Migrating to Shopify: the step-by-step plan from first audit to hypercare

Most migrations to Shopify do not fail on design. They fail on things nobody wrote down: a field that lands empty, a redirect that points to the homepage, an ERP connection that stops quietly on a Saturday. This guide is the plan we use as a Shopify Platinum Partner to move stores to Shopify and Shopify Plus, step by step, from the first question (should you move at all?) to the first ninety days after launch.

Short answer: a controlled move to Shopify has seven parts. Decide whether moving is the right call, plan backwards from your peak season, take a baseline before anything changes, sort everything you own into keep, improve or bin, map your data to the Shopify model and rehearse the import three times, build a complete redirect matrix, and treat launch as a one-hour event followed by ninety days of hypercare. Skip one and you feel it after launch, in traffic, orders or operations.

First: should you move at all?

A replatform is not a goal in itself. Before we scope anything, we ask three questions about the current platform, ideally in one meeting with twelve months of invoices on the table.

No red answers: stay, and invest in conversion, margin and marketing. One red answer: fix that one thing. Two or more: move, because two red answers reinforce each other and do not recover on their own. Ask the ceiling question to your merchandiser and marketer, not your developer. They hit the ceiling every week and have often stopped asking.

There are also three situations in which we advise against starting: in the middle of a rebrand, during an ERP change in the same quarter, and when there is less time until Black Friday than the build needs. If the decision itself is still open, read replatform, rebuild or hold first.

Plan backwards from your peak

Planning forwards always fits on paper. Counting back from a date that cannot move is the only calculation that holds. These are the phase lengths we work with for a mid-market catalogue with two integrations:

In practice: Black Friday 2026 is too close to migrate before it. If you want to sell on Shopify on Black Friday 2027 (26 November), you start in February 2027 and go live by late September. If your own peak or an end-of-support date comes earlier, count back from that date instead. And put a name on the code freeze, not just a date: someone has to be allowed to say no in week 46.

Step 1: take a baseline before anything changes

Without a baseline nobody can tell damage from noise after launch. A measurement taken after go-live is not a baseline. On one afternoon, over the same twelve months, we record eight readings:

1. Sessions per month (GA4, one source).

2. Organic clicks per URL over 16 months (Search Console).

3. Conversion rate per device.

4. Orders and average order value.

5. Return rate and the top three return reasons.

6. Discounts as a share of gross revenue.

7. LCP, INP and CLS per template (field data from PageSpeed Insights).

8. Revenue from email flows and their share of email revenue.

Export Search Console first. It keeps sixteen months and nothing older, so every month you postpone the export is a month of history gone. Reports on the old platform disappear with its licence.

Step 2: open every box before you pack it

Copying the old store one to one also copies its limitations. We give every page, template, app, flow, field, integration and URL exactly one label, with a name next to it, before scope freeze:

• Keep: it makes money now, or the law says you must retain it. Products, variants, stock, customers with consent, recent orders, URLs that earned a click in the last 16 months.

• Improve: it works, and Shopify makes it better. Templates that convert, lifecycle flows, product data, checkout and payments.

• Bin: nobody knows the last week it made money. Apps nobody opens, pages without sessions, old discount codes, fields nobody fills in.

An "improve" without one sentence on what better means falls back to keep. That is how twelve weeks become twenty. Ideas that arrive after scope freeze go on a parking lot with an owner and reopen two weeks after launch. New features come after go-live.

Step 3: map your data to the Shopify model

Migrations fail on data more often than on design. For every field, decide where it lands in Shopify, and ask one question: if this field arrives empty on day one, who notices, and in which report? If the answer is nobody, it stays behind.

Freeze your SKUs before the export: the SKU is the key for stock, ERP and every feed. And store the source system's IDs in metafields on products and variants, so a later ERP connection can still match records.

Some things do not simply move along:

• Passwords. You cannot migrate customer passwords. With Shopify's new customer accounts, customers sign in with a one-time code by email, so nobody has to reset anything. Legacy customer accounts have been deprecated since February 2026; if you still use them, every customer needs an invitation, which you plan as a campaign.

• Subscriptions. The contract lives in the app, the card with the old payment provider. Most subscribers have to authorise again: email them before launch.

• App-owned data. Reviews, loyalty points and gift card balances each need their own importer and owner. Gift cards cannot be edited or deleted after creation, so import them close to launch.

Step 4: rehearse the import three times

One import is a gamble. We run three:

1. Dry run in a development store: which fields arrive empty?

2. Dress rehearsal on the real store with the full data set: how long does the import take? The launch hour is planned on that number.

3. Delta after the freeze: only what changed. Size it in advance: orders per year ÷ 8,760 × hours frozen. A store with 126,400 orders a year and a four-hour freeze needs to move about 58 orders.

Agree the tolerance beforehand (customers and orders to the unit, gross revenue to the euro) and count five totals on both sides: customers, products, variants, orders and gross revenue. Malelions moved more than 180,000 customers from Lightspeed to Shopify Plus this way; see the Malelions case.

Step 5: give every object one owner

Most integration problems are ownership problems: two systems both believe they own the price. Before scope freeze, every object gets exactly one owner system. A typical split: the ERP owns master price, cost price and invoice; the PIM owns product content and media; Shopify owns orders, checkout, discounts, markets and B2B catalogues; the WMS owns stock per location; Klaviyo owns consent and flows.

Write every connection as a sentence: direction, frequency, and what happens when it gets stuck. A silent error in an ERP connection otherwise surfaces at month-end closing. Circle every object with two owners: that is your integration scope and your bug list, and the goal is zero before scope freeze. Check the connector of your ERP vendor in writing before scoping. Every connector is its own project; at OGÉR the scope included two or more ERP and WMS connectors next to Shopify POS. More on how we approach this in Shopify ERP integration.

Moving to Shopify Plus with custom checkout logic? Shopify Scripts stopped running on 30 June 2026. Discount, shipping and payment rules are now rebuilt as Shopify Functions inside checkout extensibility. Rebuild each rule on paper first and test it against the Functions limits before you sign.

Step 6: build a complete redirect matrix

Shopify uses fixed paths such as /products/, /collections/, /pages/ and /blogs/; only the last part of the URL (the handle) is yours. Almost every old URL therefore changes. Build the matrix from everything that ever returned a 200: a full crawl, the old sitemaps and Search Console.

• Sort by clicks, then by referring domains. Everything with a click or a link gets a destination chosen by a person; the rest follows pattern rules.

• Never send old URLs to the homepage: Google treats that as a soft 404. A discontinued product goes to its collection; search and filter URLs may simply return a 404.

• No redirect chains: old to new in one hop.

• Shopify only applies a redirect when the old path no longer exists as a page, and redirects with query strings do not always work as expected. Test them.

• The Change of Address tool in Search Console is only for a domain change. If you stay on the same domain, redirects and an updated sitemap do the work.

Keep the matrix as a separate document, with an owner who signs it off before launch. You will still need it months later for late 404s.

Step 7: go live in an hour, not a day

What goes wrong, goes wrong in the four hours around the switch. Our launch schedule:

• T−7 days: decide whether rollback is possible. The old store keeps serving, DNS TTL goes to 300 seconds 48 hours ahead, and no order reaches the new store that the old one cannot see.

• T−2 hours: go/no-go. One owner, four criteria, one decision.

• T−1 hour: the old store stops taking orders.

• T−0: switch the A record and CNAME, remove the password.

• T+15 minutes: one paid order per payment method, then a refund.

• T+60 minutes: 50 old URLs by hand, then the full redirect matrix.

• T+2 hours: compare counters with the same hour last week.

We roll back on four criteria only: the main payment method accepts nothing, orders do not reach the ERP, customer data leaks between accounts, or prices or stock are wrong across the catalogue. More than thirty minutes without a fix in sight triggers the rollback. Everything else is fixed forward. And we launch on a Tuesday morning, never on a Friday. We learned that one ourselves.

The first 72 hours and the first 90 days

A launch has worked when your customers' customers notice nothing. For 72 hours we compare five counters per hour with the same weekday a week earlier: orders per hour, checkout conversion, failed payments per method, 404s per 1,000 sessions and support tickets per 1,000 sessions. One counter out of line for thirty minutes is an incident; two at once sends us back to the rollback criteria.

Hypercare belongs in the contract, with hours and names. Ours runs for ninety days: in week one the build team stays on the project, in weeks two to four there is a fifteen-minute check on the counters every morning, and from week five it is weekly. When something dips, diagnose in this order before touching anything: tracking (orders in the admin against GA4), redirects (404s per 1,000 sessions), feeds (rejected items in Merchant Center and the Meta catalogue), payments (failures per method), season (the same weeks last year, never last month) and finally search (impressions per template, then clicks). Most dips stop at the first or second item.

Measure success on margin per visitor, comparing the same months this year and last year. Revenue and sessions can look fine while returns and discounts eat the profit.

What to watch per source platform

Comparing big bang, phased and parallel approaches? Our migration path comparison covers that choice.

Eight mistakes we see most often

Three of these we once made ourselves: going live on a Friday, rolling back on an undiagnosed number and promising a date we could not defend.

1. Copying the old store one to one.

2. Reopening scope after the freeze.

3. Going live on a Friday.

4. Skipping the baseline.

5. Redirecting old URLs to the homepage.

6. Rolling back on a number nobody diagnosed.

7. Promising a launch date you cannot defend.

8. Stopping at launch.

A useful exercise: read the list out loud to the project team and the budget holder. Everyone names the two this company is most likely to make. Those two get an owner and a date before the plan is signed.

Moving with a partner

This guide covers the full route, but every migration has its own complexity in data, connections and organisation. See how we run it on our Shopify migration page, including cases such as Malelions, OGÉR and Noordcode.

Sources

• Shopify Help Center: migrating to Shopify

• Shopify Help Center: URL redirects

• Shopify Help Center: importing customers

• Google Search Console: Change of Address tool