Why Most Strangler Fig Migrations Stall at 40%

← All posts

The strangler fig is a good tactic the industry has mistaken for a strategy, and the difference shows up around month 30.

There is a meeting that happens in the third year of most incremental modernization programs. The steering committee reviews the roadmap. Forty-something percent of the estate has moved to the new platform, and everyone in the room is quietly proud of that number. Then someone from finance asks when the old system gets switched off, and the answer is a sentence with no date in it.

That meeting is the plateau. It is not a crisis, which is precisely why it is dangerous. Nothing is on fire, the new platform works, and the migrated services are cheaper per transaction. Yet the program has effectively stopped, and it will stay stopped for years, because the remaining work is harder than the completed work by an order of magnitude and the political energy that funded the first half is spent.

Here is the claim, and you are welcome to disagree with it: the strangler fig pattern has no natural end. It is an execution tactic for moving functionality safely from one runtime to another, and it is very good at that. It contains no mechanism for finishing. Martin Fowler’s original metaphor ends with the host tree dead and hollow. Real programs skip that part, because killing the host tree is the only step that produces no new features and no demo.

Most organizations do not plan a modernization. They plan a migration and assume decommissioning falls out of it. It does not. Decommissioning is separate work with a separate cost, a separate risk profile, and a separate political sponsor. Name all three before your first migration sprint, or you are simply building a second system to run alongside the first one indefinitely. The plateau is predictable enough to design around, but almost none of that design work can happen after you hit it.

What the 40% plateau actually looks like inside a program

The number is not magic. Depending on the estate it lands between a third and a half. What is consistent is the shape of what got done, and of what did not.

The easy 40% is selected, not discovered

Ask any team to pick the first candidates for a strangler fig migration and they produce a sensible list: the customer portal, document generation, the notification engine, the reporting extracts, the two or three microservice-shaped things an architect carved out in 2019 and never finished. Chosen because they are low-coupling, well understood, thin on data dependencies, and demonstrable to a steering committee inside two quarters.

That is not a criticism. Early wins are how you keep a multi-year program funded. But notice what those criteria optimize for: demonstrability per unit of effort, which is almost perfectly inversely correlated with strategic importance. The modules that are easy to lift are easy to lift because the business does not depend on them very much. So the first 40% is not a random 40%. It is the 40% with the least entanglement, and moving it did not reduce entanglement in the remaining estate. It concentrated it.

What is left after the easy work is gone

What remains is a recognizable shortlist, roughly the same at a bank, an insurer, a utility or a public sector claims agency:

• The nightly batch cycle. Several hundred jobs with implicit ordering and hand-tuned windows, at least four of which are documented only by a comment saying “do not move, see incident 4471.”
• The general ledger and its feeds. Anything with a SOX control attached, where “we refactored it and the numbers moved by 0.02%” is not a sentence you want to say to an auditor.
• The pricing or rating engine. Forty years of accreted rules, maybe 60% of them still intentional. The rest are behaviours something downstream has come to depend on.
• The shared data model. The DB2 or Oracle schema everything writes to, where the pattern breaks down because you cannot strangle a table.

Every one has the same property: the acceptance criterion is not “the new thing works.” It is “the new thing produces identical output across every edge case we never enumerated.” That is a far more expensive class of problem, and the estimates produced during the easy 40% do not price it. Twelve services migrated in eighteen months does not predict the thirteenth, when the thirteenth is the rating engine.

Why the anti-corruption layer becomes permanent infrastructure

Every strangler fig implementation needs a facade: a routing layer in front of the estate, an anti-corruption layer translating between the legacy domain model and the new one, and a synchronization mechanism so data written on one side becomes visible on the other. Change data capture with Debezium into Kafka, or a message bridge, or in a depressing number of cases a reconciliation job someone wrote in a hurry.

This is correct architecture. The problem is what it becomes when the program stalls.

The third system nobody budgeted for

The business case said you were replacing one system with another. What you built was three: legacy platform, target platform, and the integration fabric holding them together. The third was scoped as temporary scaffolding, so it never got a product owner, a roadmap, an SLA, or a line in the run budget. Then the funding ends and the scaffolding is still load-bearing. You have a business-critical component that sits on the transaction path for a meaningful share of revenue, has no owner beyond whoever last touched it, accretes a special case every time a mapping edge case surfaces in production, and is the hardest thing in the estate to reason about, because it is the only component holding both domain models at once.

Ask a stalled program where its worst incidents originate and a striking proportion say the sync layer, not either of the systems it connects. That is what happens when you put your least-owned component in your highest-coupling position.

Two of everything, and then some

The compounding cost is not only infrastructure. You run two on-call rotations, or one that needs people fluent in both stacks, a much smaller hiring pool than either alone. You carry two compliance surfaces: DORA resilience testing, PCI DSS 4.0 scope, access recertification and DR evidence all run twice, plus a third time for the integration layer auditors will correctly place in scope. And you run two change pipelines, where every business change is specified once, built twice, tested three times, and released in a coordinated window.

That last one is where the money quietly goes. The double-build tax is rarely counted as a modernization cost, because it lands in feature delivery budgets rather than the program budget. It is often the largest component of dual-run cost and the least visible.

The dual-run cost curve rises, it does not sit flat

The most common modelling error in modernization business cases is treating dual-run cost as a flat penalty for a fixed period: two systems, roughly 1.6x the run cost, for three years, then it goes away. That is wrong in both terms. It does not go away, and it does not stay flat.

Dual-run cost rises because drift accumulates. On day one the two systems agree and the mapping between them is simple. Every subsequent business change makes them agree slightly less. New regulation gets implemented properly on the new stack and back-ported approximately to the old one. A defect gets fixed on one side. The target data model is deliberately different, which was the entire point, and every quarter that difference widens. The sync layer absorbs all of it.

Below is a four-year profile for a composite organization: a regional insurer we will call Calder Mutual, roughly 3,000 staff, policy administration on AS/400 with the general ledger and overnight cycle on z/OS, baseline IT run cost around $18M a year. These figures are illustrative, not a client engagement. The shape of the curve is the point, not the numbers.

Three things matter more than the totals.

The gap between “share migrated” and “legacy cost removed.” By year 4 the program has moved 43% of the estate and eliminated 19% of legacy cost. That gap is structural. Legacy run cost is dominated by fixed components: capacity you cannot step down until the last workload leaves, licences priced on installed capacity, the DR contract, the operations floor, and a control apparatus that exists whether the system runs one workload or a thousand. Savings arrive in steps, and the steps happen at decommission events, not migration events.

The two fastest-growing lines are the ones nobody sponsored. Integration and double-build together go from zero to $9.5M a year, more than the entire target platform run cost. Neither appeared in the business case, because that case modelled a migration, not a coexistence.

The curve is still rising at year 4 while migration has flattened. Between year 3 and year 4 the program moved three percentage points of estate and added $2.4M of annual cost: costing more each year, delivering less each year, until someone forces a decision.

Deloitte’s 2026 Global Technology Leadership Study found technical debt consumes 21% to 40% of IT spending, midpoint around 30%. A stalled strangler fig does not reduce that figure. It restructures the debt into a form that is harder to see and harder to retire, spread across three systems instead of one.

The political economy of the stall

The plateau is usually described as a technical problem. It is not. The difficulty of the hard core was always going to be there. What changes at month 30 is the political capacity to fund difficulty, and that follows a schedule you can predict at kickoff.

The business case was written for three years. That is the longest horizon a CFO will underwrite for infrastructure and the shortest that sounds credible for replacing a core system. The work is a five-to-seven year job, and the gap gets closed on the slide deck with optimism about the back half.

The benefits were front-loaded and have been booked. The easy 40% delivered the portal, the API layer, the reporting improvements: real benefits, correctly claimed and recognized by finance by year 2. The remaining work has a far worse profile, because retiring the batch cycle produces no new capability, only removal of cost and risk. You are asking for the largest tranche of money in the program to buy the least visible outcome.

The sponsor changes, and the budget resets. As a rough planning assumption, CIO tenure at large enterprises runs four to five years, and the sponsoring executive is often not the CIO but a transformation director on a shorter cycle. Around month 30 the person who staked their credibility on this moves on. Their successor inherits a program that is 40% complete, over budget, and attached entirely to someone else’s tenure, and the rational move is to declare phase one a success and put their own name on something new. Meanwhile the remaining scope re-wins its funding every year against initiatives with twelve-month payback. A batch cycle migration cannot win that argument on merit, only on commitment, and commitment is what erodes when the sponsor changes.

The stall is not a failure of engineering. It is the rational output of a system where the incentives to start are strong, the incentives to finish are weak, and nobody’s objectives contain the words “powered off.”

Organizational drift makes the second half harder every quarter

While the political clock runs, a second process quietly raises the cost of the work you deferred.

Your strongest engineers move to the new stack. That is not disloyalty, it is career management, and you encouraged it by telling everyone the new platform was the future. Within two years the legacy side is staffed by people who could not move or chose not to, plus contractors, plus the two or three who genuinely understand the rating engine and are within a decade of retirement.

COBOL demographics are the extreme version: roughly 220 billion lines in production, average programmer age around 55, approximately 10% retiring each year (DreamFactory). The same dynamic hits PowerBuilder, Oracle Forms, Delphi and .NET Framework 4.8 estates nobody wants on their CV. The technology does not have to be ancient. It only has to be labelled legacy inside your organization.

Three consequences compound. Knowledge concentrates rather than transfers, so the people who can safely change the batch schedule go from nine to six to three. The estimate for the hard core gets worse rather than better, because discovery on undocumented systems is done by people, not tools. And nobody refactors a system that is officially dying, so the code you eventually migrate is worse than the code you scoped. The reason to defer the hard core is that it is hard, and deferring it is the most reliable way to make it harder.

How to design an exit condition before your first migration sprint

Diagnosis without a prescription is just a vendor telling you your house is on fire. An exit condition is a set of commitments made before migration starts that make finishing structurally more likely than stopping. Six, in the order you should establish them.

1. Name a decommission date, with an owner, as a governance artifact

Not a target date in a plan. A dated commitment registered wherever your organization records things it has to answer for: the risk register, the board technology report, the regulatory change calendar. It needs a named accountable executive, and that name should not be the person running the migration.

This works for an unglamorous reason. Dates in plans move silently. Dates in risk registers move in a meeting, with a written rationale, in front of people who ask why. You are not trying to make the date accurate. You are trying to make moving it expensive enough that someone fights for it. And it belongs to the business owner, not to IT: if the head of claims owns the claims platform, she owns the day it goes dark.

2. Fund decommissioning as its own line item, not as phase 6

In almost every stalled program, decommissioning was the last phase of the plan, which made it the phase whose budget was consumed by overruns in all the earlier ones. Phase 6 does not arrive. It gets deferred into a business case nobody writes.

Carve it out as a ring-fenced budget line from year one, with its own reporting. A rule of thumb: reserve 15% to 25% of total program cost for decommissioning and the retention, archival, control migration and contract exit work that comes with it. That is more than teams expect, because decommissioning a regulated system is not “turn off the LPAR.” If you cannot get that funded separately, you have learned something about whether your organization intends to finish.

3. Sequence hard-early, not easy-first

The strongest single intervention. If the hardest component of the estate is not started in the first third of the program, it will not be started at all.

Strict hardest-first is often impractical: you need early delivery to sustain confidence, and the hard core frequently depends on foundations you have not built. The workable version is hard-early. Pick one genuinely hard component, the pricing engine or one leg of the batch cycle, and run it alongside the early wins, properly resourced, from day one. You get a real estimate for the hard class of work while you still have the political capital to act on it, and you learn in year one whether your target architecture can express the components that matter.

4. Define “done” as legacy powered off, not new system launched

Write it into the program charter and into the objectives of everyone senior on the program. A workload is not migrated when the new service is in production. It is migrated when the legacy code path is deleted, the job is out of the scheduler, the table is dropped or made read-only, and the associated capacity or licence has been surrendered.

One discipline follows: no migration is complete while the legacy path is still runnable as a fallback. Keeping the old path warm “just in case” is how 40% of the estate stays live at 100% of its cost. Set a fallback window of 30 or 60 days, and put the deletion in the same change record as the go-live so it cannot be quietly dropped.

5. Track a reverse burndown, not a feature burnup

Most modernization dashboards report progress on the new platform: services live, APIs published, story points delivered. That number only goes up, which is why executives like it and why it cannot detect a stall. Measure the legacy estate instead. Every metric below counts something that has to reach zero.

Two rules make this work. Report it at the same governance forum, with the same prominence as delivery metrics. And treat the sync-layer row as first-class, because it is the only metric measuring the thing the program created rather than the thing it replaces. If every number has been flat for two consecutive quarters, you are on the plateau, whatever the delivery burnup says.

6. Set a tripwire review at 40%

Schedule it at kickoff as a mandatory gate triggered by completion percentage, not by a date. When the program retires 40% of the estate, measured by legacy code or transaction volume rather than services delivered, the steering committee holds a review with a pre-agreed agenda:

1. Re-estimate the remaining 60% from current knowledge, with no reference to the original number. That number was produced by people who had not yet seen the hard core.
2. Report actual dual-run cost to date against the model, broken into the four lines in the cost table above.
3. Confirm the decommission date and its owner, or formally record that it has moved and why.
4. Assess key-person risk on the remaining scope by name, not by headcount.
5. Show the reverse burndown trend for the previous four quarters.

Three outcomes are permitted: commit (re-fund the remaining scope at the re-estimated number, decommission date confirmed), redesign (the approach does not work for the hard core, so change the pattern, the sequencing or the partner), or declare a deliberate hybrid. “Continue as planned” is not on the list, because that is what stalled programs choose. Set the gate at kickoff, so you agree the rules while everyone is optimistic and nobody’s reputation is attached to the answer.

When the plateau is actually the right answer

Sometimes stopping at 60% is correct. A deliberate hybrid is a legitimate architecture, and treating every unfinished migration as a failure is its own kind of error. The distinction is not the outcome, it is whether the decision was made. A deliberate hybrid has four properties an accidental one never has:

1. A dated decision record stating that the residual legacy scope will not be migrated, with the rationale and the executive who signed it.
2. The integration layer promoted to permanent product status: named owner, run budget, roadmap, SLA, on-call, and a documented contract between the two domain models rather than a pile of special cases.
3. The residual legacy system funded as a supported asset, not a dying one: patching, dependency currency, capacity planning, knowledge retention, and a documented lifecycle with a review date.
4. A stated end-of-life trigger. Not necessarily a date, but a condition: vendor support ends, hardware refresh becomes uneconomic, a regulatory change makes the current state untenable.

An accidental hybrid has none of these. It has a program that quietly slid into business-as-usual, an integration layer maintained by whoever is unlucky, and a legacy system nobody may invest in because it is officially being replaced. That last condition is the poisonous one: a system neither maintained nor retired degrades in both directions at once.

The test is simple. Ask three executives independently whether the legacy system is being replaced. If you get three answers, you have an accidental hybrid, and the first thing to fix is not architecture. It is the decision record.

Frequently Asked Questions

Is the strangler fig pattern wrong?

No. For incrementally redirecting functionality from an old system to a new one while keeping the lights on, it remains the best available approach for most large estates, and big-bang replacement has a considerably worse failure profile. The error is treating it as a strategy rather than a tactic. It tells you how to move a workload. It says nothing about which workloads to move first, how to fund removal of the old system, or how you will know you are finished. Make those decisions explicitly, or the pattern’s bias toward low-risk increments makes them for you, and it always picks the easy ones.

How do we tell whether our program has already stalled?

Three signals, read together. First, the reverse burndown: if legacy batch jobs, legacy transaction volume and legacy source lines have all been flat for two consecutive quarters while new-platform delivery continues, you have stalled regardless of what the delivery report says. Second, the decommission date: if you cannot get a specific date and a named owner within one working day of asking, one does not exist. Third, the sync layer: if synchronized record types are rising quarter over quarter, drift is outpacing convergence and the two systems are moving apart faster than you are merging them.

Why does decommissioning cost so much more than teams expect?

Because it is mostly not technical work. It is extracting and proving retention of records under statutory hold, migrating SOX and audit control evidence to the new platform’s control set, unwinding vendor and capacity contracts inside their notice periods, decommissioning DR arrangements, and producing an evidence pack that satisfies internal audit and, in regulated sectors, your supervisor. Organizations that treat this as a switch-off task commonly underestimate it by a factor of three, which is why it needs its own funded line rather than a slot at the end of the plan.

Who should own the integration layer during dual-run?

Someone whose incentives are aligned with its deletion. The most reliable arrangement is to give it to the team accountable for the decommission date and to publish its size as a governance metric: record types synchronized, mappings maintained, special cases added this quarter. If the layer belongs to a platform team whose success is measured by uptime, it will be operated well and it will never shrink, because nobody is rewarded for removing it. Give the same team the decommission date and the sync layer, and every new mapping becomes a cost they personally want to retire. Ownership determines trajectory more reliably than architecture does.

The Bottom Line

The strangler fig will get you to 40%, and that first 40% will look like a success, because it is one. What it will not do is get you to 100%. Nothing in the pattern creates pressure to remove the host tree, and every force acting on your organization, from budget cycles to executive tenure to the human preference for building over deleting, pushes the other way.

So the exit condition has to be engineered in advance, and it is mostly not an engineering artifact. It is a dated commitment with a named owner, a ring-fenced decommissioning budget, a hard component started early, a definition of done that means powered off, a metric that counts down instead of up, and a gate at 40% with “carry on as before” removed from the options.

Do that in the first two months and you have a modernization program. Skip it and you have a well-executed migration that leaves you running two systems, two rotations, two compliance surfaces and one unowned integration layer for the next decade. Legacy maintenance already consumes between 60% and 80% of IT budgets across the industry. A stalled strangler fig does not reduce that number. It makes the bill harder to read.

two-week portfolio triage

If your program sits somewhere between 30% and 50% complete and the decommission date has moved twice, that is the moment when intervention is still cheap. Modernize Software runs a that re-estimates your remaining scope from current evidence, models your actual dual-run cost curve, and produces a dated exit plan with named owners: the artifacts your original business case probably left out. Worth a conversation before the next budget cycle resets.