Key takeaways
- Full rewrites fail more often from scope and timing than from technology.
- Put a stable interface in front of the old system before replacing anything behind it.
- Replace one business capability at a time, and prove it in production before the next.
- Run old and new side by side and compare outputs before switching traffic.
Full rewrites promise a clean slate and usually deliver a long, risky project. Replacing a legacy system in stages keeps the business running and proves each step.
Why full rewrites stall
A legacy system is usually old for a good reason: it works, and the business depends on it. Years of rules, exceptions and fixes are encoded in it, many of them undocumented. A rewrite has to rediscover all of them while the old system keeps changing underneath.
The result is a familiar pattern. The new system takes longer than planned, the old one needs urgent changes in the meantime, and the cutover date moves. Meanwhile the business pays for two systems and gets the benefit of neither.
Start with a stable interface
The first step is not writing new code for the core. It is putting an interface — usually an API layer — in front of the existing system, so that other applications talk to that interface instead of to the legacy database or screens directly.
Once consumers depend on the interface rather than the implementation, you can change what sits behind it one piece at a time. This is often called the strangler pattern: the new system gradually grows around the old one until the old one can be switched off.
Sequence by business capability
Choose the first capability to replace on two criteria: how much pain it causes today and how isolated it is. A good first candidate has clear inputs and outputs and few dependencies — for example, quotation generation, notifications or reporting.
Avoid starting with the most central, most connected part of the system. Early stages should build confidence and shared understanding, not bet the project.
- Map capabilities and the data each one owns.
- Score each by business pain and coupling.
- Start where pain is high and coupling is low.
- Leave the core transaction engine until the team knows the domain well.
Prove each step with parallel running
Before switching a capability over, run the old and new implementations side by side on the same inputs and compare the results. Differences reveal undocumented rules faster than any requirements workshop.
Switch traffic gradually — by branch, customer group or percentage — and keep a documented rollback path. A migration step that can't be reversed is a step that needs more preparation.
Treat data migration as its own project
Data outlives code. Legacy data often contains duplicates, inconsistent formats and fields used for purposes they were never designed for. Plan cleaning, mapping and verification explicitly, with counts and checksums that prove nothing was lost.
When the last capability moves, decommissioning the old system should be a formality: every consumer already uses the new interface, every dataset has been verified, and the business has been running on the new system for weeks.
Enjoyed this? Get the next one by email.