Shopify Migration: Moving a Catalogue Without Losing Rankings or Orders

Introduction

The decision to move platforms is usually easy. What follows is a month of small questions nobody assigned: which fields map to what, who writes the redirects, and what happens to the reviews. The guides that rank for this are written by migration tools, and they stop where the difficult part starts.

This covers what actually moves, what quietly does not, how addresses decide whether you keep your rankings, and what to settle with your studio before anyone exports anything.

Key Takeaways

• Redirects Are The Whole Risk: Map every earning address before Spoke's Shopify development page work begins.
• Reviews Do Not Travel: Plan to move them separately or lose them entirely.
• Clean The Data First: Migration copies your mess across faster than you can.
• Watch The Option Limit: Products with many variants need restructuring before import.
• Freeze Orders During Cutover: Two live systems taking orders is the real disaster.
• Check After Launch, Not Before: The failures appear once real traffic arrives.

What Actually Moves, And What Does Not?

Twelve things travel in a migration and four of them need a separate plan. Naming the whole list early is what turns a month of surprises into a project with a schedule.

1. Products, with their descriptions, images and pricing.
2. Product variants, within the limits the new platform allows.
3. Collections or categories, usually needing to be rebuilt rather than copied.
4. Customer records, without their passwords.
5. Order history, which normally needs a dedicated tool.
6. Content pages such as about, shipping and returns.
7. Blog articles, if you have any worth keeping.
8. Discount codes, which are often recreated by hand.
9. Reviews, which almost never move on their own.
10. Subscriptions and recurring orders, which are their own project.
11. Images, which move but rarely keep their file names.
12. Addresses, which change shape completely and decide your rankings.

Items five, nine and ten are where budgets get missed, because a proposal that says catalogue migration rarely means any of them.

The Ones That Need A Separate Plan

Shopify's WooCommerce migration guide is specific about the gaps. Reviews cannot be exported or migrated and have to be brought across using a reviews app instead, the platform allows only three product options so anything with more will not import those options, and weights recorded in pounds have to be converted by multiplying by 453.6 before the file will make sense. Commercially, those three lines are a week of work hiding inside one bullet on a proposal, and a store with rich variant structures usually discovers the option limit at the worst moment.

1. Reviews: choose the app first, then export, because each one expects a different format.
2. Variants: restructure anything using more than three options before exporting.
3. Order history: budget for a tool or accept a read-only archive of the old system.
4. Subscriptions: treat as a separate migration with its own test window.

A pro tip: run a test import of fifty products before committing to the full file. Every mapping problem you will have shows up in those fifty.

What Happens To The Addresses, And Why Does It Decide The Rankings?

Every address changes, and each one you fail to redirect is a page that stops existing. This is the single largest risk in the project, and it is entirely preventable with work done before launch rather than after.

Shopify's migration guidance states it plainly: the new platform's link structure is likely different from your previous service, so old links to specific pages will not load, and it gives the example of a shipping policy page moving from one path to another entirely. It also warns that domains should be disconnected from the previous platform before transfer, or you may hit certificate errors. In practice that means the redirect map is not a launch-day task. It is a deliverable with an owner and a due date, built while the catalogue is still being prepared.

Building The Redirect Map

Start from what earns, not from what exists. A store with four thousand addresses does not need four thousand redirects written by hand; it needs the two hundred that carry traffic or links handled carefully, and the rest handled by pattern.

Shopify's redirect documentation covers what the platform allows: redirects can be imported in bulk from a spreadsheet, a store can hold up to 100,000 of them and considerably more on the highest plan, they begin working immediately once created, and certain reserved paths such as the cart and orders cannot be redirected at all. The consequence for planning is that volume is rarely the constraint. Knowing which old addresses mattered is the 

constraint, and that list has to come out of your analytics before the old site is switched off.

1. Export every address that received a visit in the last twelve months.
2. Export every address with a link pointing at it from another site.
3. Map each one to its closest equivalent, not to the home page.
4. Handle patterned addresses as a rule rather than one line at a time.
5. Load the map before launch, and spot-check the top fifty by hand.
6. Keep the old sitemap so nothing is forgotten after the switch.

What Breaks The Orders?

The cutover itself, when two systems are live at once or neither is. Rankings recover; a day of lost or duplicated orders does not, and this is the part customers notice.

1. Both stores accepting orders during the switch, so stock counts diverge.
2. Payment settings tested with a real card only after going live.
3. Shipping rates not matching what the old store promised customers.
4. Tax settings copied by assumption rather than checked.
5. Order confirmation emails still pointing at the old system.
6. Existing customers unable to log in, because passwords do not migrate.
7. Anything integrated with the old store, from accounting to fulfilment, still connected to it.

Spoke's ecommerce design work shows the kind of store this sequence protects.

What Does The Catalogue Need Before It Moves?

A clean-up, and it is the step most often skipped because it is unglamorous. Migration copies whatever you give it, so the mess arrives faster and costs more to fix on the other side.

1. Remove products you have not sold in a year and do not intend to.
2. Fix product titles so they read consistently rather than however each was typed.
3. Standardise option names, because colour and Colour become separate options.
4. Check every product has an image, and that images are a sensible size.
5. Fill in the fields that will matter later, including codes used for shipping.
6. Decide the collection structure now rather than recreating the old one by habit.
7. Write down which fields map to which, and have one person own that sheet.

A second pro tip: do the clean-up in the old system, not the new one. You will run the import more than once, and anything fixed after the first import has to be fixed again.

How Long Does A Migration Actually Take?

Anywhere from a fortnight to a quarter, and the catalogue size is rarely what decides it. What decides it is how clean the data is, how many integrations exist, and how quickly your team answers mapping questions.

1. Catalogue size, which matters less than people expect.
2. Data quality, which matters more than anything else on this list.
3. Number of connected systems, each of which needs its own test.
4. Whether order history is coming across.
5. How much of the design is being rebuilt at the same time.
6. How fast decisions come back when a field does not map cleanly.

Doing a migration and a redesign together is the commonest way to double a timeline. If the store is already under pressure, move first and redesign after, because then only one thing can be blamed when something breaks. A woocommerce to shopify migration handled that way is also far easier to test, since you are comparing like with like. Spoke's client work includes stores moved in that order.

What Should You Agree With The Studio Before Starting?

Six things, in writing, none of which takes more than a sentence. Every one of them is cheap now and expensive in week three.

1. Exactly which data is in scope, named item by item from the list above.
2. Who owns the redirect map, and when it is due.
3. Who cleans the catalogue, and in which system.
4. How the cutover runs, including whether orders are paused.
5. What is tested before launch, and by whom.
6. What support looks like for the fortnight afterwards.

Spoke's India Shopify team scopes migrations against that list rather than against a product count, which is why the number usually differs from a tool's estimate.

Conclusion

A Shopify migration rarely fails on the catalogue; it fails on the addresses nobody mapped and the cutover nobody rehearsed, and both are decided weeks before launch. Pull the list of addresses that earn, build the redirect map as a deliverable with an owner, clean the data in the old system, plan separately for reviews, variants and order history, and keep the redesign for afterwards. A woocommerce to shopify migration planned this way is a scheduled project rather than a month of surprises. If you are scoping one now, book a scoping call and bring twelve months of analytics rather than a product count.

The longer guides behind each of these steps sit on the Spoke blog.

FAQs

Q. Will we lose our search rankings when we migrate?

Ans. Not if the addresses are handled properly. Rankings follow pages, and a page that returns nothing loses what it earned. Export the addresses that received visits in the last twelve months, map each to its closest equivalent rather than to the home page, load the redirects before launch, and expect a short unsettled period afterwards while the change is recognised.

Q. Can we migrate reviews from our old store?

Ans. Not directly. Reviews do not export or import as part of a standard catalogue migration and have to be moved using a reviews app, each of which expects its own file format. Choose the app before you export anything, because doing it in the other order usually means exporting the data twice.

Q. Should we redesign the store at the same time?

Ans. Only if the current design is genuinely unusable. Doing both together doubles what can go wrong and makes every problem harder to diagnose, because you cannot tell whether a drop came from the move or the new layout. Move first, confirm the numbers settle, then redesign with a working baseline to compare against.

Q. How do we handle customer accounts?

Ans. Customer records migrate but passwords do not, so existing customers have to set a new one. Plan the email that tells them so, send it when the new store goes live rather than before, and make the reset route obvious on the login page. Support enquiries spike for about a week, so warn whoever answers them.

Q. What should we test before the switch?

Ans. Place a real order end to end, including payment, confirmation email, tax and shipping. Then check the fifty most visited old addresses resolve, that stock counts match, and that every connected system is pointing at the new store. Anything you skip here is something a customer finds for you within the first day.