Every step of a Shopify migration, in the order you have to do them

How to use this checklist

This is a working document, not a reading experience. Paste it into whatever your team runs tickets in and give every phase one named owner. Migrations rarely fail on the hard technical steps. They fail at the handoffs.

The phases run in this order because they depend on each other. You cannot build a redirect map without a URL export, or test a checkout before the gateway is live. Only the theme build and the data clean safely overlap, and only with separate owners. Every date counts backwards from cutover, the moment DNS points at Shopify. Almost everything before that is reversible. Very little after it is.

Most of what goes wrong is a known step somebody deferred because it was invisible on launch day. Here is what those cost once the store is live.

Phase 1: the pre-migration audit

The audit produces two artifacts: a list of everything the old store does, and a list of every URL it answers on. Everything later gets checked against those. Teams who skip the audit do not find out what they missed. Their customers find out for them.

Do this four to six weeks out, before any design is signed off, because the audit is what tells you whether the design is buildable on Shopify at all.

1. Crawl the live site and export every URL returning 200, with its title, canonical and template type. Crawl again logged in if you have gated content.
2. Export 12 months of landing pages from analytics and 16 months of pages and queries from Google Search Console. Search Console keeps only 16 months.
3. Export the backlink profile and note which specific URLs earn the links. Those redirect targets stop being negotiable later.
4. List every app, plugin and scheduled job, with what it does and whether a Shopify equivalent exists. Flag the ones with no equivalent now, not in week six.
5. List every system that reads or writes to the store: ERP, 3PL, accounting, PIM, email, reviews, loyalty, tax. Name a contact at each vendor.
6. Document the checkout in detail: custom fields, validation rules, shipping logic, discount types, B2B price lists.
7. Record the baseline. Sessions, conversion rate, revenue, average order value, organic clicks, top 50 landing pages by revenue. Nobody remembers to take one, and without it every post-launch argument is unwinnable.
8. Decide what is not moving. Dead posts, discontinued products, campaign pages from 2022. Cutting them shrinks every later phase, and they still need redirects.

Phase 2: data export and cleaning

This phase always overruns, for a boring reason: the data on the old platform is worse than anyone believes. Duplicate SKUs, products with no image, two customer records sharing an email, descriptions carrying markup from three different editors. Import it dirty and you clean it in production, where every fix is a live change.

Check the catalogue against the platform limits before exporting anything. A Shopify product can carry up to 2,048 variants, raised from 100 in October 2025, but still supports only three option types. If your Magento catalogue uses five configurable attributes, that does not map. Either the product splits or the attributes move to metafields, and that decision belongs in writing before the export.

1. Export products, variants, inventory, customers and orders in full, then keep an untouched copy somewhere the migration team cannot edit.
2. Clean product data in a spreadsheet rather than the admin. Normalise handles, strip inline styles, fix image filenames, resolve duplicate SKUs.
3. Map anything that breaks the three-option limit to metafields, and note which theme sections have to render them.
4. Split CSVs under 15 MB, the import ceiling for product, inventory and customer files, and import in batches so a failure traces to one batch.
5. Import in the order the data model expects: products, then customers, then orders, since orders reference the other two.
6. Plan the order history import as an API project. The admin imports products, customers and inventory from CSV. Historical orders come through the Admin API or a migration app.
7. Accept that passwords do not migrate. Shopify cannot import password hashes, so every account arrives disabled and each customer sets a new password from an invite.
8. Deduplicate the customer list against your email platform before anyone sends a single invite.

Budget for this properly. Past a few thousand SKUs the data clean is usually the longest task in the project, longer than the theme build, and it gets estimated by whoever has looked at the data least. Get a real number before you commit to a launch date: take one hundred products, clean them end to end, time it, and scale that against the catalogue.

Phase 3: environment and theme build

Build somewhere that is not live and not indexable. A Shopify storefront with the password on is not crawlable: search engines see the password page and nothing behind it. That is what you want during the build, and what ruins a launch when somebody forgets to switch it off.

The theme is the part clients watch, so it collects the attention and carries the least risk. The risk sits in the parts nobody demos.

1. Keep the storefront password on for the whole build. Development stores are password protected by default and cannot be opened until the store is on a paid plan.
2. Use a Git-backed theme workflow with a preview theme. Nobody edits the live theme through the admin code editor, at any point.
3. Define metafields and metaobjects before building sections against them. Renaming a metafield that 4,000 products reference is a migration inside your migration.
4. Build every template the audit found, not only the ones the design covers: search results, empty cart, 404, account pages, gift card, policies. The 404 matters most, since it catches every redirect you miss.
5. Rebuild transactional email templates and authenticate the sending domain early. Verification waits on DNS records that take time to propagate.
6. Recreate discounts, shipping rules, tax rules and markets. Shopify Markets handles currency, domains and regional pricing as configuration rather than code, which is why it gets left until launch week.
7. Load real content. Long titles, missing images, 40-character variant names. Placeholder copy hides layout bugs until the day they matter.
8. Set title tags, meta descriptions and structured data as you build. Retrofitting 2,000 title tags after launch is its own project.

Phase 4: URL mapping and redirects

This phase decides whether the migration costs you organic revenue. The Shopify URL structure is fixed. Products sit at /products/handle, collections at /collections/handle, articles at /blogs/blog-handle/article-handle, static pages at /pages/handle. You do not get to keep /shop/category/product-name.html. Every old URL needs a destination or an explicit decision to let it die.

Map page by page for anything that earns traffic or links. Pattern rules are fine for the tail and unfit for your best 200 pages, because a pattern rule is how a whole category ends up pointed at the homepage and quietly stops ranking.

1. Build one sheet with a row per old URL: old path, current status, new path, reason. No blank destinations.
2. Redirect to the closest equivalent page. Bulk redirects to the homepage get treated as soft 404s and pass nothing.
3. Cover the types people forget: paginated collection pages, filtered and sorted variants, internal search URLs, old sitemap paths, product feeds, and image paths earning image search traffic.
4. Include non-HTML assets. PDFs, size guides and spec sheets get linked from forums and get zero attention in a migration.
5. Import redirects under Content, Menus, URL redirects. Standard plans hold up to 100,000 redirects and Plus up to 20 million, so the ceiling is rarely the constraint.
6. Import in batches of around a thousand so failed rows stay findable, then re-export and check the count.
7. Write and queue the verification crawl before cutover. Redirects can only be confirmed on the live domain, so it runs the moment DNS moves.
8. Whenever a handle changes after launch, leave the create a URL redirect option ticked. Clearing it is one of the most common self-inflicted traffic losses on Shopify.
9. Keep the old platform reachable, or keep its URL export forever. Once it is off, the only record of what existed is Search Console, and that record expires.

Phase 5: apps, checkout and integrations

Apps are where migration budgets go to die. Every app on the old platform has an internal advocate, and a good share of them do something Shopify now does natively. Walk the audit list and force one of three answers on each: replace, rebuild, drop.

Checkout is the piece you control least and the piece with a real deadline attached. Shopify replaced checkout.liquid and additional scripts with checkout extensions. Plus stores had to move their Thank you and Order status pages by 28 August 2025, and stores on other plans have until 26 August 2026. If your launch lands near that date, anything rebuilt as a script tag on those pages is work you will do twice.

1. For each app, name the replacement, the person configuring it, and the date it is done by. No entry means the app is dropped.
2. Install as few apps as the business can live with. Every one adds storefront JavaScript, and the ones injecting on every page show up later in your field performance data.
3. Rebuild checkout customisations as checkout extensions rather than scripts, whatever your current plan still allows.
4. Reconnect analytics deliberately: GA4, ad platform conversion tags, and the customer events pixels in the admin. Verify with a live test order you refund afterwards.
5. Remap ERP, 3PL and accounting integrations to the new store IDs. Old product and order IDs do not survive, so anything keyed to them needs rebuilding.
6. Start subscriptions early. Contracts depend on stored payment tokens, and moving those between vaults is a PCI-governed process rather than an export. Shopify documents migrating payment methods as an assisted path. If it does not happen, subscribers have to re-enter card details, which is where a subscription base gets destroyed.
7. Confirm tax configuration against real orders in every region you sell to. Tax is the failure that loses money quietly for months.
8. Have the plan paid and the gateway live before QA. A checkout with no live gateway cannot be tested.

Phase 6: pre-launch QA

QA in the last 72 hours, on the store you are actually launching, with the data you are actually launching. Not a copy. Every defect found here is cheap. The same defect found on Tuesday morning costs orders and costs judgement, because people decide badly while a live store is broken.

Run it as a checklist with named testers and a pass or fail against each line. A browse-around is not QA.

1. Place at least five real orders through the live gateway: single item, multi-item, discounted, gift card, and one you refund. Check the confirmation email, packing slip, ERP record and accounting entry for each.
2. Test on the devices your analytics reports, in roughly the proportions it reports. Most stores are majority mobile and most QA happens on a desktop.
3. Walk every account flow: register, log in, reset password, view order history, edit saved addresses. Migrated customer data breaks here first.
4. Validate structured data and title tags across 20 URLs covering every template.
5. Crawl the preview store for broken internal links, orphan pages, missing alt text and accidental noindex tags.
6. Reconcile inventory against the source of truth on the morning of launch, not the week before.
7. Test the failure states: 404 page, empty search results, out of stock product, cart holding a sold-out item.
8. Sign off in writing, per phase owner. If nobody signs, nobody owns it at 2am.

Phase 7: DNS cutover

Cutover is fifteen minutes of work followed by a day of waiting. Do it on a Tuesday or Wednesday morning, when traffic is low and your team plus every vendor is reachable. Never on a Friday. Never in the week before a peak trading period.

Lower the TTL on the records you are about to change at least 48 hours ahead, so the old value has expired everywhere before you touch anything. That one step decides whether a rollback takes minutes or takes a day, which is why teams under pressure skip it.

1. Confirm the plan is paid, the gateway is live, and the storefront password is ready to come off.
2. Point the apex A record at 23.227.38.65 and delete other A records on the root. Add the AAAA record 2620:0127:f00f:5:: and the www CNAME to shops.myshopify.com. Some regions get a different A record value, which is also valid.
3. Leave the TTL at your provider default once the change is in. Shopify advises against changing it, and activation can take up to 48 hours.
4. Remove the storefront password only after the domain resolves to Shopify and the site checks out. Leaving it on is how a store spends launch week invisible.
5. Load the redirect file if it is not in yet, then run the queued crawl. Fix 404s in the first hour, not the first week.
6. Submit the sitemap in Search Console. Shopify generates /sitemap.xml automatically as an index of product, collection, page and article sitemaps, and updates it as content changes.
7. File a Change of Address request only if the domain itself changed. A replatform on the same domain does not use that tool, and Google wants the request on every verified variant of the old property, www and non-www included.
8. Leave robots.txt alone unless you have a reason. The Shopify defaults are maintained by Shopify, and a robots.txt.liquid template added in a hurry is how a directory stays blocked for a year.
9. Verify SSL on both apex and www, and confirm both resolve to one canonical host.
10. Tell support, the warehouse and whoever runs paid media. Somebody always finds out from a customer instead.

Phase 8: the first 48 hours and the 30-day check

Launch is where you start finding out what the audit missed. For two days, watch orders rather than rankings. Rankings move slowly and noisily. Orders tell you within an hour that checkout is broken.

The first 48 hours

1. Compare hourly order volume against the same weekday last month. A twenty percent gap holding for three hours is a bug, not variance.
2. Watch Search Console coverage and your 404 log. New 404s in the first two days are redirects you missed, and they are still cheap.
3. Confirm each integration wrote a real record: first order in the ERP, first shipment at the 3PL, first invoice in accounting.
4. Send account activation emails in batches, watching bounce and complaint rates between batches rather than after all of them.
5. Put one person on support triage whose only job is escalating anything that sounds like a checkout problem.

The 30-day check

1. Compare organic clicks, impressions and average position against the baseline at page level. Site totals hide the pages that died.
2. Re-crawl and diff the URL inventory against the old export. Anything with no live destination is still leaking.
3. Check Core Web Vitals against field data rather than lab scores. New themes and new apps change what real users get.
4. Reconcile a full month of revenue, refunds and tax against the same month on the old platform.
5. Only now decommission the old platform, keeping a read-only archive of its database and original images.

Expect movement in both directions. A project that changes URLs, templates and page speed at once will not leave rankings exactly where it found them, and the honest measurement point is 90 days, not 7. Read your own Search Console data against the baseline you recorded in the audit, at page level, at 30 days and again at 90. Without both reads you cannot separate a normal recrawl wobble from a redirect that never fired.

Common questions

How long does a Shopify migration take?

The build is rarely the constraint. A small catalogue with no custom integrations can move in a few weeks. A catalogue with tens of thousands of SKUs, a subscription programme and an ERP connection takes months, and most of that time goes on data cleaning and integrations rather than design. Estimate from the app list and the data quality, not from the number of page templates.

What should I do first when migrating to Shopify?

Run the audit before anything else. Crawl the existing site and export every live URL, pull 16 months of pages from Google Search Console before that window rolls forward, export the backlink profile, and list every app and integration with a named owner. Those exports are what the redirect map, the QA plan and the post-launch comparison are all built from.

Will I lose organic traffic when I migrate to Shopify?

Some short-term movement is normal, because URLs, templates and page speed change at once and Google has to recrawl the whole site. Sustained loss usually traces back to one cause: an incomplete redirect map. Page-level redirects for everything that earns traffic or links, plus a crawl of old URLs on cutover day, separate a two-week dip from a permanent one.

Can I import my order history into Shopify?

Not from the admin. Shopify imports products, inventory and customers from CSV, but historical orders have to come in through the Admin API or a migration app that uses it. Plan it as a development task with its own timeline, and import products and customers first, since order records reference both.

Do customers have to reset their passwords after a Shopify migration?

Yes. Shopify cannot import password hashes from another platform, so migrated accounts arrive disabled and each customer activates through an invite email and sets a new password. Send those invites in batches after launch, clean the list against your email platform first, and expect a temporary rise in support tickets about logins.

When is the safest time to switch DNS to Shopify?

Early on a Tuesday or Wednesday, in your lowest traffic window, with the whole team and every vendor contactable. Lower the TTL on the records you are changing at least 48 hours beforehand so a rollback is fast. Avoid Fridays, avoid the week before a sale, and do not cut over while a paid campaign is mid-flight.