Migrating a custom store to Shopify

Moving a custom store to Shopify is rarely difficult because of the products. It is difficult because of everything attached to them — the URLs search engines have indexed for years, customer accounts and their order history, the pricing rules nobody wrote down, and the integrations someone built in 2019 and left.

Plan for those and a migration is orderly. Plan only for the catalogue and you will spend the following month explaining a traffic drop.

What actually breaks?

What moves	Difficulty	What to watch
Products and images	Straightforward	Option structure has to fit three options
URLs	Hard	Shopify imposes its own paths — every URL changes
Customer accounts	Moderate	Passwords cannot transfer; everyone resets
Order history	Moderate	Imports as records, not as live orders
Pricing rules	Hard	Often undocumented and embedded in old code
Content and blog	Straightforward	URLs change again
Integrations	Varies	Whatever your ERP was talking to no longer exists

The URL row is the one that costs money, and it is the one most often discovered late.

Why are URLs the expensive part?

Because Shopify uses its own path structure and you cannot fully override it. Products live under one path, collections under another. Whatever structure your custom store used, the addresses change.

Every one of those old addresses may have accumulated years of search ranking, external links and bookmarks. Without redirects they return 404s, and the ranking is not transferred — it is discarded. Businesses that skip this reliably see traffic fall and reliably attribute it to the new design.

What to do before anything else: export a complete list of your live URLs, from your sitemap, your server logs and Search Console. Map every one to its new address. Anything with no equivalent goes to the nearest sensible page rather than the homepage — a redirect to the homepage tells a search engine the page is gone, not moved.

Do this as a spreadsheet before migration, not as remediation afterwards.

What happens to customer accounts?

They move; their passwords do not, because passwords are stored in a form that cannot be transferred between systems. Every existing customer will be asked to reset.

That is not a technical problem, it is a communication one. Customers who arrive to find their login rejected assume the site is broken. Tell them beforehand, explain why, and make the reset the first thing they see rather than an error message.

Order history imports as historical records rather than live orders, which is usually adequate — customers want to see what they bought, not to act on it. Confirm that expectation with whoever handles your support, because they will field the questions.

What about the rules nobody documented?

This is the part that extends a migration by weeks, and it is entirely predictable.

Custom stores accumulate logic: a discount for one customer type, free freight above a threshold that differs by region, a product that cannot be ordered with another, a tax rule for one state. Some of it is in code written by someone who has left. Some of it is in a database table nobody has looked at in years.

None of it appears in a requirements document, and all of it surfaces the week after launch when a customer notices their price changed.

Spend a week on this before scoping. Sit with whoever handles orders and ask what exceptions exist. Pull the last few hundred orders and look for prices that do not match the list. That exercise finds more requirements than any specification meeting.

What should you not migrate?

A migration is a rare opportunity to remove things, and most businesses waste it.

Discontinued products with no traffic. Categories nobody browses. Features built for a campaign that ended. Content written eight years ago that no longer reflects what you do.

Check traffic before deleting — a page with no internal links may still receive search visitors. But moving everything indiscriminately means paying to rebuild things nobody uses, and starting the new store with the old store’s clutter.

How should the switch itself be handled?

1. Build and populate on a Shopify development store, with the real catalogue rather than samples.
2. Load the redirect map before going live, not after.
3. Test checkout properly, including the awkward cases — freight rules, tax, a large order, a failed payment.
4. Tell customers about the password reset in advance.
5. Switch at a quiet hour, not on a Friday, and not during a campaign.
6. Watch Search Console daily for two weeks. A rise in 404s means a gap in the redirect map, and it is fixable if you see it early.

Expect a modest ranking dip for a few weeks even when redirects are correct. It usually recovers. A dip that does not recover is normally a redirect problem rather than a Shopify problem.

Common questions

How long does a migration take?

It depends almost entirely on catalogue complexity and undocumented rules, neither of which anyone can estimate before looking. The build is rarely the constraint; the discovery is.

Will we lose search rankings?

Temporarily, usually. Permanently, only if redirects are incomplete. This is the single highest-return part of the project and the one most often rushed.

Can we keep our existing design?

Broadly, through a custom theme. Whether you should is a separate question — a migration is a reasonable moment to reconsider a design built around the previous platform’s constraints.

What about our ERP integration?

It needs rebuilding against Shopify’s APIs. Scope this as its own piece of work rather than an afterthought — it is frequently the largest single item in the project and the one that delays go-live.

More on this: Shopify or custom build and deep catalogues on Shopify. See also eCommerce development.