The strangler pattern, minus the theory

The strangler pattern gets described as if the hard part is philosophical - commit to incrementalism and the rest follows. It does not. The hard part is deciding where to cut, and that decision is specific to your system in ways no diagram captures.

Cut where the data is already separate

The best seams follow existing data boundaries. If a subsystem owns its tables and nothing else writes to them, you can move it behind an interface and migrate it independently.

If four subsystems write to the same table, that is not a seam. It is a knot, and pretending otherwise produces a migration that has to be finished in one release - which is a big-bang rewrite wearing a costume.

Move reads before writes

Reads are reversible. Point a read path at the new system, compare its output against the old one in production, and you learn whether your reimplementation is correct while the old system is still authoritative.

We usually run this comparison for weeks and log every divergence. On one data project it surfaced two unit-conversion bugs that no test caught, because no test knew the source data could arrive in those units.

Keep the old system running longer than feels necessary

The temptation once the new path works is to decommission immediately. Resist it for one full business cycle - a month-end, a quarter close, whatever your system's rare-but-critical moments are.

Those code paths run infrequently, which means they are the least exercised and the most likely to be subtly wrong.

What this costs

Incremental migration is slower in raw engineering time than a rewrite that goes perfectly. Rewrites do not go perfectly. You are trading a small guaranteed cost against a large probable one, and the business keeps running throughout.

That trade is almost always worth making, and it gets more worth making the more revenue depends on the system you are replacing.