Not every system change needs a public tender. But every one of them needs requirements that hold — and a migration that loses nothing.
We capture, structure and maintain the requirements for your geodata system — and accompany the migration of your legacy data into the new environment. Whether you are moving to QGIS and PostGIS, replacing a proprietary legacy system, or consolidating isolated solutions that grew over the years.
Arrange an initial consultation →
Does this sound familiar?
- You are moving to open source. QGIS and PostGIS are meant to replace a licensed system — and now it turns out that no one can write down precisely everything the legacy system actually does.
- Your legacy system is being phased out. The vendor is ending maintenance, the contract expires, or the last person who really knows the system is about to retire.
- Your data lives in five places. A specialist database, a folder full of shapefiles, an Access file serving as order management, an Excel tracker, and the knowledge in the heads of two people.
- You have received an offer and don't know whether it fits. Because the requirement it could be measured against was never written.
- You are heading into a tender. Then requirements engineering is the step before it — what comes after is on our page on tender and award support.
If this sounds familiar: nobody dropped the ball. Writing requirements down is work that only becomes urgent once it is too late for it — and work nobody is usually freed up for alongside running operations.
What you gain from it
- You know what you need — before the first invoice. Not as a wish list, but as a verifiable catalogue you can hold an offer, a configuration or an acceptance test against.
- Your specialist department is relieved, not replaced. Your people supply the knowledge in workshops; the writing, ordering and follow-up we take on. It ties nobody up for months.
- You lose nothing in the migration. Because what exists was measured beforehand — instead of searching afterwards for what is missing.
- Your knowledge stays in the house. What today sits in people's heads and long-practised routines is afterwards written down in a document someone can still read in five years.
- You can stop or switch at any time. Requirements and data model belong to you — they are tied neither to a product nor to us.
For us, requirements engineering means a chain that holds
Most requirements catalogues die the moment the project begins — because no one can find them again. We build them so that every requirement stays traceable from the observation in the department to the acceptance test case:
- Observation — We watch how the work is actually done. Not how the process manual describes it.
- User story — Every requirement is formulated from the perspective of the people who work with it: “As an editor, I see …”, “As a system, I offer …”.
- Classification — K.O., High, Medium, Low. Without this rating every requirement carries the same weight, and then nothing can be prioritised.
- Weighting — Requirements that are critical for your operations carry additional weight. Justified transparently, not by gut feeling.
- Target data model — Every requirement that touches data ends up in the model. That way no catalogue emerges that talks past the data model.
- Acceptance test case — Every must-have requirement comes with a test that proves it. Otherwise “fulfilled” is an opinion.
- Operation — Whatever changes in live operation is tracked back to the same requirement. The catalogue stays alive instead of becoming a project artefact.
In a current procedure this produced 294 functional and 70 non-functional requirements across 26 function groups — each individually classified, weighted and priceable. The scale is not an end in itself: it is the difference between “the system shall manage pipelines” and a statement someone can commit to contractually.
The requirement nobody mentions
The critical requirements rarely appear in questionnaires. They show up when you watch: the routine someone has performed for twelve years without ever mentioning it. The special rule for one network region. The field officially no longer in use that three evaluations depend on.
That is why we work on site and with real data: watching the editing work, running through real orders, collecting the special cases that never appear in the standard process. What we find, we translate back into the language your people use — not into ours.
Migration: measure first, then move
1 — We count before anything is moved
Before anything is migrated, it is counted: object volumes, geometry types, attribute population, duplicates, orphans, value ranges, historical states. Your benefit: You learn the bad news at the beginning, while it is still cheap.
2 — We build the target model from your requirements
The new model grows out of your requirements, not out of the structure of the legacy system. Open, documented and OGC-compliant — with a mapping specification that assigns every source field to a target field or explains why it does not. Your benefit: You do not carry the old baggage into the new system.
3 — We migrate several times as a rehearsal
At least two runs per area, each with a test protocol: completeness, geometry fidelity, attribute reconciliation, defined error classes with thresholds. Your benefit: The production migration is the third run, not the first.
4 — We switch over and keep the way back open
Cut by region or by subject area, with a limited freeze window, a tested rollback and parallel operation for as long as it takes. Your benefit: Your operations do not come to a standstill, and a failed attempt costs hours instead of weeks.
5 — We accept against test cases and stay reachable afterwards
Acceptance is measured against the test cases from the requirements catalogue, not against a general impression. Afterwards a phase of heightened attention, in which the cases surface that never occur in testing. Your benefit: “Done” is a state with criteria, not a date. What comes after that — the ongoing preparation, maintenance and map production — is on operations and data maintenance.
Example: moving to QGIS and PostGIS
The switch from a proprietary system — ArcGIS, GEOgraf, a CAD-based asset documentation — to QGIS with PostGIS is the case we are asked about most often. Our honest short version:
What works well: capture and editing, cartography and plan output, analysis, native data storage in PostGIS without an ETL layer in between, open formats, on-premise operation as the normal case rather than an expensive exception.
What needs configuration or development: audit-proof historisation, an order and update management integrated into the asset data, the automatically generated longitudinal section, consistent 3D handling with a Z coordinate, plan-accurate cartographic text placement, fine-grained permission and locking concepts. All of it feasible — but it has to be described, classified and costed, otherwise it turns into a surprise.
Where the real gain lies: historisation, data model and rule set live in the database, not in the client. That way they survive every change of tooling — and you can change service provider without losing your data. Licence costs go down; the share for services and development goes up. So calculate total cost over the contract term, not licence prices.
And your external surveying offices? Either they keep delivering in the familiar format and you define a robust handover interface with validation logic — or they get a workstation on the target model themselves. Both belong in the requirements and should not slip through as a detail. Where the capture out in the field should be structured from the start, MoversSurvey is our building block for it: objects and metadata are recorded offline-capable and according to your data model — with mandatory fields and value lists, rather than as free text somebody has to interpret later.
What you will have in hand afterwards
- A classified requirements catalogue as user stories, weighted and traceable
- A documented target data model that belongs to you
- A migration plan with iterations, test criteria and error classes
- The profiling report on your legacy data — often the first complete look at your own holdings
- Acceptance test cases per function group
- A mapping specification from every source field to every target field
- An onboarding concept that starts from your workflows rather than from software features
How we work
A small team from Vienna works on your project. The person who records your requirements also checks the migration protocol later — so no information is lost between analysis and implementation.
We work on your side. That also means: we will tell you when a requirement you insist on is not worth the effort. And if a plan does not work in its intended form, you will hear that from us early — not at acceptance.
Frequently asked questions
We already have a requirements specification. Isn't that enough?
Often not quite. The typical gap is classification: if all requirements carry the same weight, nobody can prioritise and no provider can calculate sensibly. We will look at your document and tell you whether it holds — sometimes that is a short meeting rather than a project.
Can you handle just the migration?
Yes. Data profiling and a migration concept can be commissioned independently — including when the implementation sits with your system vendor. We then review it on your side.
How much internal time does this cost us?
We need your specialist department for workshops, for letting us watch the day-to-day work, and for the reviews — in appointments that can be planned. Everything in between runs on our side. That keeps the load on your team manageable, even when the project runs over months.
Do we have to replace everything at once?
No, and usually we advise against it. The realistic path is replacement in layers: first the leading data storage, then the workstations, and last the connected information and web systems. Coexistence for a time is not failure, it is risk management.
What about users who have worked differently for fifteen years?
They don't need software training, they need their workflows back: prepared project templates, adapted toolbars, capture forms, snapping and topology rules that enforce the same care as the legacy system. That is why the onboarding concept is part of requirements engineering for us, not part of the operating phase.
How long does it take?
Requirements capture depends on the number of people involved and the number of special cases; the migration depends on your data quality. We estimate both after a first look at your data holdings — not before.
And if it turns into a tender?
Then the groundwork is already done. A classified requirements catalogue is exactly what a bill of quantities needs — and the target data model becomes the migration part of the requirements specification. What happens from there is on our page on tender and award support.
Further reading
Let's talk about your data
Tell us what you work with today and what no longer holds. In an initial consultation we will tell you where we would start — and whether you need us for it at all.
Arrange an initial consultation →
Tender and award support →
Operations and data maintenance →
Discover MoversSurvey →
