Replacing a legacy system: the groundwork that decides the outcome
For: Owners of legacy systems
Updated: 2026-09
Legacy replacements usually fail on three things: undocumented business logic nobody understands any more, data quality that only surfaces during migration, and a missing switch-off date, which leaves both systems running in parallel indefinitely.
Legacy systems are rarely a problem because they are old. They become a problem because the knowledge about them disappears while the dependence on them remains. Replacing one is less an engineering task than an archaeological one.
This list covers the groundwork before development starts. It is the part most likely to be cut when saving money — and the one whose absence most reliably sinks the project.
The checklist
- 01
Recover the business logic from the system
The rules the legacy system operates by are usually documented nowhere and exist only in code or in a few people’s heads. Reconstructing them is the most demanding and most important part.
Done when: The business rules are written down and confirmed as complete by the business units.
- 02
Measure what is actually used
Establish which functions are genuinely used. It regularly turns out that a substantial share of the feature set has not been touched in years — and does not need rebuilding.
Done when: Usage data covering at least one quarter exists and unused functions are marked as such.
- 03
Check data quality before migrating
Old data holds duplicates, incomplete records and values that contradict the schema. This surfaces during migration; the only question is whether by plan or mid-cutover.
Done when: A sample has been tested against the target system’s rules and the cleanup effort is estimated.
- 04
Capture every interface
Including the unofficial ones: exports someone pulls manually each month, spreadsheets fed from the system, reports processed further elsewhere. None of these appear in system documentation.
Done when: The list includes manual and unofficial data flows, confirmed by asking the business units.
- 05
Choose the cutover route
All at once, incrementally by functional area, or in parallel with gradual redirection. Each carries its own risks; what matters is that the choice is deliberate and reasoned.
Done when: The route is chosen, reasoned and agreed with the business units.
- 06
Fix a binding switch-off date
Without a set date both systems run in parallel indefinitely — the most expensive of all possible states. The date belongs in the plan from the start, not at the end.
Done when: A switch-off date is agreed and the conditions for moving it are defined in advance.
- 07
Settle retention obligations
Legacy data often carries statutory retention periods that switching off does not lift. Archive access has to be planned before the system leaves service.
Done when: Retention periods are known and archive access for the remaining term is described.
Common mistakes
- —The new system rebuilds the legacy feature set in full, although a large part of it has been unused for years.
- —Data quality is only checked at the first migration run. The cleanup effort that then appears is in nobody’s plan.
- —There is no binding switch-off date. Both systems keep running, costs double, and nobody owns the problem.
- —Manual exports get overlooked because they appear in no system documentation — and are noticed only after switch-off.
What this checklist does not cover
- —This list covers groundwork. Target architecture selection and development itself follow their own logic.
- —Effort estimates for a replacement are not reliable before the business logic has been reconstructed. Estimating earlier means estimating the unknown.
- —Systems subject to regulatory requirements carry validation and evidence obligations not covered here.
- —The organisational side — training, resistance, process change — is a separate workstream and at least as decisive as the technical one.
Parent service: Digital Transformation
Matching offers
Legacy modernisation
Legacy modernisation makes grown software maintainable and future-proof again — step by step rather than in a risky big bang. The result is a system that can evolve without halting operations or rebuilding everything at once.
IT strategy & roadmap
An IT strategy answers which technical investments advance your business goals most — and in what order. The result is a prioritised roadmap that turns a diffuse wish list into an executable plan with clear action areas and milestones.
FAQ
Is an incremental replacement worth it?
Usually yes, because it distributes risk and produces findings early. The price is a period with two systems running, which is demanding technically and organisationally and therefore has to be time-boxed.
What if nobody knows the business logic any more?
Then it has to be reconstructed from behaviour and code, supplemented by asking the business units. That is laborious but unavoidable — a rebuild without understood rules produces new errors.
Can we simply keep the legacy system running?
Sometimes that is exactly the right call. It should be a deliberate decision, though, reasoned against security, maintainability and dependence on individuals.
More checklists
Choosing a software partner: what to settle before you commission
Choosing a software partner is decided less by references than by four contractual points: who owns the result, who holds access to the systems, what a handover looks like, and what happens when the engagement ends.
EU AI Act conformity: a checklist for the first pass
A workable first pass through the EU AI Act has six parts: know which AI runs in the business, determine your role for each system, classify under Article 6, check transparency duties separately, ensure AI literacy, and file everything so it can be found under scrutiny.
High risk or not: reasoning an Annex III classification properly
High-risk classification follows a fixed order: first the deployment area under Annex III, then whether the system plays a substantive role in the decision, then the exemption in Article 6(3). Each of those steps has to be documented with reasoning.