Why data feels like the hard part, and isn’t
Product, customer and order data has a clear source and a clear destination, a schema on each end, and tooling built specifically to move it — whether that is Shopify’s own migration apps or a bespoke script against the Admin API. It is genuinely fiddly work, particularly around metafields, variant options and historical order states, but it is bounded and testable in a way that makes it feel like the main event.
URL structure has no such tooling by default. Every platform generates its own URL patterns for collections, pagination, filtering, blog content and account pages, and none of it maps cleanly onto Shopify’s conventions. That mismatch is exactly where organic search visibility lives or dies, and it rarely appears on a data migration checklist because it is not, strictly speaking, data.
The result is a familiar pattern: the migration goes live on time, the store functions correctly, the team celebrates a smooth cutover, and organic traffic quietly halves over the following month as search engines encounter thousands of URLs that now 404.
The URLs people forget
Product and collection URLs get mapped because they are the obvious candidates — someone builds a spreadsheet of old-path to new-path and calls the redirect work done. What gets missed is everything around the primary pages, which is often where a disproportionate share of earned links and long-tail search traffic actually lands.
- Paginated collection pages and sort or filter query parameters that search engines have indexed independently
- Legacy blog and article paths, especially ones with external backlinks accumulated over years
- Filtered collection URLs that earned links from press or affiliate content
- Image and asset URLs referenced directly from external sites, forums or image search
- Account, policy, store-locator and other ‘boring’ legacy pages that still carry indexed weight
Test the map, not the spreadsheet
A redirect map is a hypothesis until it has actually been crawled. Run a full crawl of the old site before cutover, capturing every URL search engines are aware of — not just the ones in the current sitemap, since sitemaps often omit exactly the long-tail pages most at risk.
Then replay every one of those URLs against the staging environment post-migration and assert on both the HTTP status code and the final destination after redirect chains resolve — not merely that a rule exists in the configuration. It is common to find a redirect rule that is technically present but never fires because of a precedence conflict with another rule, and the only way to catch that is to actually request the URL and check what comes back.
Redirect chains deserve particular attention. A URL that redirects three times before landing on its destination is a real cost to crawl budget and to user-perceived speed, and platform migrations are notorious for accumulating chains as old redirects from a previous migration get layered under new ones nobody bothered to collapse.
Watch the first fortnight
Cutover is not the finish line, it is the start of the period where the actual damage — or lack of it — becomes visible. Monitor crawl stats, index coverage reports and live 404 logs daily for at least two weeks, and treat every unexpected 404 as a defect with a named owner rather than noise to be reviewed at the next weekly sync.
It is worth setting an explicit alert threshold — for example, more than fifty new 404s logged from referrer traffic in a 24-hour window — that pages someone rather than waiting to be discovered in a monthly report. Search engines re-crawl at their own pace, and a gap left unaddressed for two weeks can take considerably longer than two weeks to recover once fixed.
The teams that come through a migration with organic traffic intact are, without exception, the ones who treated the fortnight after go-live as an active monitoring period rather than a victory lap.