Ecommerce Development · focused work
Ecommerce platform migration
A migration moves a store's catalog, customers, orders and traffic onto a different platform without losing the revenue attached to them. Most of the risk is not in exporting the data. It is in the URLs, the redirects, the tracking and the many small behaviours of the old store that nobody ever wrote down.
This is the right work if
- The current platform blocks something the business needs, such as trade pricing or a new market
- App subscriptions are replacing functions the platform itself should be providing
- The catalog has outgrown the way the current store models products and variants
- An earlier migration left redirects incomplete and organic traffic never came back
- Several sites are being consolidated onto one storefront and one catalog
What it is
What a migration covers end to end
The visible half is the build: modelling products, variants, options and collections on the new platform, importing customers and whatever order history the platform accepts, moving blog and page content, reviews, subscriptions and gift card balances, and constructing the storefront itself. The less visible half decides whether the store keeps earning. Every URL with traffic, links or index presence needs a destination. Every product feed needs re-pointing at the new source. Every analytics tag, conversion action, ad platform connection, email flow trigger and automation has to be rebuilt and tested against a real order rather than assumed.
The URL map is where the outcome is usually decided. It covers products, collections, blog posts, static pages, the filtered pages that were earning clicks and the paginated series behind large categories, each mapped to a single destination in one hop. The map is tested on a staging copy against a fresh crawl of the live site before anyone changes DNS. After launch the work continues for weeks: crawl errors, index coverage, rankings read by template, revenue by channel, and the feeds and tags that fail quietly without producing an error anywhere.
How it is done
The work, in order
What changes
- Traffic and rankings carry across because every earning URL has a destination
- Tracking, feeds and flows work on the first day instead of being found broken later
- The catalog is modelled for the new platform rather than copied out of the old one
- The business gets the capability that justified the move in the first place
Inventory the old store first
Crawl every URL and join it to rankings, sessions and revenue, then list the apps, integrations, feeds, tags and automations with their owners. Nothing gets built on the new platform until this exists, because it is also the acceptance checklist for launch.
Model the catalog before importing it
Decide how products, variants, options and attributes map onto the new platform's structures, and where extra fields will live. Copying an old model into a new system carries forward every compromise the old platform forced, and it is far harder to change once orders exist.
Build the URL map
Pair every old URL that has traffic, links or index presence with one destination on the new store, including filtered pages that earned clicks and the pagination behind large categories. Write a rule for the long tail so no page is left without a target.
Rebuild tracking, feeds and flows
Analytics, ad platform tags and conversion setup, product feeds, email and SMS connections, review sync and subscription data. Test each one on staging with an order placed end to end, since a tag that fires on a test page proves very little about a real checkout.
Cut over on a written plan
Freeze content changes, run the final data sync, publish the redirects with the DNS change rather than after it, and keep the old store reachable on an internal address for comparison and rollback. Assign one person to each check on launch day.
Watch the first weeks closely
Read crawl errors and index coverage daily at first, rankings by template weekly, and revenue by channel against the equivalent period before. New redirect gaps surface as crawlers work through the old index, and they are cheap to fix while traffic is still recovering.
Platform notes
Shopify
Product and collection paths follow a fixed prefix structure, so a move from a platform with custom paths means redirecting nearly every URL; historical orders import as records rather than as live orders, which affects reporting continuity.
WooCommerce
Permalink structures are configurable, so an incoming migration can often preserve the old paths exactly, which removes most of the redirect risk at the cost of living with the previous site's URL decisions.
How much organic traffic does a migration put at risk?
It depends almost entirely on whether the URL map is complete and the new templates are as crawlable as the old ones. A move with unchanged URLs and equivalent content usually passes with a short dip. A move that changes every path and drops on-page content can take a long time to recover.
Can order history move to the new platform?
Usually as historical records rather than as fully functional orders, which means refunds, exchanges and subscription renewals may still need the old system for a period. Decide early how long the old platform stays accessible and who has access to it.
Should a redesign happen at the same time as the migration?
Only when there is capacity to test both. Changing platform and design together makes any drop after launch hard to attribute, since the cause could be redirects, templates, content or layout. Where the timeline allows, move first, stabilise, then redesign.
How long do the redirects need to stay in place?
Indefinitely for anything that still receives traffic or holds links, and at minimum for a long enough period that search engines have processed every old URL. Redirects are cheap to keep, and removing them is the most common cause of a delayed second traffic drop.
Related work and answers
Find the leak.
A free Growth Analysis ranks what your store should fix first, by revenue at stake.