Replacing a working system in a single cut-over is the highest-risk change an architecture can make, because every capability moves at once and going back means going back on all of them. The alternative is to put something in front of the old system that every caller now goes through, so that routing becomes a decision you can make per capability. Then move one capability at a time: build it in the new system, point the facade's route for that capability at the new implementation, watch it, and leave the old code in place until you are sure. The old system shrinks as its remaining responsibilities do, which is where the name comes from. Three things make it work and are worth naming, because a migration usually fails on one of them. Callers must go through the facade, or an unrouted caller keeps the old path alive forever. Each capability must have an owner for its data, because two systems writing the same records is the hard case and needs its own answer. And every move must be reversible by changing the route back. It is slower than a cut-over and it costs you a period of running both. What it buys is that no single step can lose everything. You can now plan a replacement as a sequence of small, individually reversible moves.
The Strangler Fig pattern is an incremental migration strategy for replacing a legacy system in which a reverse proxy is placed in front of the existing system, and functionality is migrated to a new…