Migration
Part of Cloud migration planning
Choosing a rollback plan for a cloud cutover
Choose a migration rollback path based on traffic, write ownership and data state, then set decision triggers and rehearse both fallback branches.
Choose a cloud cutover fallback based on the point of failure and which system holds the latest accepted writes. Before the target accepts new data, returning users to a still-usable source may be possible. After target writes begin, the source may be stale. Redirecting traffic alone could then lose or split business records.
Mark when the data state changes
Document the workload's cutover sequence: control source writes, finish synchronisation, check the target, change traffic, allow target writes, then validate important actions. Mark the point when the target becomes the authoritative writer. Include background jobs and partner integrations, which may write even when users do not.
Agree with the business owner on a failed-cutover trigger, how it will be observed and the latest decision time. Triggers might include a critical action failing, missing data, unacceptable response time or a required security control failing. An instruction to “roll back if needed” gives operators too little to act on during an outage.
Key Cutover Decision Triggers
- Critical action failure
- Trigger for rollback
- Missing data after cutover
- Trigger for rollback
- Unacceptable response time
- Trigger for rollback
- Security control failure
- Trigger for rollback
Match the response to the actual state
| Cutover state | Possible response | Condition to establish |
|---|---|---|
| Source remains authoritative and traffic has not moved | Stop the change and continue on the source | Source still serves the action with the expected data |
| Traffic moved, but no target writes were accepted | Return traffic to the source | Source remains usable and compatible; no background or partner writes are missing |
| Target accepted new writes | Reconcile those writes before returning, or pause writes and repair the target | A single authoritative data state can be established within agreed limits |
These are choices, not guarantees. Even before target writes, a changed source configuration or unavailable old service can prevent return.
If both environments use the same authoritative data store, assess its actual state rather than assuming the source copy is stale. A phased traffic shift may make routing reversal faster when the application supports it, but write ownership still needs a clear rule.
If new data must return to the old environment, design and rehearse that path before cutover. An application-specific method might use reverse replication or a controlled export and import. Check schema compatibility, write order, duplicates and conflicting transactions. If reconciliation cannot meet the allowed interruption or data-loss limit, pausing writes and repairing the target may be safer than directing users to stale data.
Give operators a decision path
Name the decision owner and deputy, source and target operators, the traffic operator and the person validating the business action. Record the latest verified data point, replication state, backup availability and how to stop writes on the side that must cease accepting them.
Give significant steps a checkpoint, time allowance and evidence to capture. Before changing traffic, verify that the source can still serve the intended action. Afterwards, check user access, a critical read, a controlled write where safe, the resulting record and important integrations. A changed routing setting alone does not establish success.
Keep the old environment usable for the agreed fallback period, subject to data consistency. Define when it may be retired and who accepts the application and data checks. A powered-on server is not a fallback if its credentials, connections or data are unusable.
Rehearse the difficult branch
In a suitable environment, rehearse a failure before target writes and one after them. Time the decision, write controls, reconciliation or recovery, traffic change and completed business action. Record which branch was exercised, what was omitted and whether it met the agreed conditions. A tabletop review may find missing owners; it cannot prove a data path works.
The plan should tell operators whether they can return to a consistent source, continue on a repaired target or pause while data is reconciled. If none protects the required data and recovery limits, change the cutover method before scheduling it.
