CommerceBolt — a Perigeon company
Talk to an expert

Service

Platform Migration

Moving platforms is mostly a data and redirect problem wearing a design brief. We plan it backwards from the two things that actually break: your organic traffic and your order history.

The Water Bottle Store homepage, a multi-brand Shopify storefront
The same storefront on a phone

We assessed this store for replatforming and advised against it. The recoverable revenue was in search, product pages and post-purchase flows, not in the platform underneath. Read the case study

Diagnosis first

Reasons to move, and reasons that only look like one

Replatforming is expensive and disruptive. It is worth it for some of these and almost never worth it for others.

  1. The platform cannot express how you sell

    A real reason to move. Contract pricing, approval chains, company accounts and catalogue rules that your current stack simply has no concept of.

  2. Licence and hosting cost more than the rebuild

    Often a real reason. Self-hosted Magento with a dedicated ops budget can cost more over three years than moving and paying a SaaS licence.

  3. Nobody will touch the codebase

    A real reason when the platform is end-of-life or the extensions block upgrades. Not a reason when the problem is one badly built theme.

  4. The site looks dated

    Rarely a reason to move. A new theme on your current platform costs a fraction of a migration and ships in weeks.

    Talk about a rebuild instead

What actually breaks in a migration

Three things, in order of how often we see them.

Redirects. A store with ten years of history has far more live URLs than anyone expects — old collection filters, discontinued products that still rank, blog posts linked from elsewhere. Generate the map from a sitemap and you will cover the catalogue and miss the long tail that quietly earns a third of the organic traffic.

Data that was never as clean as the export suggested. Variant options stored inconsistently, prices maintained in two systems, customer records duplicated across channels. This surfaces during mapping if you are careful and during cutover if you are not.

Integrations nobody documented. The ERP connector someone built in 2019, the spreadsheet that drives pricing, the webhook that tells the warehouse to pick. These are discovered by asking the people who use them daily, not by reading the codebase.

How we keep the risk low

We migrate data in repeated dry runs rather than once on the day, and we time each run, so cutover has a known duration. We agree a parity checklist — tax, shipping, discounts, analytics, email flows — and check it against the old store rather than against the brief.

And we capture a ranking baseline before anything moves. Without one, any post-launch traffic argument is unresolvable: you cannot tell a seasonal dip from a redirect you missed. With one, it is a five-minute question.

If you are weighing whether to move at all, the eCommerce development page covers the cheaper alternative, and the Hydrogen and Oxygen page is worth reading before anyone proposes going headless as part of the same project.

Platforms

Where we build.

The traffic is what you are really protecting

Most migrations that go wrong do not lose data — they lose rankings, because the redirect map was generated from a sitemap and the long tail was never in it. We build ours from crawl and Search Console data, and we measure against a baseline captured before anything moves.

Talk through your migration
An abstract render of commerce controls moving to a cloud platform

Scope

What a build includes.

  • A redirect map built from real URLs

    From your analytics, Search Console export and a full crawl — not from the sitemap. The sitemap never contains the long tail that earns the traffic.

  • Catalogue and customer data, reconciled

    Products, variants, media, categories, customers, addresses and order history, with a field-by-field mapping agreed before anything is written.

  • Order history your support team can still search

    Historic orders carried across or kept queryable. Losing them is the migration decision people regret six months later.

  • Integrations re-pointed, not rebuilt from memory

    ERP, OMS, tax, fulfilment and marketing connections re-established against the new platform, with the old ones kept running until cutover.

  • A parity checklist before anyone goes live

    Analytics, tracking, tax rules, shipping rates, discounts and email flows checked against the old store rather than assumed.

  • A rollback plan

    Written down before cutover, with a DNS TTL short enough to actually use it. A plan nobody wrote is not a plan.

How it runs

From first call to live.

  1. Audit 2–3 weeks

    Catalogue size, data quality, integration inventory, top URLs by traffic and revenue, and the honest question of whether moving is warranted at all.

  2. Mapping 2 weeks

    Data model mapping and the redirect map. This is the unglamorous half of a migration and the half that decides whether it works.

  3. Build and migrate 8–14 weeks

    New storefront built while data is migrated in repeated dry runs. Every run is timed, so cutover day has a known duration rather than a hopeful one.

  4. Cutover 1 week

    Final sync, DNS switch, redirects live, analytics verified. Chosen for a quiet trading day, not a Friday.

  5. Watch 4–6 weeks

    Daily rank and traffic monitoring against the pre-migration baseline. Dips in week one are normal; dips still there in week four are a defect we fix.

Frequently asked questions

How long does a platform migration take?

Twelve to twenty weeks for most mid-market stores, from audit to the end of the monitoring window. The variables are catalogue size, how clean the product data is, and how many integrations exist. The storefront build is rarely the critical path.

Will we lose our search rankings?

Not if the redirect map is complete. Expect a dip in the first fortnight while the new URLs are recrawled, then recovery. We capture a ranking and traffic baseline before cutover specifically so that this is measurable rather than a matter of opinion, and we monitor daily for four to six weeks afterwards.

Can we keep our order history?

Usually yes, either migrated into the new platform or kept queryable in a read-only archive your support team can search. Which approach fits depends on the target platform and how far back you need. Decide it during the audit, not after.

Do we have to redesign at the same time?

No, and often you should not. Migrating and redesigning at once means that if traffic drops you cannot tell which change caused it. Moving on a close approximation of your current design, then redesigning once the numbers are stable, is the lower-risk sequence.

What about downtime?

Minutes, not hours. The new store is live and tested before cutover; the switch is a DNS change with a short TTL and a final data sync. We schedule it for a quiet trading period and have a rollback path ready.

Should we move to Shopify Plus or Adobe Commerce?

Shopify Plus for most D2C and a good deal of B2B, because total cost of ownership is lower and the checkout converts. Adobe Commerce where you need deep B2B rules, complex pricing or self-hosting. Salesforce Commerce Cloud where you are already in the Salesforce estate. The audit answers this on your constraints rather than our preference.

Want to talk through Platform Migration for your store?

Tell us where it hurts. We will tell you honestly whether we are the right people for it.

Talk to an expert Book 30 minutes