The strangler pattern came out of application modernisation, and it has been borrowed into the data world with mixed results. The idea is simple enough: rather than replacing a legacy system in one move, you place a new system in front of it, redirect functionality piece by piece, and let the old system shrink until nothing depends on it and it can be switched off.
It works well for applications because applications have a natural interception point. Requests arrive over a network. A routing layer can send some to the old system and some to the new, and the caller does not need to know or care.
Data platforms do not have that clean seam, which is why importing the pattern naively tends to disappoint. Getting value from it requires understanding what the equivalent of the routing layer actually is.
The seam is the semantic layer, not the storage
The mistake we see most often is attempting to strangle at the storage layer. Teams stand up a new warehouse, start dual-writing tables, and expect consumers to be indifferent to which one they read from.
Consumers are not indifferent, because in most estates they are not reading a clean interface. They are reading physical tables, with physical names, in queries written by people who have since moved teams. Point them at a different physical location and things break in ways that are tedious to trace.
The interception point that works is a level up, wherever consumers ask questions rather than address storage. In practice that is a view layer, a semantic model, or the BI tool’s shared dataset. If a report asks for monthly recurring revenue by segment and something in between decides where that comes from, you have a seam. If a report selects from a named schema, you do not.
Which means that for many organisations, step one of a strangler migration is not migration at all. It is building the abstraction that makes strangling possible. That work is unglamorous and it is the whole game.
Build the seam before you need it
Introducing a view layer over a legacy warehouse, with consumers migrated onto it while nothing else changes, feels like a wasted quarter. Nothing improves. Costs do not fall. No new capability appears. Explaining this to a steering committee is genuinely hard.
It is also the difference between a modernisation that can proceed incrementally and one that can only proceed as a big bang. Every consumer moved onto the abstraction is a consumer you can redirect later without touching their code. Every consumer left addressing physical tables is one you will have to migrate manually, under time pressure, at the worst possible moment.
We frame this as optionality rather than progress. The quarter does not deliver a feature. It delivers the ability to change your mind cheaply for the next three years.
Strangle by domain, and pick the boring one first
Once the seam exists, the question is sequencing. The temptation is to start with the highest-value domain, on the reasoning that value should be delivered early.
We advise against it, for the same reason you do not learn to drive in traffic. The first domain through a new platform is not really a migration. It is the platform’s first real test, and it will surface every gap in the deployment model, the testing approach, the access model, the monitoring and the on-call process. You want that happening somewhere the consequences of a bad week are contained.
Pick something with real complexity but low blast radius. An internal operational domain is usually ideal: complicated enough to be a genuine test, but not something that appears in a regulatory return.
Two systems, one definition
The characteristic failure mode of a long strangler migration is definition drift. Old platform and new platform both calculate active customers. For eight months they agree. Then someone patches the legacy logic for a specific commercial need, and now they do not, and nobody notices until two reports disagree in front of an executive.
Three defences, in order of effectiveness. First, freeze the legacy platform to essential fixes only, in writing, with a named approver. Second, run the equivalence checks continuously for the whole transition rather than only at cutover, so drift is detected in days. Third, keep a single definitions register that both implementations reference, so a change is at least visible in one place.
The freeze is the one people resist and the one that matters most. A legacy platform under active development cannot be strangled, only chased.
Know when the pattern is wrong
Strangling is not always the right answer, and consultancies that only sell one approach will not tell you that.
It is a poor fit when the legacy estate is small. Below a certain size, the overhead of running two platforms, maintaining reconciliation and managing the abstraction exceeds the cost of a careful rebuild. There is a threshold, and it is lower than most vendors imply.
It is also a poor fit when the legacy platform is genuinely unstable. Strangling assumes the old system keeps working while you replace it. If it is failing weekly, you are not strangling, you are firefighting on two platforms simultaneously, and stabilising first is the correct sequence even though it delays the interesting work.
And it fits badly when the target architecture is fundamentally different in shape. Moving between similar warehouses is a strangling problem. Moving from a batch warehouse to a streaming-first architecture changes what consumers can ask for, which means there is no equivalence to reconcile against and the abstraction cannot hide the difference.
The honest version of the timeline
A strangler migration on a mid-sized estate is a multi-year commitment. The seam takes a quarter. The first domain takes another. Throughput then improves substantially, and the last few consumers take longer than anyone budgeted because they belong to teams with other priorities.
What you get in exchange is that at no point are you more than a few weeks from a working state, and at no point does the business carry a single-weekend risk. For most organisations that trade is clearly worth making. It is worth making it with the timeline stated honestly at the outset, rather than discovered in year two.
