Every company has a system nobody wants to touch. The one the whole business runs on, patched for a decade, understood best by the person who retired two years ago. In financial services it is usually the core — the ledger, the system of record, the ERP-adjacent platform that knows where the money is and cannot be wrong about it. It works. It is also the single largest piece of concentrated risk on the technology estate, and everyone knows it.
When the pressure finally builds, the instinct is to propose a rewrite. Two years, a big number, a new platform, a cutover weekend, a press release. I have sat through enough of those proposals to have a reflex about them, and the reflex is no. The full rewrite of a core system is the most expensive way to modernize and the one most likely to fail. A widely cited warning in software is that rewriting from scratch throws away the one asset that is hard to rebuild quickly — the accumulated knowledge of every edge case the old system quietly handles and nobody wrote down.
There is a better shape, and it is not new. Martin Fowler named it the strangler fig, after the vine that grows up around a host tree, takes over its structure, and eventually stands on its own where the tree used to be. You grow the new system around the old one, capability by capability, until the old one carries no traffic and you can turn it off. No big bang. No weekend where the whole company holds its breath. This is an operating model, not a database trick — the sequencing, the funding, and the discipline that keep the lights on while you do it. Here is how I think about running it.
Route through a facade, not around the core
The first move is to stop letting callers talk to the core directly. You put a facade in front of it — a routing layer that every consumer goes through — and on day one that facade sends one hundred percent of traffic straight to the legacy system. Nothing has changed functionally. What has changed is that you now own the seam. Every request to the core passes through a place you control, and that place is where the entire migration will happen.
From there, replacement is a routing decision. You build the new implementation of one capability and flip a fraction of its traffic from the legacy path to the new one — a canary, then a larger slice, then all of it. The facade holds the dial. When a slice is fully migrated, the old code behind it is dead, and you delete it. The core shrinks from the outside in.
Two patterns make this survivable. An anti-corruption layer — the term is from domain-driven design — sits between your clean new model and the legacy one, so the old system's assumptions do not leak into the new code and quietly recreate the mess you are escaping. And branch by abstraction lets you build the replacement behind the facade in the mainline, in the open, instead of on a long-lived branch that has to survive a year of divergence before it merges.
The facade is also where the platform earns its keep in a regulated shop. The routing seam is the natural home for logging, authorization, and the audit trail — one place that sees every call to the system of record instead of every team reaching into it its own way. It is the same reason we route every model call in AgentOS, the governed agent platform my team built, through a single controlled path rather than letting each team hit the model directly. A facade is not just a migration tool. It is a control point worth building even before you replace anything behind it.
Sequence by seam, not by ambition
The most common way to kill a strangler migration in month three is to start with the wrong slice. The loudest engineer wants to rewrite the hardest, most interesting part first — the posting logic, the balance engine, the thing at the center. That is exactly backwards. The center is the last thing you touch, once your facade, your reconciliation harness, and your team's confidence have been proven at lower stakes. You do not learn to migrate a ledger by migrating the ledger first.
Pick the first slice on two axes at once: the cleanest seam and the lowest blast radius. Find a bounded context with the fewest tendrils into the rest of the system — a capability you can wrap without unpicking twenty hidden dependencies — and prefer one that is mostly read, rarely written, and reversible if you get it wrong. Reporting, a read-heavy lookup, a notification path. Real enough to prove the machinery, safe enough that a bad day is embarrassing rather than material.
The sequence I would run, once the facade is in place:
- Instrument the core to see the call graph you actually have, not the one the architecture diagram claims. You cannot sequence what you cannot see.
- Pick a first slice that is peripheral, read-heavy, and reversible, and use it to prove the facade, the anti-corruption layer, and the reconciliation harness end to end.
- Dual-run that slice — new path and old path both live — and reconcile their outputs until they agree for long enough to trust.
- Cut the slice over behind a flag, watch it, and only then delete the legacy code it replaced.
- Repeat inward, taking on more coupling and higher stakes with each slice, until the system of record is the last thing standing — and, by then, the least frightening thing you have ever migrated.
Each slice you retire makes the next one easier, because the core gets smaller and better understood every time. That compounding is the whole reason the pattern wins: a big-bang gets harder as it goes; a strangler gets easier.
Fund it as a portfolio line, not a project with an end date
Here is the honest reason big-bang rewrites keep getting approved: they are easy to fund. A rewrite has a start, an end, and a number, and a board can vote on that. A strangler migration looks, to a finance committee, like a thing that never ends — incremental spend with no ribbon-cutting. That funding shape is a real reason good engineering strategy loses to bad. I report to boards, and I would not bring this one as an open-ended platform tax.
I am a security and platform leader, not your controller, but the shape of the money matters and I have watched it decide these programs. Use a portfolio lens to classify what you are doing — the TIME model, Gartner's tolerate, invest, migrate, eliminate — so the core moves explicitly from tolerate to migrate and the board sees a decision rather than a slow leak. Use cost transparency, the discipline the TBM framework formalizes, to surface the real run-rate cost of keeping the legacy core alive — license, specialized staff, risk premium — so the migration is measured against a genuine number, not against zero.
And understand the accounting shape, because it is not neutral. Under the general logic of ASC 350-40, the US standard for internal-use software, costs in the application-development stage of genuinely new functionality can often be capitalized while routine maintenance is expensed as incurred. A like-for-like rewrite that adds no capability is a harder capitalization story than incremental slices that each deliver new function. I am not handing you an accounting opinion — take the specifics to your controller — but the operating-model choice and the capitalization treatment are linked, and a strangler sequenced as capability deliveries tends to sit better with the board and the auditors than a two-year rewrite booked as one act of faith.
So fund the first two or three slices as a proof, not the whole program up front. Tie the release of further capital to a demonstrated result — traffic moved, slices retired, legacy run-rate falling — the way a disciplined capital-allocation process stages money against milestones instead of writing one check against a plan. That is a story a board can actually govern.
Keep the lights on with dual-run, not a cutover weekend
This is the section I can speak to from my own chair, because running two systems safely in parallel is platform and security work, and it is where a strangler migration is won or lost. The whole promise of the pattern is that you never bet the company on a single cutover.
The mid-migration disciplines that make that real:
- Dual-run before you cut over. Run the new path in shadow — it computes its answer alongside the legacy path, which is still the source of truth — so you can compare without any customer depending on the new code yet.
- Reconcile relentlessly, and make disagreement loud. A reconciliation harness compares the two outputs on every call and flags every divergence. You promote a slice not because it looks done, but because it has matched the legacy system long enough that a mismatch would be news. That log is also your audit evidence.
- Cut over behind a flag with instant rollback. Each slice flips on a flag you can turn off in seconds. If the new path misbehaves in production, you route back to legacy while you fix it, and no one outside the team needs to know it happened.
- Treat every cutover as a change with a reversal plan. In a regulated shop this is not optional theater. Examiners and FFIEC-style change-management expectations want a change to a critical system to be controlled and reversible, and the EU's DORA regime pushes financial entities toward exactly this resilience testing on the systems that matter most. The reversibility you build for safety is the reversibility that passes the exam.
Notice that none of this is a database technique. Zero-downtime schema changes and active-active data stores are real and they matter, but they are the plumbing under one slice. The strangler is the operating model above all of them — the sequencing, the facade, the reconciliation, the flag — that lets you modernize a whole platform without a single night where everything is at stake at once.
Measure the strangle, not the story
A rewrite is reported as a narrative — percent complete, on track, we are confident — and it stays green until the month it does not. A strangler migration reports itself in facts, and you should insist on the facts. The share of traffic on the new path. The number of slices retired. The legacy call graph shrinking month over month. The contract or the specialized headcount you could finally reduce because the thing it supported is gone. Those facts also enforce the discipline teams love to skip: actually deleting the strangled code once its traffic reaches zero. Code you have stopped calling but never removed is not a finished migration — it is a second system you still carry, still have to secure, and still have to explain to an auditor. The strangle is complete when the old path is deleted, not when the new one goes live.
Where I'd start
If you are staring at a core system you are afraid to touch, do not open with the rewrite proposal. Start smaller and start sooner:
- Build the facade first and migrate nothing yet. Own the seam, put your logging and authorization on it, and you have made the system safer before you have replaced a single line of it.
- Prove the machinery on a peripheral, reversible slice before you go anywhere near the ledger, and let each retired slice make the next one easier.
- Fund it in stages against a demonstrated strangle, never as one open-ended tax, and never call a slice done until the old code is deleted.
I am reasoning about this from the platform and security side of the house, up toward the portfolio and funding decisions that sit a rung above me, so I would genuinely like to hear from people who have run one of these to the end. What was the slice you wish you had sequenced differently, and how did you keep the funding alive through the boring middle when there was no ribbon to cut? Leave a comment — I read the replies, and the middle is where I have the most to learn.
