Shopify Migration Checklist: Everything to Do Before, During, and After Cutover

Export every URL that has inbound links or search traffic before you touch anything else. In a recent migration we ran, this URL audit took nearly as long as the build itself — the case study is at /work/dynamo-perfumes/. This is the single most important step in a migration and the one most often skipped or rushed. A URL that disappears without a redirect loses all the link equity that has been built up pointing to it — and that equity doesn't return just because the content is available at a new URL.

Use Google Search Console to identify every URL that has received impressions or clicks in the last 12 months. Export the complete URL list from your current platform (including products, collections, pages, and blog posts). Run a crawl of your current site with Screaming Frog or similar to catch any URLs that aren't in Search Console but might have inbound links from external sources. The union of these three lists is your redirect map input.

Also export, before touching anything: all historical orders with line items, all customer accounts with addresses and order history, all product data with variants and metafields, all blog posts with their full text and metadata, all images in their original resolution, and all active discount codes. These exports are your safety net. If anything goes wrong in the migration, these exports are what you restore from.

Every URL that changes needs a 301 redirect. Build the redirect map before migration starts, not after. The redirect map is a spreadsheet with two columns: old URL, new URL. For every product, collection, page, and blog post that exists on the current platform, you need to know what its URL will be on Shopify and whether that URL is the same or different.

Shopify's URL structure is mostly predictable: products live at `/products/[handle]`, collections at `/collections/[handle]`, pages at `/pages/[handle]`, blog posts at `/blogs/[blog-title]/[post-handle]`. If your current platform uses the same structure, most redirects are unnecessary. If your current platform uses a different structure — Magento's `/catalog/product/[id]`, WooCommerce's `/product/[slug]/`, or a fully custom structure — every URL is a redirect.

Pay particular attention to pagination URLs (`/collections/all?page=2`), filter URLs (`/collections/shoes?color=black`), and variant-specific URLs (`/products/shirt?variant=123`). These are often indexed despite not being canonical — they need redirects to the canonical version, not to 404.

The redirect map should be reviewed by both the SEO lead and the development team before migration begins. The SEO lead verifies that all high-traffic and high-authority URLs are accounted for. The development team verifies that the Shopify redirect limits won't be exceeded (Shopify caps redirects at around 100,000 for most plans — not a constraint for most stores, but worth knowing).

Shopify's native import tools work well for simple product catalogs. For complex catalogs — variants with metafields, products with custom attributes, large image libraries — a scripted migration via Shopify's Admin API produces more reliable results than the CSV importer.

Customer account passwords cannot be migrated. This is a security constraint — no platform will expose unhashed passwords for export. Plan for a password-reset flow at launch: an email to all existing account holders explaining the migration, with a password reset link. Send this email the day before DNS cutover so customers have the context before they try to log in on the new platform and find their credentials don't work.

Order history should be imported as archived orders, not as active orders. Shopify allows importing historical orders via the Admin API with a 'closed' status — these appear in customer order history and in your admin but don't trigger fulfillment workflows or notification emails. Verify that the import matches the source data exactly: line items, totals, tax amounts, fulfillment status, and tracking numbers where applicable.

Product images are often the slowest part of a data migration, both because of file size and because of the API rate limits on Shopify's image upload endpoints. Budget significant time (often several days for a catalog over 500 products with multiple images per product) and run image migrations in the background while other migration work proceeds.

Verify every critical path before going live. The most important items, in the order you should check them:

Checkout end-to-end: complete a full purchase with each supported payment method (card, digital wallet, COD if applicable) and verify the order appears in admin with correct details. Verify the order confirmation email is sent and contains correct information. Verify the inventory decrement happens correctly.

Email notifications: test every automated email (order confirmation, shipping notification, abandoned cart, password reset) for content accuracy, correct branding, and correct links. These are often the last thing tested and the first thing customers see.

Analytics and tracking: verify Google Analytics, Google Tag Manager, Facebook Pixel, and any other tracking pixels are firing correctly on all page types. Verify conversion events are recording. This is the step most frequently forgotten — and losing 3 weeks of post-launch analytics data is a significant cost.

Search and filtering: verify that your collection pages and search results return correct products, that filtering works correctly, and that sort orders match your merchandising intent.

Mobile checkout: verify the full checkout flow on a real mobile device, not just a browser's mobile emulation. Real device testing catches rendering and interaction issues that emulation misses.

Lower DNS TTL to 5 minutes 48 hours before the cutover window. This ensures that when you point DNS to the Shopify-provided IP, propagation completes in under 10 minutes for most users rather than the 24–48 hours it would take at standard TTL settings.

Schedule the cutover for your lowest-traffic window — typically 2–4am in your primary market's timezone. Have the complete team available: someone to manage the DNS change, someone monitoring the Shopify admin for incoming orders, someone monitoring the old platform to confirm traffic is dropping off, and someone available to communicate on any customer-facing channels if anything goes wrong.

The cutover sequence: verify the Shopify store is working correctly on the preview URL → lower TTL 48 hours before → at cutover time, update DNS A record and CNAME to Shopify's provided values → monitor DNS propagation with a global DNS checker → verify first live order on the new platform → keep the old platform accessible for 72 hours as a rollback option.

Do not decommission the old platform until 72 hours after cutover. In the event of a critical failure in the first 72 hours, having the old platform available is the difference between a difficult 72 hours and a catastrophic incident. The cost of keeping two environments running for three days is negligible.

The first 72 hours after a migration produce more useful signal about what's working and what isn't than any amount of pre-launch testing. The testing was done in a controlled environment; real customers, real devices, and real traffic always surface edge cases that weren't anticipated.

Crawl the new site immediately after launch with Screaming Frog or similar to verify that all redirect rules are working, that there are no 404 errors on high-traffic pages, and that the canonical tags are correctly set on all page types. A launch crawl takes 20–30 minutes for most stores and catches redirect gaps that would otherwise take weeks to appear in Search Console.

Monitor Search Console for crawl errors in the first 48 hours. Google typically recrawls a site within 24–48 hours of detecting a DNS change. The first crawl report after migration will show any 404s that need additional redirects.

Verify that all integrations are processing real orders correctly. Email marketing, loyalty programs, review platforms, and logistics integrations all need real order data to confirm they're working — staging environment testing with test orders doesn't catch all production configuration issues.

Don't make significant layout or content changes in the first week. Let the dust settle, let Google re-index the redirected URLs, and let the analytics data accumulate before making decisions based on it. The temptation to iterate immediately is understandable, but changes in the first week create noise in the data that makes it harder to understand the migration's baseline impact.