Legacy System Modernization: Strangler Fig or Rewrite?

Choose the strangler fig pattern when the old system still earns money and cannot stop. You replace it piece by piece behind a routing layer. Choose a big-bang rewrite only when the system is small, well understood, or too broken to keep. For most live systems, the strangler fig wins.

Almost every CTO who inherits an aging system lands at the same fork. Rewrite it from scratch, or take it apart one piece at a time? The rewrite is always the more attractive pitch, because a clean slate feels like relief. The slow route is always a bit dull. Dull usually wins, and this post explains when it does not.

What is the difference between a strangler fig and a big-bang rewrite?

A big-bang rewrite builds the replacement next to the old system, in isolation, and switches everyone over on one date. Until that date the new system earns nothing. The strangler fig approach, named by Martin Fowler in 2004 after the rainforest figs of Queensland that grow around a host tree, puts a routing layer in front of the old system and moves one capability at a time to new code. The old system shrinks until you can turn it off.

Both end in the same place. What differs is when you find out you were wrong. In a rewrite you find out at cutover. In a strangler migration you find out with the first slice, when the damage is small.

Why do big-bang rewrites go wrong?

Joel Spolsky argued in Things You Should Never Do, Part I back in 2000 that rewriting from scratch is one of the worst strategic mistakes a software company can make. He was writing about a shipped product, and the essay is old, but the reasoning carries over to internal systems. Four things tend to hurt:

• The old system knows things nobody wrote down. Years of patches hold edge cases: the odd tax rule, the customer with a special contract. A rewrite rediscovers them one production incident at a time.
• The target keeps moving. The business does not freeze for a year. Either you freeze features and everyone resents it, or you chase a moving spec and the rewrite never catches up.
• Value arrives late and all at once. Nothing ships until everything ships. Budget holders lose patience halfway through, which is exactly when a rewrite is most fragile.
• The cutover is a single point of failure. Data, integrations and load all get tested for the first time on the same weekend.

None of this means rewrites never work. It means a rewrite has to earn its place, and the seven questions below are how we would test that.

Why is the strangler fig not free?

The pitch for it usually skips the costs, so here they are:

• You run two systems for a long time and pay for both, in money and in on-call attention.
• You need a routing layer (an API gateway, a proxy, or a feature-flag layer) and someone has to look after it.
• You need seams. If the old code has no clean boundary, the first weeks go on creating one before anything can move.
• The data rarely splits as cleanly as the code does.
• The last slices are the hard ones, and the temptation is to leave them for later, forever.

We still lean toward the strangler fig for live systems. Just go in knowing that you are trading one big risk for a long list of smaller ones that you can actually manage.

Do you need to replace the system at all?

Sometimes the right answer is neither. Check the cheaper options first:

• Rehost: move it as it is to new infrastructure. Fixes hardware and hosting cost, not design. Our cloud application services cover this route.
• Refactor: clean up inside the existing code without changing what it does.
• Re-architect: change the structure, for instance by breaking a monolith apart. The strangler fig is usually this, done gradually.
• Retire: some systems should simply be switched off once their last users have moved.

If the pain is a dying server or a hosting bill, rehosting may be enough. If the pain is that every change takes weeks because everything is tangled together, moving house will not help. That is strangler or rewrite territory.

How do you decide? Seven questions for CTOs

Answer these with your tech leads in the room, not alone. For each one, note which column your honest answer lands in.

Five or more answers in one column settles it. A split, say four against three, usually points to a hybrid: strangle most of the system and rewrite the one module that is beyond saving. Hybrids are common.

Question 7 deserves a veto. If a botched cutover could hurt customers, patients or a regulator relationship, treat it as a strong vote for the incremental route, whatever the other six say.

What does this look like in real projects?

When coupling was the cost: an aviation data platform

A monolithic Java application was taking in more than 1 TB of data a day in batches that ran for six to eight hours. Insight was always half a working day old, and the fixed servers cost about $11,000 a month whether they were busy or idle. No single feature was the problem. Ingest, processing and reporting were fused together, so you could not scale or change one without touching the rest.

We re-architected it as an event-driven system on AWS. Insight now arrives in seconds, cost came down by about half, and releases use blue/green deployments so a bad one rolls back instantly. The full story is in the aviation data solution, and the thinking behind the design is on our event-driven and serverless page. The lesson for this decision: coupling, not age, was what was costing money, and that pointed to re-architecting rather than patching.

A justified rewrite: Taxi On Spot

Taxi On Spot came to us with a part-built system that someone else had started. We audited it before touching anything, found security weaknesses in the foundations, and rewrote it. That is a rewrite done for the right reasons: the existing code was not an asset worth carrying forward. Read the Taxi On Spot case study for the detail.

When operations could not stop: Skylark

Skylark's fleet dispatch had to keep running while it was consolidated into a single multi-tenant platform. Dispatch does not pause for a migration, so the work happened around live operations, not instead of them. That is questions 1 and 7 in practice. The Skylark case study has the details.

How do you move the data without breaking anything?

Data is where migrations actually fail, because you can swap code but you cannot swap history. This is the order we would work in:

1. Reconcile first. Run old and new on the same inputs and report every difference. Do not trust a migration you have not diffed. Staged migration with reconciliation is the default on our legacy modernization service.
2. Move in waves. Go by customer, region or record type, smallest and least risky first.
3. Name one source of truth at every moment. For each record type, say which system owns writes. Two writers is how you end up with corrupt data.
4. Keep an audit trail. Every migrated record should trace back to where it came from.
5. Rehearse the rollback. A rollback you have never run is a hope, not a plan.

If that sounds like database work as much as application work, it is. Our database engineering team is usually in the room from week one.

What does the first 90 days of a strangler migration look like?

Every system is different, so read this as a shape, not a quote.

• Weeks 1 to 2: inventory and pick a first slice. Map capabilities, dependencies and data. Choose a slice that is small, visible and low risk.
• Weeks 3 to 6: routing layer and slice one. Traffic still goes to the old system by default. Get CI/CD and monitoring in place now; our beginner's guide to CI/CD pipelines covers the basics, and our DevOps services cover the rest.
• Weeks 7 to 12: slice one in production. Send a small share of real traffic to the new code, reconcile against the old system, rehearse the rollback, then widen.

By day 90 you should have one real capability in production, a working rollback and a ranked list of the next slices. If you have a lovely architecture diagram and no production traffic, something has gone wrong. For how to ship these changes without downtime, see how DevOps coordination reduces downtime during critical deployments. 

What are the most common ways a strangler migration stalls?

1. The routing layer becomes the new monolith. Business logic creeps into it. Keep it thin.
2. Only the easy slices move. The hard core stays on the old system for years, and you end up maintaining both.
3. The shared database never gets split. Two services on one schema is not a migration, it is a new kind of coupling.
4. Nobody owns switching the old system off. Give that goal a name, an owner and a date.
5. The parity trap. The team rebuilds every old bug and every feature nobody uses. Decide what is not coming across, and write it down.

Where does AI help with legacy modernization?

In a narrow band, and it is a useful one. AI tools are good at reading unfamiliar code, summarizing what a module does and drafting tests that pin down existing behavior before you change it. They are not good at deciding what a business rule should be, or when to cut over. Our own rules are simple: AI never touches production, a person reviews every line, and a client who wants none of it can have an AI-free contract. The details are on our engineering practices page.

What should you ask anyone who proposes a big-bang rewrite?

• What is the cutover plan, and how do we roll back after it?
• How will you find the behavior nobody documented?
• What ships before the end, and when does the business first see value?
• What happens to feature requests while the rewrite is underway?
• Who pays for the old system in the meantime, and for how long?
• What would make you stop and change course?

A good answer is specific. A vague one tells you something too.

Frequently asked questions

What is the strangler fig pattern in software?

It is a migration approach where you put a routing layer in front of a legacy system and move one capability at a time to new code. Traffic shifts slice by slice until the old system handles nothing and can be switched off. Martin Fowler named the pattern in 2004.

Is a big-bang rewrite ever the right choice?

Yes, when the system is small, the spec is current and tested, little of the code is worth keeping, or the foundations are unsafe, and the business can live with a feature freeze and a single cutover. Otherwise the risk usually outweighs the tidiness.

How long does a strangler fig migration take?

It depends on how many capabilities the system has and how tangled they are, so be wary of anyone who quotes a fixed finish date before reading the code. A reasonable target is a first slice in production within a quarter, with full retirement of the old system taking considerably longer.

Does the strangler fig approach cost more than a rewrite?

It can cost more overall, because you run and maintain two systems for a while. The spending is spread out and value arrives early, though. A rewrite looks cheaper on paper but nothing is usable until the end.

What is the difference between rehosting, refactoring and re-architecting?

Rehosting moves the system to new infrastructure unchanged. Refactoring cleans up the code without changing what it does. Re-architecting changes the structure, for example by splitting a monolith into services. A rewrite replaces the system outright.

How do you migrate data during a strangler fig migration without downtime?

Move it in waves, with one system owning writes for each record type at any moment. Compare old against new on the same inputs, keep an audit trail, and rehearse the rollback before each wave.

Want a second opinion on your own system?

If you are stuck between the two paths, a short discovery call is the cheapest way to pressure-test the decision. Bring your answers to the seven questions and we will tell you where we disagree. Book a discovery call, or look at how we work with clients first.