A Shopify migration checklist that starts with the theme has started in the wrong place. The build is the visible part of a migration and rarely the risky part. The risk is in the URLs, and it is decided before anything moves.
Before anything: inventory every URL that earns something
Export your URLs from analytics and Search Console together, over at least twelve months, and sort by traffic and by impressions separately. You are looking for the long tail rather than the obvious pages — everyone remembers the top products; nobody remembers the guide written four years ago that quietly brings in visitors every week.
The list will be longer than you expect. Product pages, collections, blog posts, static pages, and then the URLs the old platform generated by itself: tags, filters, author archives, pagination. Some of these earn real traffic. All of them need a decision.
This inventory is the single most important artefact in the project. If a migration goes wrong, it goes wrong here.
Then: map every one of them to a destination
Every URL on that list gets a destination on the new store, before the build is finished rather than after. Most map cleanly. The interesting cases are the ones that do not.
Products being discontinued should redirect to the nearest equivalent or to their collection, never to the homepage. A mass redirect to the homepage is treated as a soft error, and it wastes the visit — someone arriving for a specific product and landing on your front page leaves.
Categories that are being merged need one destination each. Blog posts that are not being carried over should redirect to whatever replaces them, and if nothing does, that is a decision to make consciously rather than by omission.
Keep the map as a file you can re-run and verify, not as a set of changes made by hand in an admin panel. You will need to test it, and you will need to prove afterwards that it worked.
The data, in the order it has to move
Products first, with their handles decided deliberately — the handle becomes the URL and changing it later means another redirect. Then collections, then the content pages, then customers, then order history.
Customer passwords do not migrate between platforms, which surprises people every time. Plan the communication: customers will need to reset, and finding that out at checkout is a lost sale. Send it before the cutover, not after.
Order history matters more than it seems. Support depends on it, returns depend on it, and customers expect to see what they bought. Decide early whether it comes across or stays readable somewhere, because retrofitting it is unpleasant.
What to test on the staging store
Test the redirect map mechanically. Take the full URL list, request every one against staging, and confirm each returns a single redirect to a page that exists. Not a sample — all of them. This is the test that catches the chain nobody meant to create.
Then buy something. Actually buy it, with a real card, through every payment method you offer, including the awkward ones. Then refund it. Then buy something with a discount code, and a gift card if you sell them. Checkout is the only part of the store where a bug is immediately expensive.
Then test on a phone on mobile data, because that is how most of your customers will arrive, and a desktop preview hides a great deal.
The cutover itself
Pick a genuinely quiet window for your traffic, not a convenient one for whoever is doing the work. Have a rollback plan that someone has read, and agree in advance who decides to use it.
Keep the old store accessible but not indexable until you are confident. It is the fastest way to check anything you are unsure about, and it costs nothing to keep for a month.
Submit the new sitemap immediately and watch index coverage daily for the first fortnight. What you want to see is old URLs being crawled, followed, and dropping out as the new ones appear. That transition takes weeks and watching it is how you find the twelve URLs that were missed.
What to do with the old store
Do not delete it, and do not leave it running indefinitely either. The useful middle is to keep it accessible but not indexable for a month or two — long enough to answer the questions that come up, and short enough that you are not maintaining two stores.
Before it goes, take a full export you can actually read later: products, customers, orders and any content that did not come across. Keep the database dump somewhere durable rather than on the hosting account you are about to cancel. Nobody thinks they will need it, and the people who do need it need it badly, usually for a tax or dispute question a year later.
After: the two things that are usually skipped
Re-run the redirect test a month later against the live store. Redirects get edited, apps add their own, and a map that was perfect at launch is rarely perfect thirty days on.
And compare traffic by landing page rather than in total. Total traffic moves for seasonal reasons and will reassure you when it should not. Page-level comparison is what shows you the one collection that lost its position, which is still fixable in month one and much harder in month six.
If you are coming specifically from WooCommerce, the incompatibilities worth knowing about in advance are set out in what actually breaks in that particular move. How we run these end to end is on the migration page.
