Complete rewrites fail at a high rate. Incremental strangulation delivers value earlier and carries far less risk.
A rewrite must reproduce years of accumulated behaviour, including undocumented rules encoded in the original by people who have left. Meanwhile the old system keeps changing, and the new one is chasing a moving target.
The business sees no benefit until the end, which makes the project politically fragile precisely when it needs patience.
Put a routing layer in front of the legacy system. Build new capability behind it, route specific functions to the new implementation, and gradually reduce what the old system handles.
Value arrives from the first slice. The legacy system shrinks rather than being replaced in one step, and at any point you can stop with something valuable delivered.
While both systems run, data must be consistent. Options are a shared database during transition, synchronisation between stores, or a clean ownership split per entity.
Each has trade-offs and all require deliberate design. Underestimating this is the most common reason incremental modernisation stalls, and it deserves as much attention as the application work.
Incremental modernisation delivers value continuously and can still lose support, because the old system remains visible and progress feels slow to people not close to the work.
Report what has moved and what that enabled, in business terms: a function now changeable in days rather than months, a report available that previously was not. Technical milestones do not sustain sponsorship.
Make the shrinking scope of the legacy system visible. A simple picture showing what has moved is more persuasive than any status report.
Longer than a rewrite estimate and it delivers value throughout. The relevant comparison is time to first benefit, where incremental approaches win comfortably.
Add characterisation tests that capture current behaviour before changing anything. They document what the system does, which is not always what anyone believes.
Sometimes, and it is usually harder than the application layer because everything depends on it. Splitting ownership per entity is generally more tractable than a wholesale migration.
Keep reading
Microservices solve organisational scaling problems and introduce distributed systems problems. Most teams should start with a well-structured monolith.
Relational databases handle the overwhelming majority of business workloads well. Alternatives should be chosen for specific reasons.
Events decouple producers from consumers and make the overall flow harder to see. Both effects are real and need managing.
