Migrating to Shopify Without Losing Your Design

Platform migrations rarely fail on the parts people worry about. Product data transfers, orders import, customers arrive. The failures are elsewhere, and they are quiet.

They are the URL that changed with no redirect, the product schema that stopped being emitted, the internal links that were rebuilt from scratch and now point at different things, and the redesign that shipped in the same release and made all of it unattributable.

URLs are the largest risk

Every platform structures URLs differently, so some change is unavoidable. What is avoidable is a URL changing with nothing behind it.

Build a complete map from every existing URL to its new equivalent. Products, collections, content pages, and anything else that resolves today.

Include what you have forgotten. Old campaign pages, discontinued products, paginated archives, anything with an inbound link. Crawl your existing site rather than working from a sitemap, because sitemaps omit exactly the things that are easiest to lose.

Implement redirects on day one, not as a follow-up task. The window between launch and redirects is a window of 404s served to real traffic and to crawlers.

Verify after launch by crawling the old URL list and confirming each resolves to something sensible. This takes an hour and catches the omissions that are otherwise found by customers.

What gets lost invisibly

The category that separates a smooth migration from one that is argued about for months.

The unifying property is that none of these change how a page looks. A product page can be visually perfect, emit no schema, carry three H1s, link nowhere and have lost every alt text — and pass a design review comfortably.

Which is why the pre-launch check has to be a crawl, not a look.

Design: match first, improve later

The temptation is to treat migration as an opportunity. It is, and taking it immediately costs you the ability to understand what happened.

Migrate with the design as close to the original as practical. Not identical — platform differences make that impractical — but recognisably the same store with the same structure.

Confirm stability first. Traffic settled, conversion broadly in line, and nothing obviously broken anywhere.

Then redesign, as a separate project with its own before-and-after.

This is slower and less exciting. It is also the difference between knowing whether your new platform helped and having a permanent argument about it.

Where a full match is impossible, keep the structure even where the styling changes. Same page types, same information in the same order, same navigation logic. Structure is what carries the SEO and the user habits; styling is comparatively safe to change.

Data that needs deciding, not just moving

Some things do not map cleanly and need a decision rather than an import.

Variant structures differ substantially between platforms, and a naive import can produce a catalogue that technically works and is completely unusable in practice.

Customer passwords do not migrate between platforms. Every returning customer will need to reset theirs, which is both a communication task and a support load — plan for it deliberately rather than discovering it on launch morning.

Order history matters for support and for customer expectations. Decide how much comes across and where the rest lives.

Reviews are frequently tied to a platform or app and do not travel automatically. Losing years of reviews is a real commercial loss, and it is worth solving before launch rather than after.

Blog content and its URLs, which are frequently the most-linked pages on a site and among the most commonly overlooked in a commerce migration, because the project is scoped around products and everything else is treated as an afterthought.

Sequencing the launch itself

The cutover is a few hours where a great deal can go wrong, and most of the pain is avoidable with ordering rather than skill.

Have the new store fully built and tested on a staging domain first. Not partly built. Every template, real data, real content, walked end to end including a completed test purchase.

Freeze changes to the old store in the days before. A product added to the old catalogue during migration is a product missing from the new one, and nobody notices until a customer asks.

Launch when traffic is low, and when the people who built it are available. Friday evening is traditional and wrong — nobody is around for the weekend when something surfaces.

Redirects go live with the switch, not afterwards. This is the most common sequencing error and the most expensive.

Verify immediately, not the next morning. Crawl the old URL list, complete a real purchase, check analytics is recording, and confirm structured data is present. Half an hour of checks at the moment of switching catches things that otherwise run for days.

Submit the new sitemap and let Search Console know the structure has changed, so recrawling starts promptly rather than at its own pace.

Communicating it to customers

The non-technical half, which affects support load more than anything on the checklist.

Returning customers will meet an unfamiliar store, and if passwords did not migrate they will meet a login that does not work. Both are fine if expected and alarming if not.

Tell them beforehand, briefly — the store is moving, here is when, you may need to reset your password, your order history is preserved or is not. A short email prevents a large proportion of the support contacts a migration otherwise generates, and it converts a confusing experience into an expected one.

Brief your support team on what changed, what to expect, and where to check an order that was placed on the old platform. During the first fortnight they are the ones who will find the problems the checks missed, and they need somewhere to report them.

Expect a settling period

Traffic fluctuates after any migration, and the first weeks are not a verdict.

Agree in advance what would count as a problem, because otherwise the first bad week produces a panic and the first good one produces a declaration of success.

Some fluctuation is entirely normal, even in migrations where every single thing was done correctly.

Weeks to months is a realistic settling window depending on site size.

A sustained decline after several months is not settling. That is a specific problem, and the redirect map and structured data are where to look first.

Keep the old site accessible internally if you can, at least for a quarter. When something is missing, comparing against the original is far faster than reconstructing what it used to do from memory.

It is also worth resisting the urge to change things during the settling period. The instinct when traffic dips is to act, and acting adds variables to a situation you are still trying to read. Unless something is clearly broken, hold the store stable for the first month and let the numbers resolve. Changes made in week two to fix a dip that would have recovered on its own are how a straightforward migration turns into an unresolvable argument about what actually happened.

For redesign decisions after the migration settles, see storefront and design. The SEO checks are covered in SEO and AI search.