Shopify Plus migration

Most migrations fail quietly. The store launches, it looks better than the old one, and three months later organic traffic is down forty per cent and nobody can say exactly when it started. That is almost always redirects, and it is almost always avoidable.

So the first thing worth saying about a migration is that the front end is not the risky part. Rebuilding a product page in Liquid is a known quantity. What takes the time, and what actually decides whether this goes well, is everything underneath.

What comes across

Products, variants, collections, customers and order history all move, but none of them move cleanly. Every platform models this differently and the gaps are where the work is.

Magento's configurable products and custom options do not map one to one onto Shopify variants, and a product with more than three option dimensions needs a decision rather than a script. WooCommerce sites usually carry years of plugin-written meta that has to be sorted into what becomes a metafield, what becomes a tag, and what gets left behind. Salesforce Commerce Cloud sites tend to have the cleanest catalogue data and the most bespoke business logic sitting on top of it. BigCommerce is the most straightforward of the four, though its price list and customer group model needs rethinking as Shopify markets and B2B catalogues.

Customer records are the part people forget. Passwords cannot migrate between platforms, so every customer has to reset. That is a comms job as much as a technical one, and it needs planning into the launch rather than discovering on the day.

URLs, redirects and rankings

This is the part that protects the traffic.

Every indexed URL on the old store needs a mapped destination on the new one. Not a redirect to the homepage, which search engines treat as a soft 404, but a page-level match. Shopify's URL structure is fixed in ways other platforms are not: products live under /products/, collections under /collections/, and a product accessed through a collection carries a different path to the same page. Getting the canonical structure right at the start is easier than unpicking it after launch.

The working method is to pull every URL that has an impression or a backlink, from Search Console, from the server logs and from a crawl of the old site, map each one to its new destination, and load the lot as redirects before the DNS change rather than after. Anything that cannot be mapped gets a considered decision, not a default.

Rankings dip for a few weeks after any migration. Done properly they recover. Done without a redirect map they often do not.

Apps and what replaces them

Every platform migration is also an app migration. Some things that needed an extension on Magento are native on Shopify. Some things that were native become an app, or become a Shopify Function. Subscriptions, loyalty, reviews and search are the four that usually need the most thought, because each one holds data that has to come with it. Reviews in particular are worth moving properly, since they carry structured data and they are slow to rebuild.

The honest version of this conversation is that the app stack often gets smaller. That is usually a good outcome, and it is worth doing deliberately rather than rebuilding the old stack out of habit.

What this costs in time

A straightforward catalogue with a clean redirect map and a theme built from an existing design is [typical timeline]. A Magento or Salesforce Commerce Cloud store with heavy custom logic, B2B pricing and a large catalogue is [typical timeline]. The variables that move it are catalogue complexity, how much business logic sits outside the platform, and how much of the design is being reworked at the same time.

Migrating and redesigning at once is usually a false economy. If the traffic drops you will not know which change caused it.