Replatforming
Part of Replatforming an online store
Setting a rollback plan for an ecommerce platform change
Set rollback triggers, order ownership and a viable traffic return path before changing ecommerce platforms.
A rollback plan must state when the new store stops taking orders, where customers go next and how accepted orders are accounted for. Returning to the old storefront does not reverse payments, stock changes or messages made on the new one. Define the decision while both systems and their operators remain available.
Set triggers and decision rights
Name a cutover lead, a payments and orders lead, a technical operator and a customer-service contact. One person must have authority to hold an affected selling path, repair the new store while it stays live or return traffic to the old store.
Agree observable triggers: a required payment path failing, accepted orders missing from the fulfilment queue, incorrect saleable stock or important pages becoming unreachable. State who verifies each trigger and what evidence they need.
A full return is viable only if the old store can still accept the intended orders and the team can reconcile activity on the new one. If neither system can safely accept an order, pause the affected path and give customers a clear status.
Record before cutover / Recovery use
- Last source order and first destination order
- Defines the change boundary
- Payment, stock and fulfilment owners
- Helps prevent duplicate action
- Old store’s current operating state
- Shows whether returning traffic is viable
- Routing procedure and operator
- Makes the traffic decision executable
- Customer message owner
- Keeps staff and shoppers informed
- Old-to-new URL map
- Helps preserve useful routes after either decision
Keep an order record across the boundary
Agree where staff will check an order accepted just before, during or after cutover. Match old and new order identifiers with the payment reference, stock or fulfilment action, current state and owner.
If traffic returns to the old store, do not recreate a new-store order there until payment and fulfilment have been checked. Decide how customer service will find purchases held in either system.
Rehearse a paid order awaiting fulfilment, an incomplete payment and an order requiring a refund or correction. For each, state which system holds the authoritative record and who closes an exception. Preserve the reconciliation record after the traffic decision.
Prepare the return path
Keep the old store and the access needed to operate it available through the decision window. Record the routing or domain settings that would change, who can change them and how the public result will be checked.
Confirm the old checkout, payment and delivery configuration before calling it a fallback. Plan how to prevent duplicate order feeds and customer notifications while both systems remain accessible.
If the destination is Shopify and a third-party domain is being connected, Shopify advises waiting 48 hours for DNS propagation to complete before making further changes. This is a connection caveat, not a measured rollback time.
Check the actual domain, DNS, certificate and routing arrangement. Do not promise that reversing a DNS edit will restore service immediately. A backup also cannot recover changes made after its capture unless another record or recovery process accounts for them.
Rehearse and close the decision
Walk through a simulated failure before changing public traffic. Have the decision owner identify the trigger, the orders lead identify affected purchases and the operator describe the action and its verification. Prepare the customer message and a criterion for reopening the new store.
After cutover, compare early live orders with payment and fulfilment records. If rollback is called, record the time and reason, route customers according to the plan and reconcile every order in the boundary record. Reopening the new platform requires the cause to be corrected and essential acceptance cases to be checked again.
