A strangler migration progressively replaces an existing system by routing selected requests or responsibilities to new implementations behind a controlled boundary. It differs from a single cutover because responsibility moves in increments while the old and new systems coexist.
The facade is the routing mechanism. Replacement is the transfer of behavior. Retirement is the removal of dependencies after that transfer. Treating these as separate milestones prevents a new interface from being mistaken for a completed modernization.
Establish the routing boundary
The approach requires entry points that can be identified and controlled. Interactive requests are only one class. Batch jobs, direct database readers, file consumers, and internal calls can bypass a front-door facade.
An inventory of those entry points establishes which work can actually move through the proposed boundary. A request that never reaches the facade cannot be redirected by it. A replacement plan must therefore account for bypass paths rather than assuming that all activity uses the new interface.
Initially, a facade can route to the existing implementation. This establishes a consumer contract before changing the behavior behind it. Contract checks and consumer trials then provide a reference for later transfers.
Move a coherent responsibility
An increment should have a defined business result and the state needed to produce it. Replacing a screen while leaving its validation, updates, and exception handling distributed across both systems creates a different boundary from replacing the whole operation.
Suppose a new implementation handles order lookup while the old one still owns order updates. The source of authoritative data and the freshness visible to the lookup must be explicit. Moving the read path does not establish a second authoritative writer.
Each increment needs acceptance for its inputs, outputs, permissions, errors, and data effects. Its scope also identifies which old responsibility becomes removable. Without that removal, successive increments can add components while preserving the full original dependency set.
Coexistence is an operating state
Both implementations need maintenance, monitoring, deployment, and incident handling during migration. Shared identities, databases, and external services can require coordinated changes even when the routing boundary appears independent.
Transactions crossing the boundary require particular attention. A successful action in one implementation followed by failure in the other leaves a business state that neither routing rule resolves alone. The design needs a defined completion or recovery disposition for that state.
The operating team must also distinguish faults in the facade, old implementation, new implementation, and synchronization path. A generic success or failure indicator conceals where responsibility currently sits.
Routing reversal is not data rollback
Reversing a route changes which implementation receives subsequent work. It does not undo committed target writes, restore a removed schema, or reconcile transactions created since the switch.
Before the new path accepts writes, a return to the old path can have a smaller state-recovery burden. After new writes occur, the old implementation needs a compatible and reconciled account of those changes if it is to resume authority.
A recovery plan therefore separates routing, data, and external effects. It identifies the conditions under which reversal remains feasible and the point at which forward recovery is the supported response.
Completion and suitability
A strangler migration completes when the selected replacement scope is accepted and the corresponding legacy dependencies have been removed. A permanent facade over an unchanged backend is encapsulation, which can be a valid outcome but is a different one.
The approach is unsuitable where requests cannot be intercepted, required state cannot be separated at a viable boundary, or the organization cannot sustain coexistence. Those conditions do not prove that a single rewrite is preferable; they change the alternatives that require investigation.
The fixed mechanism is progressive transfer of responsibility through a controlled boundary. The size of increments, deployment shape, and final architecture vary with the actual system and the business operations that can be separated.