A few years ago I sat in a boardroom reviewing a seven-figure ecommerce investment. The platform was a Magic Quadrant leader. The implementation partner was global. The architecture slide was immaculate.
Behind the slide: pricing managed in Excel. No structured PIM. No OMS. Inventory visibility dependent on workarounds the incumbent team had built over years and no longer fully understood.
The board approved it anyway, because it was Tier 1. That decision added nine months of complexity before a single customer saw a benefit. It was not unusual. It is endemic.
Before you commit £3m to a replatform, establish whether the platform is the constraint
Across multiple £200m+ retailers, PLCs and heritage brands alike, I have watched enterprise platforms implemented on top of fragile operating models. The most instructive failure I have seen was a governance failure rather than a technology one. Four business functions were left out of the replatforming requirements process. Each surfaced its problem only after go-live, when the cost of fixing it had multiplied.
The four conversations nobody had
1. Account management functionality was assumed, not validated.
Customer services had been using parts of the incumbent platform to manage customer accounts. No equivalent existed in the replacement. A complex development, parsing data across four integrated systems, was required to replicate what had been a standard workflow. Result: an unplanned integration programme after launch.
2. Returns processing was rebuilt from scratch, badly.
The supply chain team had been using the incumbent platform to manage returns. A bespoke development between the ERP and the new platform was needed to trigger returns processing, and the operator UX was destroyed in the process. A 30-second workflow became a 2-minute one. At peak volumes the bottleneck was felt across the operation. Result: a fourfold increase in returns processing time at peak.
3. Month-end reconciliation lost a day, every month.
Finance had been using the incumbent platform for reconciliation. No equivalent capability existed in the replacement. The workaround added a full day of manual work to every month-end close, permanently. Multiplied across a year, that is a material operating cost that appeared nowhere in the business case.
4. CMS agility was assumed. A content straitjacket was inherited.
Marketing had assumed an agile CMS with launch preview, out-of-stock messaging and back-in-stock email as standard. None of it existed out of the box. The team that most needed speed found itself more constrained than before the migration. Result: phase two became structural rework rather than enhancement.
None of these were edge cases or implementation errors. They were the predictable consequence of a requirements process that involved the ecommerce and technology teams and not the operational functions that depended on the incumbent system for workflows they had quietly built over years. The vendor’s sales team did not surface them. The implementation partner’s discovery did not surface them. Go-live did.
The enterprise illusion
The platforms selected across the programmes I have worked on or observed: IBM WebSphere, SAP Hybris, Adobe Commerce, Salesforce Commerce Cloud. All powerful. All capable. All completely dependent on the organisational maturity of the business implementing them.
The recurring failure is what organisations bring to the platform: fragile data models, immature cross-functional ownership, pricing controlled in spreadsheets, thirty or more manual files to manage catalogue and price changes, and no structured OMS beneath a commerce layer that assumes one exists.
In one case the absence of an OMS meant replicating core order logic inside middleware, extending delivery by nine months. In another, spreadsheet pricing errors put high-value electronics on sale at a fraction of retail price. Enterprise platforms do not create the discipline these situations require. They expose its absence, at a scale and speed that makes recovery expensive.
“We will migrate now and optimise later”
The second failure mode. What actually happens is that old journeys are lifted and shifted. Legacy constraints become permanent features. Technical debt does not stay behind; it migrates with a fresh coat of paint and a slower resolution timeline. Backlogs balloon. Agencies become critical to daily operation. Internal teams turn risk-averse because every change is now a change to a system they do not fully own.
I have seen seven-year-old “temporary” repair and personalisation journeys carried straight into a new enterprise stack, untouched, because fixing them would have delayed go-live by three months. Five months after launch the business realised that marketing, finance, supply chain and customer services had never been properly embedded in requirements. Phase two became structural rework.
An MVP without a defined commercial end-state is not agility. It is deferred regret with a project code.
The replatform we did differently
Earlier in my career I faced a platform choice between IBM WebSphere Commerce and a significantly less prestigious alternative. IBM was the safer board narrative: the name a CFO would recognise and a CEO would feel comfortable reporting to investors.
The organisation lacked the governance cadence, the technical capability and the cross-functional maturity to extract value from it. We chose the more appropriate platform instead.
Revenue doubled. The platform carried eight years of stable, scalable trading. The business grew commercially before it needed to grow architecturally, which is the order these things should happen in.
Restraint beat prestige.
What boards are actually buying
When a leadership team says “we need Tier 1”, they are rarely making an architectural argument. They are buying psychological safety, investor defensibility and a logo they recognise from a Gartner slide.
That is understandable. “No one ever got sacked for buying enterprise” is a rational response to the career risk of a failed transformation. It is also how businesses end up paying for technology they cannot operate, implemented at a pace that prevents them embedding it, measured against KPIs that were never properly defined.
Buying complexity before capability does not accelerate growth. It accelerates the rate at which organisational weaknesses become expensive problems.
Six questions to ask of yourselves, not the vendor
- Is our product data governed and structured, or are we planning to sort that out in the new platform?
- Is pricing controlled beyond spreadsheets, or will the new platform inherit the same fragility with a better interface?
- Is inventory unified and real-time, or are we still routing through middleware workarounds?
- Have customer services, finance, supply chain and marketing been through a structured requirements process, rather than informed of a decision?
- Can our internal team operate this platform at full capability, or will we be agency-dependent within eighteen months?
- Is there a defined commercial end-state, or are we launching an MVP and hoping phase two gets funded?
In my judgement many mid-market retailers would generate more profit from six months of disciplined data governance and pricing control than from a £3m replatform. The platforms are not the problem. The process that selects and implements them usually is.
Where Barking Cat Advisory comes in
The Barking Cat Review answers the question above before a board answers it with a purchase order: whether the platform is the binding constraint, or whether something cheaper and less glamorous is. Barking Cat Advisory does not build, does not implement and does not earn from the platform decision in either direction, which is the only position from which “you do not need this” can be written down.
Before you commit to the replatform, establish whether the platform is the constraint.
Back to Thinking