Shopify migration checklist: before, during and after the move

A migration is not a single date but three phases that build on each other. Preparation decides how much has to be improvised later. The build phase decides whether sign-off is meaningful. The follow-up decides whether visibility and revenue stay stable after go-live.

The most common reason for a slipped date is not technology but unclear ownership. Legal pages, payment contracts, tax rates and product data all have owners outside the agency. If they only surface during the build, the project waits on approvals nobody scheduled.

It starts with a complete list of every URL that exists today. Complete means merged from the sitemap, a crawl, the server logs and Search Console. Each of these sources knows URLs the others do not, especially old campaign pages and discontinued products.

That list is then weighted. What matters is which URLs receive organic traffic, which serve as landing pages for paid campaigns and which carry external links. A URL with neither traffic nor backlinks needs no dedicated target. One with both needs a deliberate decision, not an automatic rule.

In parallel you take stock of the data. Products, variants, categories, customers, order history, discount codes, subscriptions, reviews and editorial content all belong in one list with volumes and source. Anything missing here shows up during the first test purchase, when the date is already close.

A data export says nothing about data quality. Sample the export for empty required fields, duplicate SKUs, products without images, categories without products, and variants that the old system maintained as standalone articles. These cases determine how much manual work the catalog build carries.

Assortments with many attributes are a special case. Shopify supports three option dimensions per product. Anything beyond that has to be decided before the import: what becomes a variant, what becomes a metafield, what becomes its own product. Changing that decision afterwards costs more than making it upfront.

Integrations deserve the same care. For every connected system, note which object moves in which direction and which system wins in a conflict. ERP, carrier, accounting, newsletter, returns portal and review platform are the ones most often overlooked until late.

Changing platforms almost always changes URL patterns. Without redirects, every old address loses its history: rankings, backlinks and bookmarks lead nowhere. The redirect map is therefore not a follow-up task but a table that grows alongside the build.

Every old URL gets exactly one target, and that target serves the same content or the closest equivalent. A blanket redirect to the homepage is not a solution but a signal to search engines that the content is gone. For discontinued products, the category is the more honest target.

Redirect chains are the second mistake. If old addresses already pointed at other old addresses before the move, the migration turns them into multi-hop chains. Resolve them in the map so every source URL lands directly on its final target rather than travelling through intermediate stops.

Tracking and consent are usually addressed too late. Decide upfront which events you measure, how they are collected and which of them require consent. A consent banner added two days before go-live changes your numbers exactly when you want to compare them against the old store.

Legal pages are not copied over, they are reviewed again. Imprint, privacy policy, cancellation terms, terms of sale and shipping information all describe concrete processes, and those change with the platform. Switching payment methods or carriers changes the content of your mandatory disclosures too.

Operationally, payment and shipping methods need to be settled early because they involve contracts and approvals. Add a freeze rule: from a fixed date, no new products, categories or content are created in the old system, otherwise the data set drifts apart while the migration runs.

The build order is not a matter of taste. The data model comes first, then the catalog, then the templates, and only at the end the finishing work on content and campaign pages. Starting with design means building templates for products whose structure is not settled yet.

Test data is useful for building against something early, but sign-off needs real data. A catalog of three sample products hides exactly the cases that create work later: very long titles, products without images, sold-out variants, bundles and items with unusual tax treatment.

The build belongs on an environment that cannot be indexed. Shopify stores are password protected before they are published, and that protection stays in place until cutover. Remove it early and the half-finished new store competes with the old one for the same content.

Walking through click paths is not enough. Sign-off only becomes meaningful once real orders run through the system, with a real payment, a real invoice, a real shipping label and a real return. Only that run shows whether store, ERP, accounting and carrier mean the same order number.

Involve the people who will run the store afterwards. Customer service, warehouse and accounting spot problems the project team never sees, because they know the everyday case. A sign-off staffed only with developers and project leads mostly finds issues that were already known.

Before the date itself comes the cutover rehearsal. The whole sequence is practised once: freeze, final data sync, DNS change, removing the password protection, activating redirects, running the check routine. The rehearsal also records who performs which step and under which condition you roll back.

Right after the switch, the redirect map is checked against reality rather than against the spreadsheet. Take the list of the most important old URLs and actually request them. Check the status code, the destination and whether an intermediate hop appeared along the way.

Then come the search engine tasks: submit the new sitemap, check the robots file, sample the canonical tags and prepare the new property in Search Console if the domain changes. Keep 404 monitoring active from the same hour, because the first gaps show up immediately.

Operational checks run in parallel. Reconcile inventory against the leading system, follow the first real orders through to the ERP, verify payouts and compare tracking against the old baseline. Treat any tracking discrepancy as a measurement error until the opposite is proven.

Metrics move after a platform change, and not every movement is a problem. Search engines need time to process new addresses, so visibility and the number of indexed pages fluctuate for a while. Expect a dip followed by recovery, not a sustained decline over weeks.

It becomes critical when errors touch the purchase process itself. Those cases take priority over any SEO question, because they cost revenue immediately and because they usually trace back to a single configuration: one payment method, one tax rate, one shipping zone.