Replacing legacy systems — without stopping operations
Grown software can be replaced step by step: first an inventory, then data migration, parallel operation, sign-off and finally the shutdown. Day-to-day business continues while the new system takes over one task at a time.
Entry point and delivery · net plus VAT
- Record first, replace second: no system change without an inventory
- A fixed price per replacement step instead of an open-ended estimate
- Parallel operation for as long as the old system is still needed
- Shutdown only once data, documents and reports have been signed off
The process analysis for a legacy system starts at 1,900 € net: we record which workflows the system carries today, which data sits inside it and which systems depend on it. You receive a written report with a prioritised replacement plan. Each replacement step in the delivery phase — a data migration, an interface, an automated part of the workflow — starts at 4,900 € net as a fixed price that is set once the analysis is complete. Ongoing support for the new setup starts at 190 € net per month. All prices are net plus VAT; third-party licences and fees are shown separately. The full breakdown is on the pricing overview.
Prices as of September 2026. Ongoing services are booked individually and can be cancelled monthly; there is no minimum term.
In many mid-sized companies, software runs quietly in the background that nobody wants to touch any more: an order management tool from the early years of the business, an industry solution whose maker no longer exists in that form, a database on a machine that is not restarted for good reason. These systems work — otherwise they would be long gone. At the same time they block every further step: they cannot be connected, they know nothing about mobile devices, and their reporting stops exactly where proper reporting would have to begin. We replace systems like these without bringing operations to a halt.
What the inventory brings to light
When replacing a legacy system becomes due
The right moment for a replacement rarely follows from the age of the software alone. What matters is how much extra work the system creates day to day and how tightly it limits your room for manoeuvre. Typical triggers are: the vendor stops maintenance and security updates. The system only runs on an operating system that no longer receives updates. There is no interface, so data is copied into other programmes by hand. Reports are produced by someone transcribing figures from several screens into a spreadsheet. Or: exactly one person in the company knows how a particular report comes about.
In the process analysis we separate two questions that are often mixed up: what does the legacy system deliver in business terms, and what technical shell surrounds it? The business capability has to be preserved, the shell does not. That distinction determines the scope: often it is not the whole system that needs replacing, only the part that creates the extra work. The rest can keep running until it reaches its natural end.
Missing documentation
For many legacy systems there is no manual left, no field description and no overview of the special cases. We reconstruct the business logic from live operations: from the data, from documents and from conversations with the people who work with it every day. The result feeds into process documentation that describes the workflow independently of the system.
Unclear dependencies
Legacy systems are rarely alone. File exports, print templates, a time-recording terminal and a recurring report for accounting all hang off them. Before the first replacement step we record every incoming and outgoing connection, so that nothing fails quietly at shutdown that somebody elsewhere relies on.
Support running out
Once maintenance ends, the system no longer receives security updates. As an interim measure, access can be restricted: a separate network segment, no access from the internet, documented exceptions. That buys time for an orderly replacement, but it does not replace one.
Knowledge tied to individuals
If only one person knows how a special case is handled, that is a risk for the business, not just for the project. We write these rules down during the inventory and hand them over to the team as part of training and rollout.
Five steps from inventory to shutdown
Inventory
We record which workflows the legacy system carries, which data it holds, who works with it and which systems depend on it. That includes the quiet uses: the monthly export for accounting, the print template for delivery notes, the list pulled once a year for stocktaking. The result is a report with a replacement plan and an order of work driven by benefit and risk.
Preparing the data migration
We take a complete data extract, map fields against the target system and define what is migrated, what is cleaned up and what is only archived. Every rule is written down. Before the first real migration there is at least one trial run with a reconciliation log: record counts, totals, spot checks.
Parallel operation
The new system takes over a clearly bounded part of the workflow while the old one keeps running. During this phase both states can be compared and the way back stays open. The scope grows step by step: first one department or one order type, then the next area. We accompany this phase closely, because this is where the special cases surface that were in no description.
Sign-off
Before shutdown we check together with the departments against a checklist: has all data been migrated completely? Do totals and balances match? Do documents, print templates and reports work in the new setup? Have the connections to neighbouring systems been switched over? Only once these points are ticked off does the step count as signed off.
Shutdown and archive
The legacy system is not deleted straight away. First it keeps running in read-only mode or is replaced by a read archive so that old records remain accessible. Only then follow the shutdown, the backup of the data and documentation of the final state — including the question of how long which data has to be retained.
We record which workflows the legacy system carries, which data it holds, who works with it and which systems depend on it. That includes the quiet uses: the monthly export for accounting, the print template for delivery notes, the list pulled once a year for stocktaking. The result is a report with a replacement plan and an order of work driven by benefit and risk.
We take a complete data extract, map fields against the target system and define what is migrated, what is cleaned up and what is only archived. Every rule is written down. Before the first real migration there is at least one trial run with a reconciliation log: record counts, totals, spot checks.
The new system takes over a clearly bounded part of the workflow while the old one keeps running. During this phase both states can be compared and the way back stays open. The scope grows step by step: first one department or one order type, then the next area. We accompany this phase closely, because this is where the special cases surface that were in no description.
Before shutdown we check together with the departments against a checklist: has all data been migrated completely? Do totals and balances match? Do documents, print templates and reports work in the new setup? Have the connections to neighbouring systems been switched over? Only once these points are ticked off does the step count as signed off.
The legacy system is not deleted straight away. First it keeps running in read-only mode or is replaced by a read archive so that old records remain accessible. Only then follow the shutdown, the backup of the data and documentation of the final state — including the question of how long which data has to be retained.
Inventory: what the old system actually delivers
The most common cause of trouble in a replacement is not the technology but an incomplete inventory (project experience). A system is replaced, and three weeks later someone notices that a report was attached to it that was only needed once a quarter. That is why we do not just record the obvious screens but follow the path of the data: where does it come in, where does it go out, who reads it?
- All user groups and their daily, weekly and annual tasks in the system
- Incoming data: imports, terminals, file shares, manual entry
- Outgoing data: exports, print templates, reports, handovers to accounting
- Special cases and exception rules that are only passed on verbally
- Historical records that have to stay accessible for legal reasons
- Technical setting: server location, backups, access, remaining maintenance contracts
Data migration without loss
Data migration is the part of a replacement that demands the most care. Old records have grown over years: fields have been repurposed, comment fields carry business information, customer numbers exist twice, date values sit side by side in different formats. These quirks only come to light once the data leaves the system. We therefore work with a written migration rule per field and with several trial runs before any dataset goes live. How several sources are brought together technically is described on the page about data integration.
Field mapping
For every field in the legacy system we define where it belongs in the new setup, whether it is converted and what happens to values that have no counterpart. The mapping is written down and stays traceable.
Cleanup before migration
Duplicate master records, orphaned references and incomplete records are dealt with before the migration, not afterwards. Otherwise the old baggage travels along and weighs on the new setup from day one.
Trial migration
Every migration runs on a test environment first. Departments check there against records they know whether the data arrives the way it is needed — before anything goes into production.
Reconciliation log
After each run there is a log with record counts per area, totals and balances plus a list of deviations. Every deviation is explained or corrected before the work continues.
History and documents
Not every old record has to go into the new system. It is often more sensible to move documents and closed records into a searchable archive and keep only the active data in the new setup.
Cut-off date and follow-up
For moving data we agree a cut-off date on which the dataset is frozen and migrated. Whatever is still created in the legacy system after that is carried over in a defined follow-up.
Data quality belongs in the replacement plan, not behind it
Parallel operation instead of a single cut-over date
Why we keep the way back open
A cut-over on a single date requires that every special case is known in advance. With grown systems that is rarely the case. In parallel operation the new system takes over a bounded area while the old one keeps serving the rest. If unexpected cases appear, that area is rolled back instead of halting the whole business. The price is a phase with two systems — in return, operations stay able to act.
- A bounded scope per step: one order type, one area, one site
- Comparable states in both systems throughout the phase
- A defined way back for as long as sign-off has not been given
- Special cases surface in live operation and get recorded
Sign-off, shutdown and retention
Sign-off is not a formality at the end but the point at which the way back is closed. That is why we work with a checklist agreed before the step and involving the departments: completeness of the migrated data, agreement of totals and balances, function of documents and print templates, availability of reports, switch-over of the connections to neighbouring systems. Anything left open on that list prevents the shutdown — even if a date has already been announced.
After sign-off, the shutdown happens in stages. First the legacy system keeps running in read-only mode so old records stay visible while no new data is created. In parallel we check which datasets have to be retained and for how long; in Germany, records relevant for tax purposes are subject to statutory retention periods that must remain satisfiable after a system change. In many cases a searchable read archive is the more practical route than keeping an old installation alive. Only then are servers switched off, access withdrawn and maintenance contracts ended. We hand over the final state documented — what was migrated, what is archived and where it sits.
Three ways to deal with a legacy system
Which route fits depends on the condition of the system, on the risk and on the time available in day-to-day business.
Keep the legacy system running
- Included: No project cost and no disruption to daily business
- Included: The team knows the handling and the special cases
- Not included: Without maintenance, security gaps stay open
- Not included: Connections to newer systems remain costly or impossible
- Not included: The effort for a later replacement keeps growing every year
Cut-over on a single date
- Included: A short phase with two systems, then one clear setup
- Included: Lower running cost during the switch-over
- Not included: Requires that all special cases are known beforehand
- Not included: Unexpected cases hit the entire business at the same time
- Not included: After the cut-over date the way back is effectively closed
Step-by-step replacement with parallel operation
- Included: Every step has a bounded scope and its own sign-off
- Included: The way back stays open until the step is signed off
- Included: Special cases surface in live operation and get recorded
- Included: Fixed price per step from 4,900 € net after the inventory
- Not included: Two systems run side by side for a while and take up attention
What a replacement costs
The effort involved depends less on the age of the system than on the number of connected neighbouring systems and on the state of the data. That is why the inventory comes before any delivery quote: it provides the basis for naming a fixed price per replacement step instead of putting an open-ended estimate across the whole undertaking. Smaller projects get by with two or three steps; with tightly interwoven system landscapes a replacement stretches across several months and several steps (project experience).
Prices for replacing legacy systems
All prices net plus VAT. Every project starts with the inventory; the fixed prices per replacement step are set after that.
Inventory and replacement plan
The entry point: record what the legacy system carries and put it into an order of work.
- On-site recording of workflows, user groups and special cases
- Overview of all incoming and outgoing connections
- Assessment of the data and its quality
- Written report with a prioritised replacement plan
- Basis for the fixed prices of the delivery phase
Replacement step by step
One bounded replacement step: data migration, an interface or a replaced part of the workflow.
- Migration rules per field, written down
- Trial migration with reconciliation log before going live
- Connection of neighbouring systems via interfaces
- Accompanied parallel operation with a defined way back
- Sign-off against a checklist agreed in advance
Operation and support
The new setup stays looked after, including after the legacy system is switched off.
- Monitoring of the migrated workflows and handovers
- One named contact for questions from the departments
- Adjustments when workflows change in the business
- Upkeep of the process documentation
- Further services under operations and maintenance
All prices net plus VAT. Third-party licences, fees and maintenance costs are shown separately. We name the binding fixed price per replacement step after the inventory.
Not sure whether the whole system has to go?
It is often enough to replace the part that creates the extra work. In the inventory we separate business capability from technical shell and tell you which scope is really needed.
Typical starting situations with legacy systems
Illustrative scenarios from typical project sequences (project experience), anonymised and without customer details.
A replacement has succeeded when nobody in daily business talks about the change any more — and the reports still show the figures that were needed before.