Every legacy modernisation project starts with someone proposing a full rewrite. It’s the instinct of engineers who’ve spent months fighting an old codebase: burn it down, start fresh. We’ve seen this end badly enough times that we now treat the full-rewrite proposal as a red flag rather than a solution.
Why rewrites fail
The new system has to reach feature parity with the old one before it can ship. The old system keeps being used (and sometimes extended) while the new one is being built. By the time the new system is ready, the old one has moved on, and the team has been running in parallel for months or years.
The strangler fig approach
We use the strangler fig pattern: route traffic through a thin proxy layer, and migrate functionality piece by piece from the old system to the new one. Each migrated module is deployed and tested independently. The old system shrinks over time; the new one grows. There is no “big bang” cutover.
The key to making this work is identifying the seams. Not every legacy system has clean module boundaries — some are a single large process where everything touches everything else. The first phase of a strangler fig engagement is often introducing those seams.
What to migrate first
Start with the highest-value, lowest-risk modules: things that are well-understood, frequently changed, and have clear inputs and outputs. Not the authentication module (high risk), not the reporting engine (complex) — something in the middle that gives the team a working example of the new architecture in production.
The organisational piece
Modernisation only works if feature development continues on the old system during the migration. This requires explicit rules: new features go on the new system if the relevant module has been migrated; otherwise they go on the old system with a migration ticket created. Without this rule, the migration stalls.