Use the checklist to plan what must move, what should change and how the team will know the new store is ready. Data, URLs and daily operating tasks need separate acceptance checks; one successful import cannot validate all three.
Inventory the current platform
Document the data and behaviors the business relies on before deciding how Shopify should replace them. Hidden rules often sit in extensions, spreadsheets and staff routines.
- Products, variants and structured attributes
- Customers, orders and legally required history
- Content, URLs and organic entry pages
- Scripts, apps and connected systems
Map destinations and ownership
For each source domain, define the Shopify destination, transformation, source of truth and reconciliation method. Record what will not move and why.
- Native Shopify data models
- Metaobjects, metafields and files
- Replacement apps or custom integrations
- Redirect and canonical rules
Rehearse the migration
Run repeatable test migrations against realistic data, then validate relationships and business meaning rather than counts alone.
- Variant and inventory relationships
- Customer and order history
- Redirect behavior and analytics continuity
- Operational handoffs and notifications
Control the cutover
Agree content freeze, final delta, DNS, rollback and support responsibilities. Test real customer and staff journeys before the launch window begins.
- Named go or no-go owners
- Final reconciliation criteria
- Monitoring and incident paths
- Post-launch priority and support plan
Create a migration acceptance register.
Keep the migration register separate from a design feedback list. For each data or workflow area, record its source, destination, transformation, check, owner and launch-blocking failures.
- Catalog and inventoryReconcile products, variants, prices, images and location stock. Inspect representative complex records, not only totals, and document exclusions or data that needs an archive.
- Customers and historyConfirm which customer, order and account information can move through the selected method. Record any customer actions needed after launch and how staff will access retained history.
- URLs and search entry pagesMap existing valuable URLs to relevant destinations. Check redirects, internal links, canonical tags and indexability on the final domain; do not send unrelated retired pages to the homepage.
- Cutover and observationSet the content freeze, final data changes, launch owner and stop criteria. After release, review orders, integrations, crawl errors and important landing pages against the agreed baseline.
A redirect map reduces avoidable broken journeys; it cannot guarantee that rankings remain unchanged. Search engines need time to discover and process changed URLs.
Google’s site-move guidance explains URL mapping, permanent redirects and monitoring. Keep those checks in the migration plan alongside the store’s operational acceptance criteria.
Choose the migration sequence from data and launch risk.
| Approach | Best fit | Watch carefully |
|---|---|---|
| Direct import | The catalog is small, relationships are simple and a supported import can be reconciled without extensive transformation. | Counts alone are insufficient; sample business meaning, URLs, media and relationships after import. |
| Staged migration | Data, storefront, apps and operations need rehearsal while the current platform remains active. | Plan repeatable scripts, delta handling, reconciliation and decision owners for each rehearsal. |
| Controlled cutover | The final delta, domain, redirects, analytics and operational switch must happen within an agreed window. | Define freeze rules, go or no-go criteria, rollback limits, monitoring and post-launch ownership. |
Catch migration gaps before the cutover window.
- Treating a successful product import as a completed migration.
- Discovering undocumented extensions and staff spreadsheets during cutover.
- Mapping fields without defining source of truth or reconciliation.
- Launching redirects, consent and analytics without testing real entry pages.
- Changing data, storefront, integrations and operations without named go or no-go owners.
Questions to resolve before implementation.
- Which source data and history must move for legal or operating reasons?
- Which URLs receive organic traffic or external links?
- What behavior currently lives in extensions, scripts or manual routines?
- How will every migrated domain be reconciled?
- What is the final-delta and content-freeze process?
- Who owns launch monitoring, rollback decisions and post-launch exceptions?
Questions about this decision.
How early should Shopify migration planning begin?
Begin before theme or app decisions are fixed. Data, URLs, integrations and operating rules can materially change the responsible storefront architecture.
Can all historical data move into Shopify?
Not always in the same shape or through standard imports. Legal, service and reporting needs should determine what moves, where it lives and how staff access it.
How are SEO risks reduced?
Inventory valuable URLs, map destinations, preserve meaningful content and metadata, test redirects and canonicals, maintain sitemap and analytics continuity, and monitor after launch.
Should apps be selected before data mapping?
Usually no. First define the workflow and data ownership, then evaluate whether native Shopify, an app, an integration or custom work is the responsible destination.
What should a migration rehearsal prove?
It should prove repeatability, transformations, relationships, reconciliation, timing, operational handoffs and recovery—not only that files can be imported.
What belongs in the cutover plan?
Content freeze, final delta, DNS, redirects, analytics, smoke tests, owners, go or no-go criteria, rollback limits, communications and post-launch support.
Prepare the migration before committing to a launch date.
Share the current platform, catalog complexity, integrations and the URLs that receive important traffic. We can identify the data rehearsal, storefront work and cutover responsibilities needed for a credible scope.