Stuart Totterdell
Technical Director
You did not put ERP transformation on this year's plan. The vendor did.
A renewal letter arrived with a number that made the FD sit forward, or support for your current version got a hard stop, or the roadmap now says on-premise is a dead end and cloud is the only supported path forward. Suddenly the conversation is no longer "should we improve operations" - it is "what do we do before this date." That is how a lot of mid-market ERP change actually starts: not with a vision, but with a forced conversation, and forced conversations reliably produce panic buying unless someone deliberately slows the room down.
The vendor set the clock. You still own the decision
End of support, price shock, and cloud mandates are real constraints, but they are not a strategy in themselves. Vendors are entitled to commercialise their platforms however they see fit, and you are equally entitled to treat their timeline as an input rather than a verdict. The worst outcomes happen when a business accepts the vendor's framing wholesale - migrate to our cloud now, buy the successor product now, extend with multi-year terms now - because the alternative has been painted as existential.
Sometimes the risk of staying is genuine: unpatched systems, withdrawn support, and rising incident exposure are not theoretical concerns. Sometimes the "risk" is mostly commercial pressure dressed up as technical destiny. An ERP renewal process that cannot tell those two things apart will always overpay for urgency.
Price shock is a finance event and an ops signal
A renewal hike is not only a procurement problem - it is genuinely useful information, if you read it properly. If the increase is steep, it is worth asking exactly what you are buying for that money: the same modules at lower utilisation, a forced move to a different commercial metric, bundled products you never actually requested, or a migration path that quietly transfers implementation risk onto you under a support deadline. Finance should model five-year total cost of ownership including licences, partner fees, internal project load, dual running, training, and lost productivity, rather than simply the year-one figure sitting on the renewal email.
Ops should be asking a parallel question at the same time: if the business is about to spend this much just to stay current, what operational outcomes does that actually secure? Continuity alone can be a valid answer on its own, but continuity plus the same unused modules, the same brittle customisations, and the same spreadsheet layer underneath it all is a poor use of a genuine crisis moment.
Cloud mandate is not the same as cloud readiness
Many mid-market estates are being told the future is cloud, whether the data, integrations, and process discipline underneath them are actually ready or not. Moving the hosting model without cleaning masters, simplifying customisations, or clarifying which processes must stay in the core is a reliable way to recreate today's mess on a subscription instead of a licence. The mandate may genuinely force a decision on infrastructure and support, but it should never force you to skip assessment of fit, adoption, and integration debt along the way.
This is exactly where independent tech consultancy earns its keep - separating "we must leave unsupported software" from "we must accept this particular migration package on this particular timetable." Those two statements get glued together constantly in vendor narratives, and it is worth the effort to pull them apart deliberately.
Do not panic-buy the successor suite
When end-of-life or renewal pressure hits, the demo carousel starts almost immediately: successor products, competitive rip-and-replace pitches, partner-led "upgrade programmes" with aggressive start dates already attached. Pause before any of it, and define the decision you are actually making. Is this a commercial renegotiation, a technical risk reduction, an opportunity to simplify the estate, or a genuine platform change because industry fit or scalability has actually failed? Each of those paths carries different evidence requirements, and collapsing them all into "we need a new ERP by Q3" is a reliable way to buy software purely to relieve anxiety.
Assess before you react: utilisation of what you already pay for, support and knowledge risk, master data condition, industry fit gaps, the integration estate, and a realistic total cost of ownership for both staying and changing. That assessment can run on a commercial clock without ever surrendering the outcome to the vendor's preferred SKU.
TCO honesty beats timeline theatre
Boards approve bad ERP spend when the alternative is framed as a cliff edge and the proposal in front of them is framed as the only available bridge. Demand a comparison that genuinely includes the cost of staying with mitigation, the cost of upgrading in place, and the cost of changing platform entirely, each stated plainly alongside its risk, duration, and operational disruption. Include the cost of doing nothing until the last minute and then paying overtime rates for a compressed programme, and include the cost of signing a long renewal that quietly removes optionality while you "think it over."
Pair those numbers with IT and process strategy so the conversation stays anchored to operating outcomes rather than just licence lines on a spreadsheet. A cheaper renewal that locks in a broken operating model is not a win. An expensive migration that merely relocates the same workarounds elsewhere is not transformation either.
Take back the agenda
Your ERP renewal forced the conversation. Good - use it properly. Do not pretend the deadline is imaginary, and do not pretend the vendor's preferred path is automatically the only rational one available. Get clear on risk, cost, and what the business genuinely needs the estate to do for the next five years, then negotiate, remediate, or change in that order of preference, unless the evidence clearly says otherwise.
Forced conversations tend to favour whoever arrives with a proposal already in hand. Arrive with an assessment instead.


