Cloud migration cutovers
Move a coherent capability before moving every endpoint
A phased migration works best when traffic and data ownership share a clear boundary. Choose a slice that can operate and recover independently.
In this article
Find a useful separation
A reporting capability may be easier to move independently than a transaction spanning order creation, payment and stock reservation. Start by examining the dependencies behind the user action.
A small endpoint is not automatically a small migration. It may read or change data owned by several parts of the old system.
Choose a capability whose source of truth, integrations and failure behaviour can be explained clearly. Record what remains in the old environment and how requests cross the boundary.
Put routing under controlled ownership
A routing layer can direct the selected capability to the new implementation while other functions remain on the old path. Keep route rules observable and reversible within the data constraints.
Do not shadow write requests into both environments unless the design explicitly prevents duplicate business effects. Comparing reads is different from performing a transaction twice.
For read comparisons, account for timing and data freshness so normal replication delay is not mistaken for a functional defect.
Prove the slice under real conditions
Release to a controlled scope and exercise the full workflow, including authentication and downstream integration behaviour.
Monitor calls that still cross back to the old system. Excessive coupling can make the new slice dependent on the very environment it is meant to leave.
Use findings to refine the next boundary rather than assuming every subsequent endpoint can follow the same schedule. Some capabilities will require a coordinated data transition.
Retire the old path deliberately
Once the new capability is accepted, prevent old writers from continuing through forgotten jobs or direct interfaces. Update operational tools and support documentation.
Keep the recovery strategy aligned with the current data owner. Routing back is only valid if the old implementation can operate on the authoritative state.
Remove the temporary routing and compatibility complexity when its purpose is finished, with a named owner and condition. A phased migration should gradually simplify the system rather than leave two permanent implementations with unclear responsibility.
Primary sources
Microsoft: Strangler Fig patternReferences checked 11 September 2026.