Shopify Migration Checklist That Holds Up

A Shopify migration fails for boring reasons. A redirect map that missed the blog. A variant import that turned three sizes into three separate products. A tax rule that worked on the old platform and quietly stopped working on the new one. None of these show up on launch day. They show up two weeks later, when organic traffic is down, support tickets are up, and nobody can agree on who owns the fix.

This Shopify migration checklist is built around that reality. It is not a list of every task. It is a sequence of decisions that decide whether your store keeps earning during and after cutover. If you want a deeper companion read on scope and partner selection, our Shopify migration services playbook goes further into pricing and risk.

Treat Migration as a Constraint Problem, Not a Copy Job

Most checklists you find online frame migration as a content transfer. That framing is what causes the damage. The real work is preserving equivalence: URLs that resolve, variants that match, taxes that calculate, orders that sync, analytics that fire. Each of those is a constraint. Break one and revenue leaks.

Gartner’s widely cited figure is that around 83% of data migration projects miss budget or schedule. Shopify-specific numbers are softer, but the pattern is consistent. One detailed practitioner walkthrough by Ringly breaks the work into 47 separate steps across the full lifecycle, with the explicit point that the cutover is the middle of the project, not the end. Use that framing. Plan for the 30 days after launch as carefully as the build.

What founders consistently get wrong

• Variant data: Shopify’s option and variant model is stricter than WooCommerce or Magento. A CSV import that looks fine often turns size variants into separate products and silently drops color options.
• Redirects: Shopify forces /products/ and /collections/ URL patterns. Every legacy URL needs an explicit 301. Migration apps will not catch your blog posts, policy pages, or filter URLs.
• Apps: Replacing five native features from your old platform with five new apps usually slows the site, increases monthly cost, and creates conflicts in the cart drawer.
• Hypercare: Treating launch day as the finish line is the single most common reason migrations look fine on Monday and broken by Friday.

Phase 1: Audit, Backup, and De-scope Before Anything Moves

The first job is deciding what should not come with you. Most stores carry 20% to 30% legacy clutter: dead categories, expired promos, dormant customers, broken filters, products nobody has sold in three years. Migrating all of it just rebuilds an old problem on a more expensive platform.

Before touching Shopify, document what you have. A full export of products, customers, orders, content, and settings. A list of every active integration, every payment method, every tax rule, every shipping zone. A crawl of the live site with a tool like Screaming Frog to capture the complete URL inventory, including the URLs you forgot exist.

Then make three explicit decisions for each item: keep, merge, or kill. If nobody on the team can explain why a feature, app, or category exists, that is your answer.

If you can’t explain why something exists on the old store, don’t migrate it until someone defends it.

Phase 2: Map URLs and Plan SEO Before You Touch Data

SEO damage is the quietest failure mode in any migration. Checkout bugs get reported within hours. A 30% drop in organic sessions takes days to notice and months to recover.

The work here is not optimization. It is equivalence. For every URL on the old site, you need a destination on the new one. Product pages map to /products/. Categories map to /collections/. Blog posts, policy pages, landing pages, and any URL with backlinks or steady traffic all need explicit 301s loaded into Shopify before DNS changes.

The redirect map needs to include

• All product URLs, including discontinued products that still rank or hold backlinks
• Category and collection URLs, including filter variants if those rank
• Blog posts and content URLs, which migration apps almost always miss
• Policy, support, and static pages
• Any URL appearing in Search Console performance reports over the last 12 months

Preserve title tags, meta descriptions, H1s, image alt text, and canonical tags during the import. New Shopify themes overwrite these with defaults if you let them. Spot-check the top 50 traffic pages in Search Console within 48 hours of launch.

The same redirect discipline applies any time URLs change. If you want the broader framework, our notes on how to redesign a website without losing SEO apply directly here.

Phase 3: Migrate Data in the Right Order, with the Right Tool

The accepted sequence across every credible source is the same: products, then customers, then orders, then content, then navigation. Reverse the order and downstream systems break in subtle ways.

The tool choice matters more than founders expect. CSV imports work for simple product catalogs and basic customer records. They fail at orders, complex variants, metafields, and any catalog with characters that confuse spreadsheets. For anything beyond a small catalog, use a dedicated migration tool like Matrixify or LitExtension, or move data through the Shopify Admin API directly.

Run the import at least twice on a subset before doing it for real. The first run will surface variant collisions, malformed CSV rows, and image URLs that no longer resolve. The second run validates your fixes. A third run for full catalogs is normal.

Platform-specific quirks change the work. If you are coming from WooCommerce, plugin logic and subscription tokens are the hard part. Our WooCommerce to Shopify migration plan covers that in detail. If you are leaving BigCommerce, the URL structure and B2B parity are usually the bigger lift, which we walk through in the BigCommerce to Shopify playbook. For larger or older catalogs, the Magento to Shopify migration guide goes deeper into catalog limits and B2B logic.

Phase 4: Theme, UX, and the Temptation to Clone

The instinct is to rebuild the old store pixel-for-pixel. Stakeholders ask for it because the old design feels safe. Resist it. Shopify’s section-based theme architecture does not map cleanly to most legacy templates, and a forced clone usually produces a worse version of the old store on a more constrained platform.

Start with a premium theme that fits the brand and customize with discipline. Fully custom themes are worth the budget only when the business has clear, specific UX needs that themes cannot meet. For most catalogs, the right work is removing clutter, fixing navigation, and shortening the path from product page to checkout.

This is also the moment to fix issues you already knew about. When we worked with Broya Living on their Shopify storefront, the meaningful conversion gains came not from theme polish but from rebuilding product pages around the questions customers actually had and tightening the subscription path. A migration is one of the rare moments where that kind of structural change is cheap to make.

If your team is cleaning up product imagery before import, this practical guide to resize product images for ecommerce is useful for keeping file sizes and dimensions consistent across the catalog.

Phase 5: Audit Apps and Integrations Honestly

App sprawl is one of the most expensive mistakes new Shopify stores make. Every app is a recurring fee, a performance cost, and a potential conflict with another app or the theme. Migration is the cleanest moment to cut the list.

Split your current stack into must-have and nice-to-have. Must-have means revenue, operations, or compliance: payments, shipping, tax, reviews if they directly drive conversion, your email and lifecycle platform. Nice-to-have is everything else. Reinstall the must-haves first, see how the store performs, then add others only when there is a specific job to do.

For each app, ask:

• Does this cover the actual job, or just match a feature name?
• Can we get our data out cleanly if we leave?
• Who on our team owns it after launch?
• Can one app replace two or three?

Integrations need the same scrutiny, especially for stores with ERP, OMS, or PIM systems. Test the failure paths, not just the happy paths. What happens when an inventory webhook times out? When an order sync fails mid-flight? Without retry logic, idempotency, and a dead-letter queue, silent failures will desync inventory within days. If lifecycle and CRM tooling is part of the rebuild, this overview of marketing automation integration is a useful sanity check before you wire everything together.

Phase 6: Payments, Taxes, and Shipping Are Where Real Money Leaks

This is the part founders skim because it feels like admin. It is the part that decides whether checkout works on day one.

Set up payments early. Activate the gateway, do a real test transaction in live mode, and confirm the order creation, confirmation email, and financial reporting all behave as expected. If you use Authorize.net, PayPal, or any third-party gateway, follow the documented activation sequence and deactivate the old plugin only after a verified test order.

Taxes need a person, not just a setting. Shopify’s tax engine is simpler than what WooCommerce or Magento merchants often run. Document every tax override, nexus rule, and product-level tax exception from the old store, then rebuild them deliberately. Place real test orders to every region you sell into.

Shipping is where margin quietly disappears. Build realistic carts and run them through checkout. Heavy items, discounted bundles, multiple regions, edge-case combinations. The Fiore Designs project is a useful reference here: a flower business with zone-based delivery, time-window scheduling, and recipient zip-code logic that Shopify’s standard checkout could not handle out of the box. We worked through that on the Fiore Designs platform rebuild, and it is a good reminder that shipping setup is often where business logic and platform constraints collide.

Phase 7: Dress Rehearsal Before Cutover

A dress rehearsal is a full end-to-end run of the migration on a staging environment. Imports, redirects, apps, payments, shipping, content, analytics, all wired together as they will be in production. The goal is not to confirm that things work. The goal is to find the things that do not.

What we always test:

• Checkout under successful, failed, and edge-case payment scenarios, with and without discounts
• Navigation, breadcrumbs, search, collection filters
• Forms: contact, newsletter, account creation, lead capture
• Mobile behavior on cart, menu, and checkout
• Analytics events: GA4, Meta Pixel, server-side tracking if used
• Crawler scan with Screaming Frog for 404s, redirect chains, and metadata gaps

If anything fails in the rehearsal, fix and re-run. A launch on top of a rehearsal that you did not finish is just a launch with known bugs.

The Cutover Sequence and the First 30 Days

The cutover is a controlled window, not a single switch. Freeze content changes on the old store 12 to 24 hours before DNS. Run a final delta import of new orders and customers created during the freeze. Lower DNS TTL ahead of time so propagation is fast. Flip DNS. Confirm SSL, redirects, and checkout in production. Submit the new sitemap to Search Console.

Then start watching.

Make sure you have owners in place before you go live. Put one person on 404s and SEO, another to monitor payments and order sync, a third for support tickets and inventory. Leave it unnamed and you will see what is bound to happen: the developer assumes the marketer has an eye on SEO, the marketer is of the opinion the developer is on top of it, and that redirect map no one got around to finishing turns into a six-month headache for your traffic.

Then impose a change freeze on anything non-essential for a good four weeks. You don’t skip hypercare just because the store appears to be in order. That is when you find out if it can stand up to real traffic.

What Actually Predicts a Successful Migration

There is nothing exotic about this checklist. The teams that handle migrations well aren’t relying on some hidden API or proprietary tool. They are simply putting in the hours in the right sequence with realistic timelines and a hypercare period long enough for issues to show their face.

You will spot the same patterns in the ones that have trouble. A hard launch date that meant testing was curtailed. An ERP integration that only works on the happy path and fails quietly otherwise. A theme rebuild that has transplanted the old UX issues to a new platform. Or a redirect map left to the mercy of the migration app.

If you are in the planning stages and need a hand to determine what should be migrated, what to cut and what calls for a proper rebuild, our ecommerce migration services and Shopify development team are here for that. Come with your current store, your app list and the workflows you have come to distrust. We will put the revenue at risk first and work our way out from there.