Shopify Migration Checklist: 30+ Items Before You Cut Over

A Shopify migration is not a redesign with a new backend. It is a full platform swap where every URL, every customer record, every order, every subscription, every review, every redirect, and every third-party integration has to land safely on the other side. Do it well and your traffic, rankings, and conversion rate move across untouched. Do it badly and you lose six to twelve months of organic visibility while your CX queue fills with customers who cannot find their account, their subscription, or their last order.

This checklist exists because most migrations fail in predictable ways. Teams underestimate the redirect map. They skip the staging QA pass on tax and shipping. They flip DNS on a Monday morning and then spend the next three weeks firefighting indexation drops in Search Console. The 34 items below are the ones that actually matter, grouped into the phases where they need to happen. Work through them in order and the cutover becomes boring, which is exactly what a cutover should be.

If you want the deeper build context, our Shopify development service walks through the technical scope, and the platform migration hub covers Magento, WooCommerce, BigCommerce, and custom-stack moves end to end. For the SEO mechanics specifically, the Shopify URL structure best practices post explains why Shopify forces certain URL shapes and what that means for your redirect map, and fix Shopify indexation issues covers the post-launch diagnostics you will need in week two.

Pre-migration data prep

Data prep is where 60 percent of migration risk lives, and it is also the phase teams rush through because it feels administrative. It is not. Every decision you make here either reduces or multiplies the work of every later phase.

Start with a full product catalog export from the current platform. Not just the visible fields. Metafields, custom attributes, variant-level data, inventory by location, HS codes, country of origin, weight and dimensions, tax classifications, and any structured content attached to the product record. If your current platform stores subscription cadence or bundle logic on the product, export that too and map where it will live in Shopify.

Customer data is the second export. Pull every customer with order history, lifetime value, tags, marketing consent status, date of first order, and any segmentation you use for email. Order history matters because it feeds the welcome-back flow on the new store and because returning customers who cannot see their past orders will open tickets.

The third pre-migration artifact is the URL inventory. Crawl the current site with Screaming Frog or Sitebulb and export every indexed URL, every canonical, every status code, and every meta title and description. This becomes the source of truth for the redirect map. Do not skip product URLs that redirect to other products already. Do not skip paginated collection pages. Do not skip blog archive pages that show up in Search Console impressions even if you think nobody reads them.

With the URL inventory in hand, build the 301 redirect map. One row per old URL, one column for the new destination. Every row needs a destination, even if the destination is the homepage or a parent collection. Missing rows become soft 404s and soft 404s bleed rankings for months. For a mid-size catalog of 800 SKUs plus blog content you are typically looking at 1,200 to 2,500 redirect rows. Build it in a spreadsheet, validate it, then convert to the format Shopify accepts.

Preserve meta titles, descriptions, and H1 structures as-is during the migration. A migration is not the moment to rewrite title tags. If a title is 73 characters on the old site, keep it 73 characters on the new site, even if it truncates in the SERP. Change one variable at a time. Rewriting metadata during a platform swap means you cannot attribute ranking shifts to either cause.

Build and QA

The build phase is where the new theme comes together and the apps get installed. QA is where you catch the things the build phase missed.

Identify every app on the current platform and decide whether each one has a Shopify equivalent, a replacement, or needs to be rebuilt. Subscriptions are the highest-stakes decision. If you are on a legacy subscription platform, moving to Recharge, Skio, Awtomic, or Smartrr requires a data export from the old provider, a mapping of cadence rules, and a customer-facing communication about any changes to their portal login or billing descriptor.

Email platform continuity is the next big one. If you are on Klaviyo, confirm that the Shopify integration will map your existing lists, segments, and flow triggers. If you are moving email providers at the same time as the platform, do not. Stage that as a separate project after the store is stable.

Run the full checkout end-to-end on staging. Place a real order with a real card. Refund it. Place a subscription order. Pause it. Resume it. Switch the product. Cancel it. Test every tax jurisdiction you collect in, which means placing test orders with addresses in each nexus state. Test every shipping zone, including international if you ship international. Test Shopify Payments plus at least one fallback gateway so you have redundancy if Shopify Payments has an outage.

Analytics installation deserves its own QA pass. GA4 needs to fire on every key event: view item, add to cart, begin checkout, purchase. Server-side tagging through a GA4 measurement protocol endpoint or through Stape is now the default for any brand that takes iOS 14 signal loss seriously. Verify that purchase events fire with the correct revenue, currency, and transaction ID, and that you are not double-counting across the Shopify native pixel and the GTM pixel.

Sitemap and robots are the SEO plumbing. Shopify generates sitemap.xml automatically but you want to confirm it contains the URLs you expect, excludes the URLs you do not want indexed (customer account, cart, checkout), and is submitted to Search Console the day of launch. Robots.txt on Shopify can be customized through the robots.txt.liquid template, which you will need if you have specific paths to disallow.

404 monitoring is the fire alarm for your redirect map. Install an app or a server-side logger that captures every 404 and emails a daily digest for the first 30 days. Missing redirects show up here and you can add them before Google re-crawls and drops the URL from the index.

Review apps, loyalty programs, and any customer-facing data that lives outside the core Shopify record need their own migration plan. Okendo, Yotpo, Junip, and Stamped all support CSV import but the mapping between product IDs on the old platform and Shopify variant IDs is where things go sideways. Do the import on staging, spot-check 20 products, fix the mapping, and only then run it on production.

Go-live

Go-live is 48 hours of coordinated work that should feel routine if the earlier phases were done right.

Start 48 hours before cutover by lowering DNS TTL to 300 seconds. This means when you flip the A record or CNAME, propagation happens in minutes rather than hours. Take a full backup of the old platform, including database and files, and store it somewhere you can actually restore from. Do not trust the platform's own backup unless you have tested a restore inside the last 90 days.

Pick a low-traffic window. For most DTC brands in the US, that is Tuesday through Thursday between 2am and 6am Eastern. Avoid Mondays (weekend order backlog) and Fridays (CX coverage drops over the weekend). Avoid the week of a major promotion, the week before a major promotion, and the week after.

Flip DNS. Verify propagation with a tool like whatsmydns.net across at least six global regions. Place a test order from a clean browser session. Place another from a mobile device on cellular data. Place a third from a VPN in a different country if you ship international.

Keep the old store online and reachable via a subdomain like old.yourdomain.com for 72 hours. This gives you a fallback if something catastrophic surfaces, and it gives your CX team a way to look up historical order data that did not make the migration.

Update inbound links that you control. Affiliate platforms, press embargoes, paid ad destination URLs, email footer links, social bio links, and any integrations that point to specific URLs need to be updated to match the new structure. Redirects will cover the ones you miss but native URLs are always cleaner.

Post-launch monitoring

The first 30 days post-launch are where the work of the previous phases either pays off or surfaces as problems.

Day 1 through 7: monitor orders in real time. Compare daily order volume against the same day of week from the previous month, adjusting for any known seasonality. A dip greater than 15 percent that persists past 48 hours is a signal to dig in. Check the checkout funnel in GA4 for drop-offs at specific steps. Check the 404 log. Check Search Console for crawl errors.

Day 7 through 14: re-submit sitemap to Search Console if you have not already. Run a full SEO crawl with Screaming Frog on the new site and diff it against the pre-migration crawl. Look for missing pages, changed canonicals, and H1s or titles that drifted during the build. Validate Core Web Vitals with PageSpeed Insights and CrUX data across your top 20 landing pages.

Day 14 through 30: watch Search Console Coverage for indexation errors. Watch the Pages report for sudden drops in indexed URLs. Watch Performance for clicks and impressions by page, and compare to the same window pre-migration. Some fluctuation is normal. A sustained drop of more than 20 percent on a specific page template is a signal that the redirect or the canonical is broken.

At day 30, run a retrospective. What broke that you did not expect. What took longer than planned. Which checklist items did your team skip and regret. Document it and feed it into the next migration, because there is always a next migration.

Common mistakes

The patterns repeat across almost every migration we see.

Skipping the redirect map for blog content. Teams obsess over product URLs and forget that a mid-size brand has 200 blog posts pulling thousands of monthly impressions each. Every one of those needs a 301.

Rewriting metadata during the migration. The temptation is real. Resist it. Do the migration clean, then A/B test metadata changes once the new store has 90 days of baseline data.

Missing the tax configuration on the new store. Shopify's tax engine is generally correct out of the box but nexus rules change and exemption certificates need to be re-uploaded. A missed nexus state becomes a compliance problem four quarters later.

Underestimating the app rebuild time. If you are replacing five apps, assume each one takes a week of integration, QA, and documentation. That is five weeks of work before the theme is even finalized.

Flipping DNS on a Friday. You will spend the weekend with skeleton CX coverage while everything breaks. Tuesday morning at 2am local time is the answer.

Measurement

The measurement frame for a successful migration is simple. Organic traffic returns to within 5 percent of pre-migration baseline inside 30 days. Conversion rate on the new store matches or exceeds the old store inside 14 days. Core Web Vitals are in the green on mobile. Redirect coverage is at 100 percent of URLs that had organic traffic in the 90 days before cutover. Indexed URL count in Search Console is within 10 percent of the pre-migration count at day 30.

If you hit those five, the migration worked. If you miss one, you have a specific thing to investigate rather than a vague sense that something went wrong. The checklist above is the mechanism for hitting all five without heroics.

• Use this checklist as a working document, not a reference. Copy it, assign owners, and track completion.
• Do not rewrite metadata or redesign templates during the migration. Separate projects, separate variables.
• Lower DNS TTL 48 hours before cutover and keep the old store online for 72 hours after.
• Monitor Search Console Coverage and the 404 log daily for the first 30 days post-launch.