A migration rollback plan names the point where the team must stop and how it can restore customer service. “We have a backup” is incomplete if new orders, payments or DNS changes have already happened. Decide which changes are reversible, which need compensation, and who can make the call.
How to make the decision
List every cutover step in order: data freeze, final import, domain switch, redirects, payment activation, email changes and announcement. For each, record the old state, restore method, maximum safe delay, owner and evidence of success. Set go/no-go criteria before launch, including checkout, support access and inventory accuracy. Test a restore on staging. After first live orders, a full rollback may create conflicting records, so define a controlled forward fix and customer-support procedure. Keep credentials and backup locations with authorized operators, not in the public plan.
Worked example
Synthetic 10:00 cutover: product pages and checkout pass at 10:15, but order confirmation emails fail at 10:30. The team has a 45-minute decision window. A test rollback of the email configuration was rehearsed and restores the old mail route without reversing the whole store. The incident owner pauses marketing sends, fixes the route, verifies two test orders and records that no customer orders were lost. The plan avoids a dramatic full rollback for a narrow failure.
What to verify
- Is the last safe rollback point explicit?
- Are go/no-go thresholds written before launch?
- Has the restore path been tested?
- Who reconciles orders created during an incident?
Limits and ownership
Do not promise one-click reversal. Some payment, order, customer and DNS effects cannot be undone exactly; the plan needs reconciliation and communication routes.
What to hand over
Print a cutover decision sheet with the current checkpoint, last safe rollback point, transaction count and named decision maker. Store it with the incident runbook. Rehearse the decision in a tabletop exercise: the team should know who pauses ads, who contacts customers and who verifies the repaired store.
Common question
When should we choose a forward fix instead of rollback?
When a rollback would lose or duplicate live transactions, use the preapproved repair path and protect customer records first.
Next useful step
Use Handling Product URLs That Have No Replacement After Migration for the adjacent decision. For an implementation review, see Megvi’s ecommerce website development service and bring the source records, proposed checks and open exceptions.
Source checked 28 October 2026: Shopify Help Center: migration checklist. Check current platform settings before changing a live store or report.
The worked example is illustrative and is not presented as a Megvi client outcome.