Shop migration: preserve open orders and addresses
Plan where open orders will be completed. A worked example separates the order’s delivery address from the current customer profile.
Before copying data, decide which system will continue handling open orders. Payment status, delivery address and shipping instructions must belong to the relevant order. An imported customer list does not answer those questions on its own.
Assign open orders to a system
The following fictional migration makes a deliberate choice: orders already accepted are completed in the old system. After cutover, only the new shop accepts new orders. The old administration remains accessible for processing and enquiries. This approach requires the business to maintain its previous access and the necessary integrations.
Another migration could transfer open orders completely. That would require evidence that payment references, shipping states and all necessary functions work together in the target. Establish the chosen approach before importing data.
An order with two different address states
All details are fictional. There is no separately confirmed address change for the open order. North and South represent different delivery locations.
Record | State before migration | Agreed handling |
|---|---|---|
Open order | Payment confirmed, shipping pending, delivery location North | Complete in the old system for delivery to North; show only a reference in the target |
Current customer profile | Default delivery location South | Transfer for new address selection; do not rewrite the old order |
New order after cutover | Received in the new shop | Process in the new system |
If the transfer replaced North on the old order with South from the profile, this example run would fail its business requirements. The customer list could still have been imported completely. Here, acceptance requires the old order to retain its confirmed state and be processed only in the system assigned to it.
Shopify's documentation also distinguishes customer migration from historical orders, with different transfer methods. Its address interface separately describes the order's address state and later profile changes. Check that distinction in the source and target systems you actually select.
Follow the rehearsal through to processing
In a separate test environment, compare the source state with the transferred record and the subsequent processing view. Check the customer link, order address, payment status and shipping status. A historical reference displayed in the target must not initiate a new payment or additional shipment in this plan. Repeat the transfer and check whether the same source order is recognised.
Real customer notifications, payments and shipping instructions are prevented during the rehearsal. Record observed results separately from expected results.
Reconcile changes up to cutover
Addresses, payments or shipping states can change between the rehearsal copy and cutover. Define a cutover time with its time zone and reconcile those changes. Check transfers still waiting in the old ordering channel as well.
If the migration is aborted, order intake stops before another channel opens. New orders already accepted must remain unambiguously assigned to the system handling them. Access to old orders ends only once their continued processing and enquiry handling are possible through a verified route.
Sources
Read more
All articles
E-Commerce with ASES
Online shops, marketplaces and B2B portals