Tags: web-dev commerce concept
Replatforming
Date: 2026-08-16
Moving a shop from one commerce platform to another. It’s a data migration, a URL migration, an integration rebuild and a measurement migration happening simultaneously — which is why the honest question is usually whether you can avoid it.
What it is
Replatforming is changing the system running your commerce operation: catalogue, orders, customers, checkout, admin and integrations.
It’s the largest routine project in ecommerce and it has a poor success record — not because the technology is hard, but because the scope is four projects that all have to land at once.
The four migrations inside it
| Migration | Fails as |
|---|---|
| Data — products, customers, orders, content | Missing history, broken variants, lost customer accounts |
| URLs — every indexed page | Traffic collapse four weeks after launch |
| Integrations — ERP, PIM, email, reviews, search, payments | Discovered late; each is its own project |
| Measurement — analytics, tags, attribution | Nobody can tell whether launch went well |
PIM is product information management — the system of record for product attributes, separate from the shop that displays them. ERP is enterprise resource planning, the back-office system holding stock and orders. Both are usually integration points, and both are usually underestimated.
The fourth is the one that turns a recoverable problem into an unresolvable argument: if measurement changed at the same time, you cannot distinguish a real decline from a tracking break, and both will be claimed with conviction.
The honest first question
Can you avoid it? Replatforming is frequently proposed to solve problems it doesn’t solve:
| Stated reason | Usually |
|---|---|
| ”The site is slow” | A theme, image and third-party problem, fixable in place — Performance Budgets |
| ”We can’t build the design we want” | A theme constraint. Sometimes real, rarely worth this |
| ”The admin is painful” | Process and training as often as software |
| ”We’ve outgrown it” | Sometimes true. Ask which specific limit you’ve hit |
| ”We need headless” | See Headless Architecture — and headless is a separate decision from replatforming |
Genuinely good reasons: the platform can’t support a business model you’re committed to (B2B pricing, subscriptions, multi-region), the vendor is discontinuing it, costs scale wrongly against your growth, or a specific hard limit is blocking revenue.
Sequencing
The single most useful principle: don’t change everything at once.
WORST BETTER
new platform 1 fix measurement, freeze taxonomy
+ new design 2 replatform on the existing design and URLs
+ new URLs 3 redesign afterwards, tested
+ new analytics 4 change URLs only if genuinely necessary
all in one release
Keeping the design and the URLs constant through a replatform removes the two largest risks and makes the launch diagnosable. It’s less exciting and it’s why the projects that survive look boring.
What to protect
- URLs. Map every one. Crawl the old site — not the sitemap, which won’t contain the URLs holding the oldest links — Site Migrations and SEO, Redirects and Link Equity
- The event taxonomy. Keep names identical even where the new platform makes different ones natural, or every trend line breaks at the seam — Event Taxonomy Design, Metric Drift
- The analytics property. A new property means no historical comparison, permanently
- Customer accounts and order history. Forcing password resets and losing order history is a churn event, not a technical detail
- SEO-relevant content — meta titles, descriptions, structured data, alt text. Frequently lost in a template rewrite
Running it
- Parallel running where the platform allows — old and new serving different segments, so you have a comparison rather than a before-and-after — Rollouts as Experiments
- Category-by-category or region-by-region cutover rather than a single switch, where the architecture permits
- Baseline everything before launch. Per-URL search performance, conversion by template, the analytics-to-orders reconciliation gap. Unrecoverable afterwards
- An owner for the four weeks after, with time allocated. The failure mode is that the team disperses on launch day and the damage surfaces in week three
- Expect a dip and say so in advance, in writing, with an expected recovery window. Otherwise the normal post-migration dip is read as failure and triggers panic changes that make it worse
The measurement checklist
Because it’s the part that lands on you:
- Tracking plan verified on staging, then at low traffic, before cutover — Experiment QA
- Reconciliation against the order system run on both platforms during any parallel period — Guide - Auditing a Tracking Plan
- Consent implementation compared — differences here move every metric — Consent Management
- Session and bot-filtering definitions compared, and the expected step changes documented in advance — Sessionisation, Bot and Internal Traffic
- The launch date annotated everywhere anyone will look — Annotation and Change Logs