Every year I get brought into conversations that start the same way: “We need to replatform.” Sometimes the pain is real. More often, someone went to a conference, saw a slick demo, and came back convinced the current platform is the problem. It rarely is. Or at least, it is rarely the whole problem.
Replatforming is one of the most expensive, disruptive things a retail business can do. Get it right and you unlock years of growth. Get it wrong, or get the timing wrong, and you burn millions while your competitors keep shipping.
Here is how I think about it after doing this work for nearly two decades.
Why most replatforms happen for the wrong reasons
The vendor ecosystem has a strong incentive to convince you that your current platform is holding you back. Sales teams are good at this. They will find your pain points, amplify them, and present their product as the solution. That is their job.
But the most common triggers I see for replatforming conversations are not commercial constraints. They are emotional ones. A new CTO arrives and wants to put their stamp on the stack. A board member reads a Gartner report. The development team is frustrated with the codebase and frames it as a platform limitation when it is actually a technical debt problem they created.
The “we’ve outgrown it” narrative is particularly dangerous because it sounds reasonable. But when I ask teams to quantify what “outgrown” means, they struggle. Outgrown in what dimension? Transaction volume? Product catalogue complexity? International expansion? Each of these has different solutions, and not all of them require a new platform.
I have seen businesses spend $2M and 18 months replatforming only to discover that their real problem was a poorly integrated OMS, or a content management bottleneck that a headless CMS would have solved for a tenth of the cost.
Before you commit to a replatform, be honest about whether you are solving a platform problem or an architecture problem. They are different things.
Five genuine signals it is time
That said, there are real signals that a platform has reached its limits. Here is what I look for.
The integration ceiling. Your platform cannot connect to the systems your business needs without heroic workarounds. Every new integration takes months instead of weeks. You are maintaining custom middleware that nobody fully understands. When the cost of connecting new capabilities exceeds the cost of the capabilities themselves, you have hit a ceiling.
Speed to market degradation. Features that used to take two weeks now take two months. Simple changes require regression testing across the entire site. Your release cadence has slowed to the point where the business is planning around technology constraints rather than market opportunities. This is measurable. If your deployment frequency has halved in the last two years while your team has grown, something structural is wrong.
TCO trajectory. Plot your total cost of ownership over the last three years: licence, hosting, support, development, and maintenance. If the curve is accelerating and the value delivered is flat or declining, the economics are telling you something. I have seen platforms where 70% of development spend goes to maintenance and workarounds, leaving 30% for new capability. That ratio should concern you.
Operational bottlenecks. The merchandising team cannot update promotions without developer involvement. The content team is working around CMS limitations with manual processes. Customer service cannot access a unified view of the customer. When the platform forces operational workarounds that consume headcount, the cost is real even if it does not show up in the technology budget.
Talent constraints. Your platform runs on a technology stack that makes hiring difficult. The developer community is shrinking. The vendor’s investment in the platform is visibly declining. Fewer releases, slower bug fixes, key people leaving. This is a leading indicator. By the time it becomes acute, you are already behind.
If three or more of these resonate and you can back them with data, the conversation about replatforming is legitimate.
The hidden costs nobody talks about
The licence cost is the number everyone fixates on, and it is usually the smallest part of the total investment. Here is what actually consumes the budget and the organisational energy.
Team distraction. For 12 to 18 months, your best people will be split between running the current platform and building the new one. Productivity on both drops. Features that the business needs today get deferred because the team is focused on the migration. I have watched businesses lose meaningful market share during replatforms because they simply could not ship fast enough on either platform.
Re-training. Every team that touches the platform, from developers to merchandisers to customer service, needs to learn new tools, new workflows, and new mental models. This is not a two-day training course. It is months of reduced productivity while people build fluency. Budget for it explicitly or it will bite you.
Data migration risk. Customer data, order history, product catalogues, SEO equity. Moving this cleanly is painstaking work. I have seen migrations that technically succeeded but lost years of customer segmentation data because nobody mapped the taxonomy properly. The business impact of that loss took months to become visible and years to recover from.
Integration rebuilds. Every integration you have today needs to be rebuilt or replaced. ERP, OMS, WMS, PIM, CRM, payment gateways, loyalty platforms, analytics. Each one is a mini-project with its own complexity and risk. The “lift and shift” promise that vendors sell rarely survives contact with your actual integration landscape.
How to build a real business case
A good replatforming business case starts with commercial constraint, not a feature wishlist. The question is not “what can the new platform do?” It is “what can the business not do today, and what is that costing us?”
Frame every requirement in commercial terms. “We cannot launch in a new market because the platform does not support multi-currency natively” is a business case. “We want a better content editing experience” is a preference. Both might be valid, but only one justifies the disruption.
Quantify the cost of inaction. If you stay on the current platform for three more years, what does the TCO look like? What revenue opportunities will you miss? What operational costs will continue to grow? This is your baseline, and the replatform business case needs to beat it convincingly, not marginally.
Be ruthless about what is a platform problem versus a process problem versus a people problem. I routinely find that 30 to 40% of the “requirements” in a replatforming RFP could be solved without changing platforms. Strip those out. They cloud the evaluation and inflate the scope.
What good timing looks like
Even when the business case is solid, timing matters enormously.
You need organisational capacity. If the business is mid-restructure, or recovering from a difficult trading period, or about to enter peak season, it is the wrong time. Replatforming requires sustained executive attention and team bandwidth. If those are not available, the programme will drift.
You need genuine executive sponsorship, and not just a verbal commitment. The sponsor needs to be prepared to make trade-offs, resolve disputes, and shield the programme from scope creep for 12 to 18 months. If the most senior sponsor is a Head of Digital with no P&L authority, the programme is under-sponsored.
You need an 18-month runway. Not because every replatform takes that long, but because you need buffer for the things that will go wrong. If the board expects results in six months, you are setting the programme up to fail.
And you need a clear picture of what “done” looks like. Not a vague notion of “better platform” but specific, measurable outcomes. Revenue capability unlocked, time-to-market improved by a defined amount, operational cost reduced by a specific figure. Without this, you will never know whether the investment paid off.
Common mistakes
Letting the vendor lead the evaluation. Vendors will frame the conversation around their strengths. Your job is to frame it around your problems. Write your requirements before you speak to vendors, not after.
Underestimating change management. Every replatform is an organisational change programme with a technology component, not the other way around. The businesses that succeed invest as heavily in change management as they do in implementation.
Not planning for the messy middle. Months four through twelve are brutal. The initial excitement has faded, the hard integration work is underway, and the business is starting to feel the cost of running two platforms. Plan for this. Communicate openly about it. The teams that pretend it will be smooth are the ones that lose people.
Treating it as a technology project. If your replatform is owned entirely by technology, it will deliver a technically sound platform that the business does not fully adopt. The best replatforms I have seen are co-owned by technology and commercial leadership, with shared accountability for outcomes.
Going big-bang. The temptation to “do it all at once” is strong, especially when the vendor promises it. Resist it. Phase the migration. Launch with core capability, prove it works, then extend. Every big-bang replatform I have been involved with has either failed outright or delivered late and over budget.
Next steps
If you are weighing up a replatform decision and want an honest assessment of whether the timing and business case stack up, that is exactly the kind of engagement I take on as a fractional CTO. I will tell you whether you need a new platform, a better architecture, or just a sharper team. Get in touch to start the conversation.
What to read next
- How to choose an e-commerce platform without getting it wrong — Once you’ve confirmed a replatform is the right move, how to choose the right platform.
- What usually goes wrong in retail technology transformation — The failure patterns that technology programmes must actively avoid.