Replatform to Shopify without losing the traffic you already earned

What we migrate from

What follows describes what each move involves technically: what exports cleanly, what has to be rebuilt rather than converted, and where the URLs change.

• Magento and Adobe Commerce

  Magento lets you design your own URL paths, usually nested category folders with a .html suffix. Shopify does not. Products always sit under /products/ and collections under /collections/, and those prefixes cannot be removed, so every Magento URL that earns traffic needs a mapped 301. The other reshaping job is the catalogue: Magento configurable products can carry as many attributes as you like, while Shopify caps a product at three options (spread across up to 2,048 variants since October 2025). Products with four or more axes have to be split, combined, or rebuilt with metafields.

  Magento and Adobe Commerce: the full guide

• WooCommerce and WordPress

  The store data is the easy half. The hard half is the WordPress site wrapped around it: /product-category/ archives, custom post types, page builder markup, and plugin logic with no Shopify equivalent. Blog content moves under /blogs/, which changes every article URL, so on content-heavy Woo sites the editorial redirect map is often longer than the product one. Anything a plugin was doing at checkout has to be rebuilt as a Shopify app, a Function, or dropped on purpose.

  WooCommerce and WordPress: the full guide

• BigCommerce

  The closest structural match on this list. Catalogue exports come out clean and the gaps are narrow: option sets and modifiers do not map one to one onto Shopify variants, and BigCommerce category URLs nest where Shopify collections stay flat. Stencil templates get rebuilt in Liquid rather than converted, which is a rewrite, not a port. Budget accordingly.

  BigCommerce: the full guide

• Wix

  Wix is a closed system, so the export is the constraint rather than the theme. The built-in product export leaves digital products behind entirely and skips listings above 100 variants, which means part of the catalogue has to come out through the API or by hand. Nothing in a Wix template transfers, so the design is rebuilt. For most Wix merchants that is the point of moving.

• Squarespace

  Squarespace exports up to 10,000 products to CSV, but only physical and service products, and only three variant options each. Digital products do not come out. The upside is that Squarespace URLs tend to be shallow and readable, so the redirect map is small and quick to verify, and most of the project is design, checkout and app work rather than data archaeology.

• Salesforce Commerce Cloud

  Nothing lifts and shifts. SFRA cartridges, price books and the integration layer around them all get rebuilt, and B2B behaviour that lived in custom code moves onto Shopify company profiles, catalogues and payment terms, which are Plus features. This is the longest migration type on the list and the one where discovery earns its keep, because an SFCC build of any age contains pricing and entitlement rules nobody currently at the company wrote.

• Custom and headless builds

  A bespoke stack has no export button, so extraction starts at the database or an internal API. That is usually good news. The data is yours in full, including order and customer history that hosted platforms hand over in reduced form. The work moves to reconciling data models: whatever the old build called a bundle, a subscription or a price rule has to become something Shopify actually has, or an app, or a Function.

How a migration runs

1. 01

   Discovery and data audit

   We crawl the current store, pull the full catalogue export, and read the theme and integration code before quoting a number. The goal is to surface everything without a Shopify equivalent while it is still a scoping decision instead of a launch-week emergency. Subscriptions, bundles, tiered B2B pricing and tax edge cases are where projects go wrong, and they are all visible in week one if somebody looks.

   DeliverableScope document naming every entity to migrate, every integration, and every known gap with the decision made on it.

2. 02

   URL map and redirect plan

   Every URL with traffic, backlinks or internal links gets a destination before anything is built. Shopify has rules here that catch teams out late: a redirect can only be created from a URL that returns 404, reserved paths such as /cart, /orders and /collections/all cannot be redirected at all, and the redirect ceiling is 100,000 on standard plans against 20 million on Plus. The map is built against those constraints rather than patched afterwards.

   DeliverableRedirect CSV checked against Search Console and backlink data, formatted for bulk import into Online Store > Navigation > URL Redirects.

3. 03

   Data extraction and transformation

   Products, variants, images, collections, customers, order history, blog content and metafields come across in staged batches, each one reconciled by row count. Transformation is where the judgement sits. Attribute sets become options or metafields, category trees become collections plus tags, and anything that cannot survive the move gets flagged in writing rather than quietly dropped.

   DeliverableStaged import files plus a reconciliation sheet: rows out of the old system, rows into Shopify, and every deliberate exclusion named.

4. 04

   Theme build on a development store

   Build happens on a password-protected development store while the current site keeps trading. Templates are written in Liquid with sections, blocks and metafields so your team can edit merchandising without a developer afterwards. If you are keeping the existing design, we rebuild it rather than screenshot it, because a converted theme carries the old platform assumptions into the new one.

   DeliverableDevelopment store with the full template set, populated with real migrated data.

5. 05

   Apps, checkout logic and integrations

   Every app on the old store has to earn a place on the new one, and the audit is where the list gets shorter: two apps doing the same job, an app installed for a campaign that ended, an app doing what a metafield and a section can do natively on Shopify. Checkout is the part that has changed most: checkout.liquid is retired, and Shopify Scripts stopped executing on 30 June 2026, so discount, shipping and payment logic now lives in Shopify Functions and, on Plus, checkout UI extensions. If your current store still runs Scripts or additional scripts, that logic is a rewrite and needs its own line in the estimate.

   DeliverableIntegration matrix: app kept, app replaced, app cut, and the named Function or extension that replaces each piece of custom checkout logic.

6. 06

   QA on staging

   Test orders through every payment method in test mode, tax and shipping rates against real destination addresses, notification emails, ERP and 3PL handoffs, then accessibility and Core Web Vitals on the templates that carry traffic. We also crawl the development store and diff it against the crawl of the old site, which is how missing redirects get caught before customers find them.

   DeliverableQA checklist signed off across orders, taxes, shipping, emails, integrations and accessibility, with the crawl diff attached.

7. 07

   Cutover

   DNS change, redirect import, robots.txt.liquid in place, sitemap submitted, analytics and pixels verified against live traffic rather than assumed. Cutover runs at a low-traffic hour with the old store kept up and reachable, so rollback is a DNS change and not a rebuild.

   DeliverableLaunch runbook with a rollback path and a named owner for every step.

8. 08

   The first thirty days

   A migration is not finished at launch, it is finished when the crawl settles. We watch 404 logs, Search Console coverage and rankings for the URLs that mattered before the move, and fix redirect misses as they surface. Customer account activation emails go out 24 to 48 hours after cutover rather than on launch day, so support is not answering password questions during the busiest hours of the project.

   DeliverableDay 30 report: 404 log, index coverage, and ranking movement measured against the pre-migration baseline captured in step 1.

What is in scope, and what is not

Questions merchants ask before signing

How long does a Shopify migration take?

Catalogue size matters less than people expect. What sets the timeline is how much custom logic sits in the old checkout, how clean the product data is, how many systems talk to the store, and how fast your team reviews staging. A Squarespace store with 200 products and no ERP is a different project from an SFCC build with price books and a warehouse integration. Anyone who quotes you a launch date before seeing the data export and the integration list is guessing.Migration checklist

What happens to my SEO and rankings?

Rankings follow URLs when the 301s are complete and in place on day one. Expect a dip anyway, because Google has to recrawl the whole site and a large catalogue takes weeks to work through. The cases that turn into real damage almost always share one cause: somebody mapped the top 200 URLs and let the long tail 404. Export Search Console and analytics for the months before cutover so you hold a baseline of your own, because without one you cannot tell a normal recrawl dip from a redirect that never fired.Site structure and internal linking

Why do Shopify products have two URLs, and does it matter?

The same product is reachable at /products/handle and at /collections/name/products/handle. Both resolve, both render, and only the first should be linked. If the theme uses the collection-scoped version throughout, your own internal links argue against your canonical tags, and Google has to decide which one you meant. We link to clean product URLs from the first template rather than fixing it after launch.

Will I lose any data?

Products, variants, images, collections, customers, blog posts and order history all move, and we reconcile row counts at each stage so nothing goes missing quietly. Two things genuinely do not survive. Customer passwords cannot be migrated by anyone, so customers reset through an activation email. Imported orders come in as records, which means refunds and edits against pre-migration orders stay on the old system. Everything else is a question of effort, not possibility.

What happens to my apps and integrations?

We audit every installed app and sort it into kept, replaced, or cut. Reviews usually migrate through the vendor import tools. Subscriptions rarely do, because billing tokens sit with the payment gateway. Loyalty balances need an export from the vendor before you cancel, not after. Checkout customisations are the sharp edge: checkout.liquid is retired and Shopify Scripts stopped running on 30 June 2026, so any rule still living there is a rewrite into Shopify Functions.

Can you work alongside our in-house team?

Yes, and it is often the cheaper way to run it. The usual split is that we own the platform work (data, Liquid, Functions, redirects, cutover) while your team owns content, merchandising and approvals, since they are faster at all three. We also embed into an existing dev team for the parts they do not want to learn on a live deadline. What we will not do is run a migration where nobody on your side can decide within a day.Hire Shopify developers

What does a Shopify migration cost?

Price tracks scope, not SKU count. The variables that move an estimate are custom checkout logic, the number of live integrations, the state of the product data, and whether the design is being rebuilt or reproduced. Platform fees are separate and public: Shopify Plus is listed at CA$3,400 per month on a three-year term or CA$3,650 on a one-year term, accurate as of 12 August 2026, with a variable fee for higher-volume merchants that Shopify negotiates directly.Migration cost breakdown