Rewrite vs strangler migration

The decision

An old system is slow to change, but it earns money today. You can replace it in two ways. A rewrite builds the new system on the side, then switches all users in one cutover. The strangler method puts a routing layer, the facade, in front of the old system. Then it moves one feature at a time to the new system. The old system shrinks until you can switch it off. The forces are the cost of running two systems and the risk of a late or failed project. Two more are how soon the business sees value and how many engineers the old system still needs.

Choose a full rewrite when

• The system is small. The Microsoft guidance says the strangler pattern might not suit a small system when replacing the whole is simple (see Sources).
• Requests cannot be intercepted, so there is no place for a facade.
• You cannot change the old system or reach its source code, so you cannot redirect its calls.
• The old platform must be gone by a fixed date, for example its support ends, and a slow path would miss it.

Choose a strangler migration when

• The system is large, and a rewrite would take more than about 8 months of full-team work (our calculation, see the numbers).
• The old system must keep running and earning for a long time.
• You can find slices with clear edges: a route, a feature or a set of tables.
• The business wants value early, and a partial result must be useful.

The numbers that change the answer

All numbers are our assumptions unless marked. This is a model of the shape of the choice, not company data. The team has 8 engineers at Rs 3,000,000 a year each, so the team costs 8 x 3,000,000 / 12 = Rs 2,000,000 a month. When the whole migration is done, the business gains Rs 1,500,000 a month (less incident work, faster features). The project needs M months of full-team work if it goes well.

The strangler tax (assumptions plus calculation). The strangler method costs more total work because of the facade, a translation layer between old and new, and running both systems. Assumption: 30% more work, plus Rs 500,000 for the facade (two engineers for 4 weeks, 2 x 62,500 x 4 = Rs 500,000). Tax = 0.3 x 2,000,000 x M + 500,000 = 600,000 x M + 500,000.

The rewrite risk (assumptions plus calculation).

• Assumption: half of rewrites run 50% late. The expected delay cost is 0.5 x (0.5 x M months x Rs 1,500,000) = Rs 375,000 x M.
• Assumption: the chance that a rewrite is abandoned grows with size, by 2.5% for each month, so 0.025 x M. If it stops, 70% of the spend is lost: 0.7 x M x 2,000,000 = Rs 1,400,000 x M. Expected loss = 0.025 x M x 1,400,000 x M = Rs 35,000 x M squared.

Set the two costs equal: 600,000 x M + 500,000 = 375,000 x M + 35,000 x M squared. That gives 35,000 x M squared - 225,000 x M - 500,000 = 0. The positive solution is M = (225,000 + the square root of 120,625,000,000) / 70,000, which is about 8.2 months. Below it the rewrite is cheaper. Above it the strangler is cheaper.

The line moves with your assumptions. The shape stays the same: the tax grows in a straight line, and the risk of a long project grows faster. The model leaves out delays in the strangler, which favours the strangler. So treat 8.2 as a rough line, not a rule.

Value early (assumptions plus calculation). Take M = 12. The strangler needs 12 x 1.3 = 15.6 months of work. Assumption: ten equal slices, so each takes 15.6 / 10 = 1.56 months. Assumption: the facade takes about 1 month first. The first slice then delivers value near month 1 + 1.56 = 2.6, while the rewrite delivers nothing until its cutover near month 12.

Cited facts. The Azure Architecture Center describes the strangler fig pattern as a facade that intercepts requests and routes them to the old or the new system. It says to make sure the facade does not become a single point of failure or a performance bottleneck. It also says to plan for data stores that both systems use. For calls between the two systems it suggests an anti-corruption layer, an adapter that translates requests (see Sources).

What breaks with each choice

Rewrite.

• The old system keeps changing during the project, and the new one chases a moving target. Fallback: freeze features, or keep a shared list of changes that the rewrite must match.
• Hidden behaviour is lost, such as a rule that nobody wrote down. Fallback: replay real traffic against both systems and compare answers before the cutover.
• The cutover is one big bet. Fallback: switch a small share of users first, and keep the old system ready for a week.

Strangler.

• The facade becomes a bottleneck or a single point of failure. Fallback: run several copies, and keep its logic to routing only.
• The two systems share a database, and a change on one breaks the other. Fallback: an owner for each table, and a translation layer between the two designs.
• The migration never ends, and the old system lives for years. Fallback: a date for each slice, and a rule that every new feature is built in the new system.

What it costs

• Money: the strangler tax is Rs 4.1 million at 6 months and Rs 7.7 million at 12 months. The expected rewrite risk is Rs 3.51 million and Rs 9.54 million.
• Reversible-first path. Put a routing layer in front of the old system first. It is cheap, and it keeps every option open. Pick the first slice by two scores: high pain and low coupling. Migrate it in about 2 months, with a share of traffic and a quick way back. If the first three slices do not make feature work faster, stop and rethink before you continue. Use a rewrite only for slices that fit under the 8-month line, so a strangler is a series of small rewrites.
• Changing your mind: a rewrite that has started is hard to turn into a strangler, because the new code has no stable seams. A strangler can stop at any slice and keep its value.

How each level answers

The question is: "Our 10-year-old billing monolith is painful. Rewrite it?"

SDE-1: A rewrite builds a new system and switches at the end. A strangler moves one feature at a time.

SDE-2: I would not rewrite everything at once, because it can fail late. I would put a router in front, move one feature at a time, and remove the old code when it is unused.

Senior: For 12 months of work, the strangler tax is about Rs 7.7 million and the expected rewrite risk is Rs 9.54 million. The break-even in my model is near 8 months. So I strangle. I use traffic replay to compare answers, and I keep a rollback for every slice. The facade runs as several copies so it does not become a single point of failure.

Staff: I frame it as value earlier against more total work. The first slice pays after about 3 months. I get the business to agree on the end state and the date to switch off the old system. I make one team own the facade and the order of slices. I track slices done, traffic share, incidents per slice and the cost of running two systems. I stop and ask again after three slices, and when the old system's support ends.

Say it in the interview

For a large system I would use the strangler method. I would build a routing layer first, then move one slice at a time with a share of traffic and a rollback. In my model the strangler costs 30% more work plus the facade. It beats the risk of a rewrite once the project is longer than about 8 months. For a small system, or one I cannot intercept, I would rewrite.

Common mistakes

• Saying "rewrites always fail". A small or isolated system is often cheaper to rewrite, and the numbers above show it.
• Ignoring the shared database. Two systems on one set of tables is where strangler projects hurt.
• No end date. A strangler without a switch-off date becomes a permanent second system.

Sources

• Microsoft Azure Architecture Center, "Strangler Fig pattern" (page dated 2026): a facade intercepts requests and routes them to the legacy or the new system while functionality is replaced step by step; make sure the facade does not become a single point of failure or a bottleneck; plan for data stores both systems use and for cross-system dependencies (anti-corruption layer); the pattern might not suit systems whose requests cannot be intercepted, systems where you cannot access or change the legacy code, small systems that are simple to replace whole, or cases where the original must be fully decommissioned quickly. https://learn.microsoft.com/en-us/azure/architecture/patterns/strangler-fig (opens in a new tab) (checked 26 Oct 2026)
• The team size and cost, the Rs 1,500,000 benefit, the 30% extra work, the facade effort, the late and abandon chances, the 70% loss, the number of slices and the 1-month facade time are our assumptions. The table, the 8.2-month line and the 2.6-month first value are our calculations, shown above.