1. Build an inventory with owners
List the data, pages and processes the current store relies on. Products and images are only part of the picture: include specifications, variants, customer records, historical orders, editorial content, discount rules and integrations. Mark each item as moving, being replaced, being archived or needing investigation.
Give each decision an owner and an acceptance check. “Orders migrated” is less useful than defining which date range, fields and intended future use are required. Confirm what the chosen migration method supports before promising that every historical record will behave as it did on the old platform.
- Identify the source of truth for product and stock data.
- Record systems involved in payment, fulfilment and refunds.
- List country, currency and trade-selling requirements.
- Separate required launch features from later improvements.
Reference: Shopify: migration planning and methods
2. Test a representative catalogue sample
Choose products that expose differences in the range: a simple item, a product with several variants, a bulky item and one with detailed technical information. Map the source fields to the proposed store, import the sample and review it with the people who maintain the catalogue.
Check images, variants, prices, stock behaviour and the meaning of specification fields. A successful import message does not establish that the storefront is useful. Ask someone to choose the right variant and explain what is included using only the imported content.
3. Prepare and test URL destinations
Gather existing URLs from a crawl, the current sitemap and available search or analytics reports. Record the most relevant destination for important pages. Include collections and useful guides as well as products; those may be a visitor’s first introduction to the business.
Test redirect behaviour on the target platform. Shopify has reserved paths and other redirect constraints, so validate the actual mapping rather than assuming an imported spreadsheet will work in every case. Update internal links to final destinations and check for chains, loops and missing pages.
4. Rehearse the order journey
Write an acceptance script that follows an order beyond the thank-you screen. Cover the chosen variant, delivery method, payment state, inventory update, warehouse handoff and refund process. Use the test facilities agreed for each system and clearly separate test activity from live orders.
Include awkward cases your team actually encounters, such as an unavailable item, a bulky delivery or a failed payment. The person responsible for fulfilment should sign off the handoff they depend on. A developer seeing a successful response is not a substitute for that operational check.
| Checkpoint | Owner to agree | Evidence |
|---|---|---|
| Catalogue accepted | Merchandising lead | Approved sample and exceptions list |
| Order handoff checked | Operations lead | Recorded test order journey |
| URLs checked | Development lead | Redirect and missing-page report |
| Launch decision | Business owner | Signed-off checks and recovery criteria |
5. Agree cutover and aftercare
Document the final data sync, content freeze, domain change and treatment of orders arriving during the transition. Record who can make the launch decision and what happens if a critical check fails. Recovery needs to account for orders already placed, not just the ability to restore an old theme.
After launch, repeat the key buying and operational checks on the live store. Monitor missing URLs, order handling and available search data against the baseline. Keep a dated issue list with owners. A planned aftercare window helps the team distinguish defects from new requests.
Want a second pair of eyes?
Tell us about your products, your current store and what needs to work better. We’ll discuss a suitable scope before you commit to paid work.
Discuss your migration plan