Will a Replatform Cost You Sales? The Revenue You Leak While You Wait

Ecommerce replatforming typically takes six to nine months from kickoff to launch. Throughout that window, the current site keeps handling real traffic, real orders, and real revenue — which means the errors, slow pages, and checkout friction a team plans to fix in the rebuild keep costing money every single day until the new site goes live. Deferring those fixes doesn't pause the loss. It extends it across the entire build.

That's the part most replatforming plans quietly ignore.

"Why would we fix a site we're about to replace?"

It's a fair question, and we hear it constantly. A team commits to a new build, the old site gets mentally written off, and every issue gets the same answer: we'll handle it in the new one. Page speed? New site's faster. Checkout bug? Rebuilding checkout anyway. Broken PDP on Safari? Won't exist post-launch.

The logic feels efficient. The math says otherwise.

The site you're replacing isn't a prototype sitting in a staging environment. It's your live storefront, taking add-to-carts and processing payments right now, for the six-to-nine-month stretch between the decision to rebuild and the day you actually cut over. For a lot of retailers, that's a peak season, a product launch, or a full quarter of demand running through a storefront everyone has agreed to stop caring about.

You don't get that revenue back. There's no true-up at launch.

The friction didn't pause because your roadmap did

Here's what actually happens during a build window. Traffic holds. Conversion drifts down, quietly, because nobody's watching the current site anymore — monitoring got deprioritized alongside everything else. A third-party script starts conflicting after a routine tag update. A payment method silently fails on one browser. An image error on the PDP suppresses add-to-cart for a segment of mobile users.

None of it shows up as an outage. None of it generates a support ticket, because under 1% of customers report anything — they just leave and shop elsewhere. So the loss runs invisibly, against a fixed conversion baseline, for months.

Now flip that around. If a tenth of a second moves retail conversion by 8%, what is a genuinely slow, error-laden site doing to conversion over eight months? The speed problem you're deferring isn't neutral while you wait. It's actively suppressing revenue the whole time.

The cost of coasting, in real numbers

The abstract version of this argument never lands. The arithmetic does. So do the math on your own site:

That $480K is money leaking from a site you already own, running on traffic you already paid to acquire, during months you've already budgeted. It's the cheapest revenue you'll ever protect — and the easiest to ignore, because the rebuild is the shiny thing and the current site feels like a sunk cost.

It isn't sunk. It's still running.

The bigger miss: you're throwing away the blueprint for the new site

Even teams that accept the revenue argument make a second, more expensive mistake. They treat the current site as only a liability to be shut down — not as the single richest source of truth about how their customers actually behave.

Your live site is running a real-world experiment every day. Where shoppers hesitate. Which PDPs get rage-clicked. Where checkout quietly fails. Which slow pages bleed the funnel. That's not legacy noise. That's a prioritized punch list for the redesign — a map of exactly which problems the new build has to solve, backed by real user behavior instead of a wireframe committee's best guesses.

Rebuild without that data and you carry the same friction into the new site by accident — now baked into a fresh codebase where it's harder to spot and pricier to unwind. Teams do this all the time: they rebuild the checkout, launch it, and reintroduce a variant of the exact bug they never diagnosed on the old one, because nobody was watching the old one when it mattered.

The friction data from the site you're replacing is the highest-fidelity brief your design and engineering teams will ever get. Discarding it to save a few months of monitoring is the most expensive shortcut in a replatforming project.

What to actually do during the build window

You don't have to choose between pouring resources into a dying site and flying blind for eight months. There's a disciplined middle path — and it makes the new launch safer, not just the old site cheaper to run.

1. Keep monitoring the live site until cutover

Don't decommission visibility on the storefront still taking orders. Always-on monitoring means a payment gateway that dies on one browser gets caught in hours, not two weeks — before it compounds across a quarter you can't get back.

2. Triage by revenue impact and fix only the cheap, high-impact issues

Nobody's asking you to refactor a site headed for retirement. But when an issue is a 20-minute fix costing five figures a month — a broken add-to-cart, a checkout script conflict, a suppressed CTA — you fix it. Prioritizing by dollars-at-risk with issue detection tells you which "we'll get to it later" issues can't actually wait.

3. Capture a friction baseline to carry into the build

Before you cut over, you want a documented, behavior-backed record of where the current site struggles: the funnel drop-offs, the recurring errors, the pages where Core Web Vitals slip. That baseline becomes the requirements doc the redesign is measured against — and the benchmark you'll compare the new site to on day one. See our guide to Page Analysis and DXA for ecommerce.

4. Validate the new site against that baseline before it costs you

Migrations are exactly when conversion silently breaks — and exactly when everyone's too busy launching to notice. This is where Release Monitoring earns its place: it connects every deployment to changes in stability, performance, and behavior, so a regression introduced at launch surfaces immediately instead of two weeks and a lost peak later.

Retailers who instrument the migration this way don't just launch — they launch with proof the new site is actually better than the one it replaced.

"When we did the major site migration, conversions dropped for a few days. I probably still think that we'd have problems with the checkout if it wasn't for the visibility that Noibu has brought to us. With Noibu, it's like running guaranteed A/B tests with the probability of delivering a positive result being infinitely higher."
— Matthew Lawson, CDO, Ribble Cycles

There's a second version of this story worth knowing — the one where the migration itself becomes lower-risk because the team validated in parallel before going live:

"Noibu gave us the confidence to move to Shopify. We could run tests in parallel, see what was running slow, and fix those issues before we ever went live. It turned a high-risk migration into a validated success."
— Philip Krynsky, CEO & Founder, Rvinyl

Coast vs. instrument: the same eight months, two very different outcomes

The redesign is the exciting project. The current site is the one paying the bills until the redesign ships. Treat both like they matter, because for the next six-to-nine months, they both do.

Related topics

• What should be on an ecommerce replatforming checklist?
• What is Digital Experience Analytics (DXA) for ecommerce?
• How does Release Monitoring catch regressions after a deploy?

Before you rebuild, you should know exactly what the current site is leaking — in dollars, by issue, ranked by impact. That's the punch list your redesign should be built around, and the baseline you'll measure the new site against on launch day.

Get a free website audit → See the revenue-impacting issues on your live site today, before the next eight months carry them into your rebuild.