How do you modernize a system that cannot stop?

Choose a capability, not a screen

A customer portal looks like a neat first slice until one request crosses identity, pricing, account status and an overnight batch. A screen is a presentation boundary, not necessarily a business or data boundary. Trace a real request through callers, writes, jobs and external consumers before putting a date on the migration.

Pick one capability with a clear owner and an observable outcome. Document what it reads, what it changes, which systems still depend on it and who notices an error. A read-only feature can prove routing and deployment, but it cannot prove that write ownership or rollback will work. Be explicit about what the pilot does and does not establish.

Do not assume microservices are the goal. A modular component inside the existing application may provide a cleaner boundary with less operational overhead. Extract a service when separate deployment or scaling is valuable enough to justify another runtime, data contract and support obligation.

Introduce a route you can control

Microsoft's Strangler Fig pattern uses a façade to direct requests to legacy or new functionality while features are replaced incrementally. It also warns about the extra complexity of coexistence. The pattern helps only if the relevant requests can be intercepted and routed without breaking existing callers.

Before switching users, run the new path in a controlled comparison where the operation allows it. For a search view, compare result sets and ordering. For a balance view, reconcile values and timing. Agree on acceptable differences before seeing the results; otherwise every mismatch becomes a debate about whether the test was fair.

Move a limited slice of traffic, observe it, and keep a clear switch back. The façade itself needs monitoring and capacity planning because it becomes part of the critical path. Avoid a permanent maze of routing exceptions by recording which legacy endpoints will be retired and when.

Evidence: Microsoft Azure Architecture Center: Strangler Fig pattern

Who owns a record during the transition?

The routing diagram is not the data plan. Name the authoritative writer for each record during every phase. If two systems can update the same entity, define conflict handling before the first production write. If changes are copied asynchronously, decide how stale a read may be and how missed updates will be detected.

A traffic rollback cannot undo a payment, notification or record created by the new path. Identify irreversible side effects and rehearse reconciliation on a safe copy. In some migrations the honest recovery path is forward repair rather than instant rollback; communicate that boundary to operations before cutover.

• Name one authoritative writer per migrated record.
• Reconcile counts and business values, not only API responses.
• List batch jobs and integrations still reading the old path.
• Define the point after which recovery requires data repair.

Finish the first slice before multiplying it

An extracted capability still needs deployment ownership, monitoring, support instructions, security review and a way to correct bad data. Include these in the first estimate. A team that has moved code but cannot diagnose a disputed result has not finished the migration slice.

The first milestone is a capability that can be operated, verified and recovered. Use what it reveals about hidden dependencies to estimate the next slice. Keep a retirement list for old code, routes and jobs; otherwise temporary coexistence can quietly become permanent architecture.