What to check before migrating an online store

Merchants usually arrive at a migration for one of three reasons: the current platform is end-of-life or the renewal has doubled, the theme has become so customised that nobody will touch it, or the business has outgrown what the platform does natively. All three are good reasons. None of them makes the migration itself safe. What makes it safe is knowing, before you commit, exactly what the old store is doing for you so you can make sure the new one does it too.

1. Find out what actually earns your traffic

Export twelve months of landing-page data from your analytics and sort by sessions and by revenue. Most stores find that a small number of pages carry a large share of organic traffic, and they are not always the ones you would guess: an old blog post, a collection with an odd URL, a product that ranks for a question people ask. Those URLs are assets. If they change without a redirect, the traffic goes with them.

At the same time, crawl the current site with any crawler tool and keep the full list of indexed URLs. The redirect map for the new store should cover every one of them, including the ones that embarrass you. A migration that only redirects the home page and the top ten products is where “we lost 40% of our traffic” stories come from.

2. List every kind of data, not just products

Products and images are the obvious part. Write down everything else that lives in the old platform and decide, line by line, whether it has to come across:

• Variants and options. How many, and do they map cleanly to Shopify's limits on options and variants per product? Bundles and configurable products often do not.
• Customers. Accounts can be imported, but passwords cannot. Customers will need to reset them, and you need a plan for telling them so it does not look like a phishing email.
• Order history. Staff want it for service; accountants want it for records. Decide how far back you need and whether archived orders are enough.
• Gift cards, store credit and loyalty balances. These are liabilities. Losing them creates angry customers and an accounting problem on the same day.
• Subscriptions. If you sell on subscription, the payment tokens often cannot be moved between providers. This can be the single hardest part of a migration.
• Reviews, blog content, pages, redirects already in place, discount codes in circulation. Each is small; together they are a week.

3. Audit the integrations and what each one really does

Every system that talks to the store needs a line in the plan: inventory or warehouse system, point of sale, 3PL, accounting, email platform, marketplace feeds, shipping label software, tax tooling. For each one, answer two questions. What data flows, in which direction, and how often? And does the new platform have a supported connector, or is it “there is an app” that turns out to be a one-way CSV export?

Make the call to each vendor before the quote, not after. “It integrates with Shopify” has meant anything from a maintained, bidirectional sync to a Zapier recipe someone built in 2019. The scoping session is where you find out which.

4. Check the theme customisations you have forgotten

Open the current store on a phone and go through a purchase as a customer. Then do it as staff: create a product, run a promotion, process a return. Note every behaviour that is not standard: the size guide pop-up, the postcode checker, the B2B price list, the “notify me when back in stock” button, the custom packing slip. Each one was built for a reason. Some reasons are gone; most are not. The new store needs a decision on every one, and a list made now is much cheaper than a complaint made after launch.

5. Decide the source of truth for stock before you move

If stock levels currently drift between the warehouse and the website, a migration will not fix that; it will copy it. Decide which system owns the number, how often the store is updated from it, and what buffer you keep on shared stock. Doing this first makes the integration part of the migration a known quantity instead of a surprise.

6. Pick the cut-over date from the trading calendar

Look at twelve months of orders by week and find the quiet period. Then check it against promotion dates, supplier deliveries, staff leave and any change freeze you have already told the business about. The cut-over wants a quiet week with people available to watch it. It does not want the fortnight before your busiest month, however keen everyone is to be on the new platform before the sale.

A sensible sequence for most retailers is to do a pre-peak checkout and speed check on the existing store so it trades well through the busy period, then migrate once the peak has passed and the numbers are in.

7. Agree what “done” means

Write down the tests that will be run on launch day: a real order with a real card and a refund, every shipping zone, tax display, a discount code, a gift card, an account login, the top twenty redirects, the sitemap submitted, structured data validated, and the integration round trip checked against the accounting system. If the list is written before the build, launch day is a checklist. If it is not, launch day is an argument.

What this costs if you skip it

The cheapest migrations I see are the ones where the merchant arrives with the landing-page export, the data list, and the vendor answers already in hand. The scoping takes an afternoon and the quote is accurate. The most expensive are the ones where the first time anyone discovers the subscription tokens cannot move is two weeks before cut-over. Checking is boring; it is also most of the value.