Should You Replatform? Start With the Complaint Test
Somebody has proposed a rebuild.
Maybe it was the agency. Maybe a platform rep, maybe a new CTO, maybe your own team after a bad quarter. The reasoning sounded solid in the room. It usually does. And now you’re trying to work out whether it’s sound or self-interested, from inside a conversation where you’re the only person who isn’t a specialist.
Here’s a test that takes about five minutes and settles more of this than a month of vendor calls.
The complaint test
Write down the five things that most frustrate you about your current site. Not aspirations — actual complaints, in the words you’d use to a peer.
Now, for each one, ask a single question:
Does this complaint survive a platform change?
Be honest, because most of them do. Work through a typical list:
“Checkout is clunky.” This might genuinely be platform-shaped. Checkout is one of the few places where the platform meaningfully constrains what you can do.
“Nobody can find the right product.” This almost never is. That’s taxonomy, attribute hygiene, and merchandising — all of which you built, and all of which will export cleanly into the new platform and be waiting for you on the other side, intact.
“The site looks dated.” That’s a design and content problem. It is solvable at roughly 5% of the cost of a replatform, on your current stack, this quarter.
“It takes forever to get anything changed.” Sometimes platform. More often a resourcing and process problem, and it will follow you — because the new build will also need someone to make changes, and you’ll be under a maintenance contract with a partner whose hourly rate you haven’t negotiated yet.
“Our conversion rate is bad.” Almost never platform. A conversion rate is a symptom of the offer, the traffic, and the trust, in that order. No platform touches any of those three.
If four of your five complaints survive the platform change, you don’t have a platform problem. You have a merchandising, offer, or ownership problem that has been misfiled — and a rebuild will carry it across in the export file at a cost of six figures and two quarters of roadmap.
Why the platform gets blamed
Not because anyone’s foolish. Because of where the line items are.
Merchandising doesn’t have a vendor. Offer strategy doesn’t have a demo. “Nobody owns the conversion rate” doesn’t have a purchase order or a slide deck or a rep who takes you to dinner. The platform has all of those things. It is the only candidate in the lineup that comes with a solution attached, so it’s the one that gets accused.
And there’s a second force. In the room where the rebuild gets proposed, look around at who’s advising you. The agency bills the build. The platform sells the license. The systems integrator staffs the project. The new CTO gets a mandate and a budget. Every person offering you counsel is compensated by the same answer.
That doesn’t make any of them dishonest. It makes them structurally unable to generate the alternative. A build team recommends builds the way a surgeon recommends surgery — sincerely, competently, and from a position that cannot produce “do nothing” as an output.
Three questions that separate a sound recommendation from a staffed one, all fair to ask out loud:
- “What would you recommend if we had no budget for a rebuild?” A good partner has a real answer. A staffed recommendation goes quiet.
- “What’s the smallest change that would test the same thesis?” If the thesis is “our checkout is losing us money,” there’s almost always a cheaper way to find out whether that’s true.
- “Who on your team gets reassigned if we say no?” Slightly rude. Extremely clarifying.
The base rates nobody quotes
Set aside ecommerce for a moment. Large technology projects have been studied for decades, and the findings are stable and unkind.
McKinsey and Oxford examined 5,400 large IT projects. The average ran 45% over budget and delivered 56% less value than predicted. Seventeen percent went so badly they threatened the existence of the company.
Flyvbjerg and Budzier, writing in Harvard Business Review from a database of 1,471 projects, found that one in six is a “black swan” — averaging a 200% cost overrun and a roughly 70% schedule overrun. The averages hide the tail, and the tail is fat.
The number that should actually stop you is from Flyvbjerg and Gardner’s analysis of over 16,000 projects: 47.9% came in on budget. 8.5% came in on budget and on time. And 0.5% came in on budget, on time, and delivered the benefits that justified the project.
One in two hundred. That’s the base rate you’re betting against, and nothing about ecommerce exempts you from it.
These are four of about thirty numbers nobody puts on one page for you.
Get the Replatform Reality File → Free, 15 pages, every stat sourced.
The thing that isn’t there
Now for the finding that surprised me most when I went looking.
There is no independent, methodology-backed study of post-replatform ROI, conversion lift, or merchant regret. Anywhere. I looked hard.
Every positive outcome number in this category is vendor-commissioned — a platform’s own survey, or a consultancy’s paid study, or an agency’s case study with no control group. The strongest independent evidence that exists runs the other direction entirely: the IT project base rates above, the migration traffic data, Marks & Spencer’s 8.1% online sales drop after a £150M rebuild.
So for a decision that Digital Commerce 360 puts at $25K to $500K of planned spend, the evidence base is: vendor marketing on one side, general project-failure base rates on the other, and silence in the middle.
That silence is not neutral. If replatforming reliably produced the returns the category claims, somebody would have published the study. It would be the single most valuable piece of content any platform could own.
Worth noting: Forrester’s own B2C commerce lead wrote in 2024 that digital leaders are now extending platform life rather than replacing it, quoting the sentiment directly — “I can’t justify the costs and the business case to replatform.” That’s a research firm that sells to platform vendors, reporting that its clients’ customers have started saying no.
When the rebuild genuinely is right
This is not a blanket no, and I’d be doing you a disservice if I left it there. There are four conditions where replatforming is the correct call, and if you’re in one of them, stop reading and go do it properly.
1. The platform blocks a revenue model you’ve already proven demand for. Not “we might want subscriptions someday.” Customers are asking for B2B tiered pricing and you’re turning them away. You have a waitlist for a subscription you can’t build. You’re losing international orders you could fulfill. Proven demand, currently blocked.
2. Total cost of ownership is being consumed by workarounds rather than by the license. If you’re paying to maintain a scaffolding of plugins, custom code, and manual processes that exist purely to make the platform do something it wasn’t built for, you’re already paying for a replatform. You’re just paying in installments and not getting one.
3. The platform is a security or compliance liability. Unsupported versions, unpatched vulnerabilities, a payment or accessibility requirement you can’t meet. This one has a deadline attached whether you like it or not.
4. You cannot hire people who will work on it. If the talent pool for your stack has evaporated, every future problem gets more expensive and slower to solve. That compounds, and it doesn’t reverse.
Notice what isn’t on that list. It feels dated. A competitor moved. The agency recommended it. The new CTO doesn’t like it. Everyone else is on Shopify now.
Those are real feelings. They’re not business cases.
Two things worth reading before you decide either way: why the platform comparison you’ve been running covers only about 30% of the cost, and what actually happens to your organic traffic after a migration — the number there is the one most business cases leave out entirely.
The question underneath all of it
If you take one thing from this: the replatform decision belongs to whoever owns the revenue number.
Not IT, who will correctly optimize for maintainability. Not the agency, who will correctly optimize for scope. Not the CEO alone, who will optimize for the most recent compelling pitch. The only defensible justification for a rebuild is a revenue mechanic, so the decision belongs to the person accountable for revenue.
Which is a problem when nobody actually owns that number — and in my experience, that’s the real finding underneath most bad replatform decisions. The rebuild isn’t chosen. It’s what happens when a decision with no owner meets a vendor with a proposal.
Sources
- Bloch, M., Blumberg, S., & Laartz, J. (2012). Delivering large-scale IT projects on time, on budget, and on value. McKinsey & Company / University of Oxford (5,400 projects).
- Flyvbjerg, B., & Budzier, A. (2011, September). Why your IT project may be riskier than you think. Harvard Business Review (n=1,471).
- Flyvbjerg, B., & Gardner, D. (2023). How Big Things Get Done. Oxford project database, 16,000+ projects.
- Digital Commerce 360. Merchant platform-switching surveys, 2020–2022 — 27–28% in-market at any given time; planned spend $25K–$500K.
- Pfeiffer, E. (2024, May). Forrester blog — B2C commerce platform life extension.
- Marks & Spencer plc. Public trading statement, 2014.


