The most dangerous sentence in IT: “We'll switch to the new system over the weekend.” If it fails, the company stands still on Monday. The strangler pattern is the more boring — and incomparably safer — road.
How the old system gets strangled
An API layer goes in front of the old system and all requests flow through it. Then functions move to the new solution one by one: orders this month, warehouse the next, invoicing after that. The old system keeps running alongside until only an empty shell remains — which you switch off without drama.
What that means in numbers
Migration takes longer — typically 9–18 months instead of “one weekend”. But the risk of an outage is close to zero, the team learns the new system gradually, and every phase delivers value immediately rather than at the very end. Cash flow is spread out: you pay per module, not half a million up front.
When a big bang is actually fine
The strangler pattern is not dogma. For a small system with a handful of users and no round-the-clock operation, gradual migration is needlessly expensive — a one-off weekend swap makes sense and saves months. The line is simple: the more an hour of downtime costs and the more systems depend on the old one, the more the boring, safe road pays off. For manufacturing, e-commerce or logistics, a big bang is almost always a mistake.
The hidden enemy of migration: data, not code
Most projects fail not on rewriting functions but on data. Twenty years of records are full of duplicates, invalid formats and “temporary” fixes that stayed forever. So we migrate data in batches with validation and, for a while, run the old and new systems side by side comparing results until we are sure. A clean cut-over with no silent data loss is harder than the code itself — and that is where most of the risk hides.
The first step is always the same: a dependency audit — what actually touches the old system. Ours takes 48 hours and produces a map, a migration order and a fixed price for phase one.