Almost every replatforming business case is built on the wrong numbers. Platform licensing and front-end build are the visible, quotable items, and together they are usually under half the real cost. The rest is data migration, re-integrating the systems around the shop, and the traffic you lose in the first eight weeks because the redirect map was treated as a launch-week task. That last one has sunk more replatforming projects than any technology decision. Sequencing a migration like this is legacy modernization work.
01What replatforming actually costs, all in
The figures below are total programme cost including build, data migration, integrations and launch - not the platform fee. They assume a mid-market retailer with real order history, a live ERP and more than one sales channel.
The dominant variable is not catalogue size. It is the number of surrounding systems that assume the current platform's data shapes: ERP, warehouse management, tax, subscriptions, loyalty, marketplace feeds and whatever the marketing team has connected without telling anyone.
| Retailer profile | Programme cost | Duration | Platform fee (annual) |
|---|---|---|---|
| Small D2C, single channel, simple catalogue | $45k - $110k | 2 - 4 months | $3k - $30k |
| Mid-market, ERP integration, 2 - 3 channels | $150k - $400k | 5 - 9 months | $25k - $120k |
| Multi-region, multi-currency, B2B and B2C | $400k - $900k | 9 - 15 months | $80k - $300k |
| Headless composable, custom checkout logic | $500k - $1.5m | 12 - 20 months | $100k - $400k |
02Platform choice, honestly
Platform selection consumes disproportionate time relative to its effect on cost. Most mid-market retailers get an acceptable outcome on any of the mainstream options; what varies is where the customisation friction lands.
The genuine decision is how much of checkout and pricing logic you need to control. That single question separates SaaS platforms from composable ones more clearly than any feature comparison.
| Category | Build cost index | Fits when | Expensive when |
|---|---|---|---|
| Hosted SaaS (Shopify Plus, BigCommerce) | 1.00 | Standard commerce, fast time to market | Custom checkout, unusual tax or pricing logic |
| Open source self-hosted (Magento, Sylius) | 1.4 - 1.9 | Deep customisation, existing team | Ongoing upgrade and hosting burden |
| Composable / headless (commercetools, Saleor) | 1.6 - 2.4 | Multi-channel, complex B2B pricing | Team lacks the platform engineering to run it |
| Marketplace-native or ERP-led | 1.2 - 1.8 | ERP is the true source of truth | Front-end experience matters commercially |
03Data migration is where the schedule goes
Product data is the part everyone plans for and it is rarely the problem. The problems are orders, customers and the objects that carry state - subscriptions, store credit, loyalty balances, partially fulfilled orders and returns in flight.
The rule that saves the most time is to decide early what you are not migrating. Ten years of order history is usually needed for reporting and customer service, not for the live storefront, and moving it to a warehouse rather than into the new platform removes weeks of work and a great deal of risk.
| Data | Typical effort | Main risk |
|---|---|---|
| Products, variants, categories | 1 - 4 weeks | Attribute model mismatch |
| Media and asset re-hosting | 3 days - 2 weeks | Broken references, filename collisions |
| Customer accounts | 1 - 3 weeks | Password hashes rarely portable |
| Order history | 2 - 6 weeks | Status model differs between platforms |
| Subscriptions and recurring billing | 3 - 8 weeks | Payment tokens tied to old gateway |
| Store credit, gift cards, loyalty | 2 - 5 weeks | Real money, must reconcile exactly |
| Reviews and user-generated content | 3 days - 2 weeks | Often overlooked until launch week |
04The SEO migration that goes wrong
The most common serious failure in replatforming is a traffic collapse in the weeks after launch, caused by URL structures changing without a complete redirect map. Losing 20-40% of organic traffic for a quarter is a routine outcome, and on a retailer doing meaningful revenue that dwarfs the entire project budget.
It is entirely preventable, and the prevention is unglamorous: crawl the existing site properly, map every ranking URL to its new equivalent, and test the redirects before launch rather than discovering broken ones from a rankings report a fortnight later.
- Crawl the live site and export every indexed URL before any development starts, not at launch.
- Map one-to-one where possible; a redirect to the homepage counts as a broken URL in practice.
- Preserve structured data, canonical tags and hreflang - these are silently dropped by new themes.
- Keep page titles and heading structure stable through launch; redesign them a month later if you must.
- Benchmark Core Web Vitals before and after - a slower new site loses rankings independently of URLs.
- Hold the old site's server logs so you can see exactly what crawlers hit and what they got.
05Integrations: the largest line and the least visible
The shop is the visible part of a commerce estate and rarely the complicated part. Every system currently reading from or writing to the platform must be reconnected, retested and reconciled, and each of those systems has an owner who does not report to the replatforming project.
Take an inventory before quoting anything. The count is almost always higher than the initial answer, because marketing and operations connect tools directly and nobody keeps a register.
- ERP and finance: 3 - 10 weeks, and the reconciliation testing is longer than the build.
- Warehouse and 3PL: 2 - 6 weeks, with a physical cutover that cannot be rolled back easily.
- Tax calculation and invoicing: 1 - 4 weeks, more with multi-jurisdiction or e-invoicing obligations.
- Marketplaces and feeds: 1 - 3 weeks each, and each has its own data requirements.
- CRM, email and consent management: 2 - 5 weeks including consent state, which must migrate correctly.
- Analytics, tag management and attribution: 1 - 3 weeks, and getting it wrong hides whether launch went well.
06Cutover and the first month
The launch itself should be boring. Aim for a phased cutover - a subset of traffic, a single region or a single brand first - so that the failure mode is contained. A big-bang launch across all regions on a Friday is how a replatforming becomes a public incident.
Budget a stabilisation period explicitly. The first four to six weeks after launch generate a steady stream of edge-case defects around returns, partial refunds, tax rounding and B2B pricing - the paths that only appear when real customers use them. Teams that discharge the delivery team at go-live pay far more to reassemble one under pressure.
- Freeze non-essential change for two weeks either side of cutover.
- Never launch into your peak trading period - retailers who do it in November regret it.
- Keep the old platform readable for at least 90 days for reconciliation and customer service.
- Reserve 10 - 15% of programme budget for post-launch stabilisation.
- Watch conversion rate by device and step, not just total traffic - a checkout regression hides inside flat traffic.
Topics
Lena Voss
Lead Architect · SyncTrix
Writes about the engineering decisions behind production systems - architecture, delivery and the trade-offs that only show up at scale.
Building something like this?
SyncTrix engineers AI, SaaS, platform and cloud systems for enterprises and high-growth teams. Tell us what you're shipping and we'll scope it with you.