Strangler fig, rewrite, or lift-and-shift: choosing a migration path
The decision criteria we use with clients, with two illustrative case studies.
The choice of migration strategy is the highest-leverage decision in a modernization programme. Get it right and the project proceeds with manageable risk and visible progress. Get it wrong and you either end up mid-rewrite with a broken system and no rollback, or with a modernized infrastructure that has all the same business logic problems as the original.
Strangler fig: the default for live systems
The strangler fig pattern — replacing the legacy system incrementally, one domain at a time, while it continues to run — is the right default for systems that are in production and cannot afford downtime. Each slice of new functionality is built in the modern stack, traffic is routed to it, and the corresponding legacy code is retired. The legacy system shrinks over time until it is gone.
- Works alongside a live legacy system — no big-bang cutover
- Each slice can be validated independently before the next begins
- Rollback is always one routing rule away
- Slower than a rewrite — typically 18–36 months for a large system
Full rewrite: rare but sometimes correct
Full rewrites are appropriate when the legacy codebase is so deeply broken that incremental extraction is more expensive than starting clean — and when you can afford a period of parallel running or a hard cutover. The failure mode of rewrites is underestimating scope and ending up with two half-working systems. We recommend rewrites only when: the legacy system has no clean domain boundaries to extract from, the business logic is thoroughly documented, and the team has headcount to run both in parallel.
Lift-and-shift: for infrastructure, not for code
Lift-and-shift — moving the application as-is to a new hosting environment — is the right choice for infrastructure modernization (on-premise to cloud) where the code is sound but the hosting is the problem. It is almost never the right choice for application modernization. You inherit the same constraints in a new environment and pay twice.
The strangler fig is boring by design. That is the point — boring migration, working system throughout.
Decision criteria at a glance
- System is live and cannot have downtime → strangler fig
- Business logic is well-documented and codebase has no extractable domains → rewrite
- Infrastructure is the problem, not the code → lift-and-shift
- Timeline is under 6 months → reconsider scope, not strategy
Application Modernization
Migrate legacy systems to modern, cloud-native architectures without disrupting the business.
Start a conversation
Let's find where value is leaking in your ecosystem.
Bring us the workflow, the channel, or the half-built thing that's stuck. In 30 minutes we'll tell you plainly which parts should connect, where intelligence pays back — and what it takes to ship.