Ecommerce replatforming without losing traffic

Every replatform carries the same fear, and it is a reasonable one: the store gets rebuilt, launches, and organic traffic falls off a cliff.

It happens often enough to be a cliché. What is worth knowing is that it is almost never caused by the new platform being worse. In the migrations we have been called in to diagnose after the fact, the cause has been one of four things — and all four are preventable with work done before launch, not after.

This is the plan we run. It is deliberately boring.

The four things that actually cause traffic loss

Notice what is not on the list: the platform itself, the framework, the hosting, and the design. Those get blamed because they are visible. The four above are invisible until traffic moves.

Build the URL map first

Before a single template is designed, produce a spreadsheet with one row per existing URL. This is the single highest-value artefact of the whole project.

Get the URL list from every source you have, because none of them is complete on its own:

• The existing XML sitemaps.
• A full crawl of the live site.
• Search Console's page indexing report and performance report — this catches ranking URLs that are not linked from anywhere.
• Analytics, for landing pages over the last twelve months.
• Server logs, if you can get them. They show what crawlers actually request, including URLs nothing else knows about.
• Any backlink source you have access to, so you keep the pages other people link to.

Then assign each row a destination and a decision:

• Keep — the URL is identical on the new site. Best outcome; aim for as many as possible.
• Redirect — the page exists at a new address. A permanent 301 to the closest equivalent.
• Consolidate — several old pages become one. Redirect all of them to it.
• Retire — the page genuinely has no successor. Redirect to the most relevant category, and accept it will lose most of its value.

Two rules that are worth arguing for.

Keep the URL structure if you possibly can. A replatform is a tempting moment to "fix" URLs, and every change spends equity you already own. Unless the existing structure is actively harmful, carry it across. A migration with 90% of URLs unchanged is a fundamentally lower-risk project than one that rewrites them all.

Never redirect everything to the homepage. Bulk redirects to the root are treated as soft 404s and pass nothing. If there is no equivalent page, the parent category is the right target.

Migrate the data twice

Run the entire migration into a staging environment, in full, before you run it for real. Not a sample — everything.

The rehearsal is where you find the things nobody remembers: products with HTML pasted into the description field, prices stored as strings, customers with duplicate email addresses in different cases, orders referencing SKUs that no longer exist, twelve years of accumulated exceptions. You will find them either in a controlled rehearsal or on launch night.

What to check after the rehearsal, at minimum:

1. Counts match. Products, variants, categories, customers, orders. A discrepancy of any size needs explaining, not rounding.
2. Prices and currencies are right, including tax handling and any per-market pricing.
3. Stock levels reconcile with the system of record, not with the old store.
4. Images all arrived, at full resolution, with alt text preserved.
5. Descriptions render correctly — this is where pasted markup shows up.
6. Customer accounts work, including whatever the password migration story is. Usually a forced reset with a clear email.
7. Order history is visible to customers who look for it.

Decide what not to migrate

A migration is the only realistic opportunity to remove things, and teams routinely waste it by moving everything. Every product, page and redirect you carry across is something to test, something to maintain and something that can go wrong on launch night.

Worth deliberately leaving behind:

• Products discontinued years ago with no traffic and no backlinks. Redirect the URL, do not migrate the record.
• Duplicate and test products. Every catalogue has them. Migrating them makes them somebody's problem forever.
• Blog posts with no traffic, no links and no relevance. Consolidate the good ones, redirect the rest.
• Collections built for a campaign that ended in 2021.
• Redirect chains inherited from a previous migration. Flatten them: point the original source directly at the current destination.

That last one matters more than it sounds. If you migrated once before, you probably have URLs redirecting to URLs that redirect again. Add a third migration and you have three-hop chains, which lose value and eventually stop being followed. Resolve every chain to a single hop as part of the mapping work.

The rule for deciding: a page earns migration if it has traffic, backlinks, or a commercial purpose. If none of the three, redirect it and move on.

The redirect rules that actually cause problems

Redirects look simple and have a handful of edge cases that account for most of the failures we see after the fact.

1. 301, not 302. A temporary redirect tells search engines to keep the old URL. On a permanent migration that is the opposite of the intent, and it is a common default in server configurations.
2. One hop, never a chain. Each additional hop loses a little and adds latency; long chains eventually stop being followed at all.
3. Never redirect to a URL that itself redirects. The commonest way a chain appears is a redirect to a non-canonical form — an http URL, a missing trailing slash — which then redirects again.
4. Handle case and trailing slashes explicitly. If the old platform treated /Shoes and /shoes as the same page and the new one does not, you have doubled your 404s in a way no crawl of the old site will reveal.
5. Preserve query strings where they carry meaning, and strip them where they do not. Campaign parameters should survive; session identifiers should not.
6. Watch for loops. A redirect map assembled by several people over several weeks will contain at least one. Test the whole map programmatically before launch, not by sampling.
7. Keep the redirects forever. There is no safe point to remove them — old links persist in emails, printed material and other people's sites for years.

The things that break that are not SEO

Traffic gets the attention, and these cause more customer complaints in practice.

Customer accounts and passwords. Password hashes usually cannot be migrated between platforms. Plan a forced reset with a clear, well-timed email — and expect a support spike whatever you do. Send it before the migration, not after, so the first thing a customer meets is not a broken login.

Order history. Customers look for it, and it is often the last thing anyone thinks about. Decide early whether historical orders are migrated or kept accessible in a read-only view.

Active subscriptions. The highest-risk item in any migration, and the reason some migrations should not happen at all in their planned form. Subscription state, billing dates, payment tokens and dunning history rarely move cleanly. If you have a subscription programme, scope this first — it will decide the plan.

Reviews. Frequently held by a third-party app keyed to the old platform's product identifiers. Confirm the export path and the re-import mapping before launch, or you lose both the content and the star ratings in your search results.

Gift cards and store credit. Real money owed to customers. Reconcile balances explicitly and keep an audit trail.

Discount codes in circulation. Printed, in emails, in influencer posts. Make sure the ones still live get recreated.

Baseline before you start

You cannot tell whether a migration went well without knowing where you started, and the time to record that is before anything changes. Capture and store, at minimum:

• Organic sessions and revenue by landing page, for the last twelve months.
• Indexed page count, from Search Console rather than a site: query.
• Rankings for your top few hundred terms, in a stored snapshot rather than a live tool.
• Core Web Vitals field data per template.
• Conversion rate by device and by template.
• A full crawl export, kept as a file — not a saved project in a tool whose subscription may lapse.

Six weeks after launch, that baseline is the difference between "traffic feels down" and "category pages are down 14% while product pages are up 6%, so the problem is in one template". One of those is actionable.

The pre-launch checks

A week before launch, on the staging build, with the staging site crawlable by you and nobody else:

1. Crawl staging and compare against the live crawl — Page for page. Look for missing titles, missing meta descriptions, changed H1s, thin pages and unexpected noindex tags.
2. Test the redirect map in bulk — Run every source URL from the spreadsheet against the staging server and assert a 301 to the expected destination. Manual spot-checks miss the long tail, which is most of it.
3. Check what renders without JavaScript — Fetch a category page and a product page with JavaScript disabled. Copy, links, prices and pagination should be in the HTML. If they are not, that is the second cause in the table above and it is an architecture problem.
4. Validate structured data on every template — Product, breadcrumb, organisation, and any review or FAQ markup. Compare against what the old site emitted — Google's Rich Results Test is the fastest check.
5. Count internal links per template — If the new product page links to four things where the old one linked to twenty, you have flattened the internal link graph. Redesigns do this by accident constantly.
6. Confirm canonical and hreflang behaviour — Especially on faceted and paginated URLs, where a new template can generate thousands of near-duplicates that did not exist before.
7. Verify robots.txt and remove staging blocks — The classic launch failure is shipping Disallow: / from staging. Make it a checklist item with a named owner.

Launch week

Launch on a Tuesday or Wednesday morning, when everyone who might need to fix something is at work. Not Friday, and not before a holiday.

In the first 48 hours:

• Submit the new XML sitemap in Search Console, and keep the old sitemap available for a while so crawlers rediscover the redirected URLs faster.
• Watch the crawl stats and the 404 report daily. Any 404 that receives traffic is a missing redirect — add it the same day.
• Watch server errors, not just page errors. A 5xx during a crawl is worse than a 404.
• Keep the old environment running and reversible. If something is badly wrong, switching back within the hour costs far less than fixing forward under pressure.
• Do not make other changes. If traffic moves, you want one variable to reason about.

Then be patient. Some ranking movement in the first two to four weeks is normal even when everything is correct — search engines have to recrawl and reprocess the whole site. The question is not whether it dips, but whether it recovers. Judge the migration at six to eight weeks, not at six days, and resist the urge to make sweeping changes in between.

Key takeaways

• Traffic loss comes from four preventable causes — redirects, rendering, structured data and internal linking. Not from the platform.
• The URL map is the most valuable artefact in the project. Build it before design starts.
• Keep existing URLs wherever possible. Every change spends equity you already own.
• Rehearse the full data migration. The rehearsal is where the twelve years of bad records show up.
• Test redirects in bulk, not by spot-check. The long tail is where the traffic is.
• Launch mid-week, keep a rollback, change nothing else, and judge the result at six to eight weeks.

If you are planning a migration and want the URL map and rendering checks reviewed by someone who has cleaned up after a few of these, get in touch. It is a short piece of work that prevents the expensive kind of surprise.