Imagine a fitness-club business where members can pause a subscription only by asking a receptionist. The company wants that journey in its customer portal. Rewriting attendance, billing and account management would be expensive, but adding a form on top of the old application will not resolve unclear dates, cancellations and manual corrections.
The Strangler Pattern transfers capabilities to a replacement gradually while the rest of the business keeps using the existing system. The useful outcome is a part of the product that becomes easier to change. Counting new services proves little: a modern facade can preserve every old dependency behind it.
Choose a slice that can actually be finished
Subscription pauses have a complete lifecycle: eligibility, requested dates, approval, changes to the subscription period and cancellation. The customer form is only one entry point. Reception staff, scheduled jobs and support tools can affect the same operation.
The first slice need not cover the whole company. It does need a verifiable result and someone accountable for it. Martin Fowler’s description of incremental replacement explains the alternative to waiting for a complete rewrite. The approach does not require turning every capability into a microservice.
Before writing the replacement, identify the constraint: coordinated releases, unclear rules, an obsolete library or records that need manual repair. Moving the same logic to another platform will not resolve an ownership dispute. Sometimes extracting a module inside the existing application is a useful first step.
Find the changes that bypass your new route
A facade can send pause requests to the replacement while routing other work to legacy. The Azure Architecture Center describes this arrangement. But a router only controls traffic that passes through it. An overnight job writing directly to subscription tables can still apply the old rules.
Inventory every source of changes, including imports, administrative screens and message replays. Each needs an agreed path to the operation’s owner. A temporary translation layer can preserve a useful contract for older callers without exporting all the legacy model into the replacement.
The facade itself needs ownership. A routing error must not alternate one request between two executors. Check permissions, operation identifiers, deadlines and failures. Automatically retrying an update against legacy after the new service times out can execute the same business action twice.
Copying records does not transfer write authority
While historical data is copied, the old application continues accepting changes. A one-time export therefore cannot establish the final state. The team needs a way to catch up, measure lag and reconcile results. AWS’s migration guidance addresses coexistence and synchronisation during the transition.
Compare business facts, not just row counts. The club needs the correct remaining days, active pauses, cancelled requests and subscription associations. Two databases with equal numbers of records can still disagree about whether a member may enter tomorrow.
For each operation, decide which system can commit the authoritative change. Writing to both databases independently introduces a failure window: one write succeeds and the other fails. Change propagation, a controlled pause in writes or another explicit coordination mechanism may be appropriate. “Write everywhere” is not a recovery design.
Who finishes requests already in progress?
A pause request may still await approval when routing changes. Either the old implementation finishes it or the new one takes over its state and responsibility. Both choices require identifying unfinished work and knowing where the next step will arrive.
Routing can be associated with a request rather than chosen again at every call. But leaving old requests on legacy forever is not a retirement plan. Some will stall or return after a correction. Set an owner and a procedure for resolving these exceptions, or a handful of forgotten cases may keep the entire old platform alive.
Comparing both implementations on the same inputs can help, provided the comparison cannot affect customers. Two calculations are one thing; two commands extending a subscription are another. The candidate path needs its real write and notification effects disabled or isolated.
Rollback may expire before the migration ends
Before the replacement writes new state, returning traffic to the old implementation may be straightforward. Once it writes something legacy cannot interpret, recovery may require conversion or a forward fix. Application rollback and data reversibility are separate checks, as Amazon Builders’ Library explains.
The plan should identify the last safely reversible step, who decides what happens afterwards and what members see during recovery. A confirmed pause cannot simply disappear because restoring yesterday’s code is convenient.
Retire the old capability, not just launch the new one
Check for remaining callers, unfinished jobs and support procedures that still depend on legacy. The new team must be able to find historical decisions and recover its service. Then remove obsolete jobs, credentials and integrations. A read-only archive may remain without keeping the old transaction-processing path alive.
Temporary architecture has a bill: two operating environments, reconciliation, support training and changing boundary contracts. A small isolated component may be cheaper to replace in one controlled step. For an incremental migration, fund the finishing work too. For the club, completion means that members can manage pauses and the previous capability is genuinely switched off—not that another portal has joined the permanent support inventory.