Iain Saunderson, CTO, Spinnaker Support, explains why staying current with vendor-led upgrades may introduce more risk than it resolves.
Enterprise IT strategy has long rested on a deceptively simple assumption: staying current reduces risk. It’s conventional wisdom that up-to-date software is more secure, better supported, easier to defend in an audit, and ultimately a more sustainable foundation for managing technical debt over time.
The reasoning here has always seemed straightforward. Vendors promise that current versions of their software are more secure, better supported, and less exposed to the kind of entropy that makes ageing systems expensive to maintain. Audit frameworks reinforce it and procurement teams build it into policy. Over time, staying current stopped being a considered decision and became a default – something organisations do because the alternative feels riskier.
The problem is that nobody stress-tests the assumption against the reality of what a major upgrade actually involves. Technical debt doesn’t disappear when a new ERP version arrives. In complex enterprise environments – where years of bespoke configuration, custom integrations and undocumented dependencies have accumulated – an upgrade can expose incompatibilities that were invisible in the old environment, causing failures that are difficult to diagnose and expensive to fix.
Gartner estimates that more than 70% of ERP implementations fail to meet their original business objectives – and that’s before accounting for the years of bespoke configuration that make any major upgrade considerably more challenging than a clean deployment.
The journey to a more maintainable platform can become a substantial source of risk in its own right. But of course, you won’t see that in your ERP contract.
The complexity problem is being consistently underestimated
Modern upgrades come with considerably more upheaval than they did a decade ago. Even minor version changes can carry modifications to architecture, dependencies or integration behaviour that only reveal themselves once something has already broken.
Consider a manufacturing environment running a tightly integrated ERP stack: a production line cannot simply go offline for a cutover window and there is no straightforward way to guarantee that a version change won’t break a critical interoperability dependency mid-process. The failure modes aren’t always obvious in testing. They arise in production, often at the worst possible moment and often in ways that were genuinely difficult to anticipate.
Compounding this challenge is the pace at which vendors now release updates. Security patches, feature changes and platform updates arrive faster than most organisations can safely absorb, test and operationalise them.
For IT teams already stretched across incident response, operational responsibilities and ongoing monitoring, each new update cycle is another demand on their limited capacity. Absorbing change as and when the vendor demands it is not always possible and attempting to do so without adequate preparation creates its own exposure.
The irony is not lost on most IT leaders: the very mechanism designed to reduce long-term technical burden can, in the short term, become a significant form of it.
The result is a category of risk that you won’t find in compliance frameworks: transition risk. Configuration drift during migration, unexpected downtime during cutover, security gaps that open briefly – and sometimes not so briefly – while teams work to stabilise a new environment, and temporary loss of visibility as monitoring tools recalibrate to a changed state.
These are all recurring features of complex enterprise upgrades, yet they almost never appear in the business case that authorised the change. By the time they’re visible, someone is already managing the fallout.
Before committing to a major upgrade, an organisation needs to answer one question honestly: can it maintain visibility, control and stability during and after the change? In many environments, the answer is no. And that’s a red flag.
Staying current isn’t the same as staying stable
Here is where IT, security and audit teams may find themselves in uncomfortable territory. Vendor support status is a poor proxy for operational risk. Software can be fully supported, regularly patched and actively maintained – and still represent a higher risk profile than a stable, well-understood system running an older version.
Risk isn’t determined solely by software age. It is shaped by the predictability of system behaviour, the stability of integrations, the maturity of internal controls around that environment and – critically – the familiarity of the teams responsible for monitoring and responding to incidents.
Constant change – the thing vendors are often selling as security – systematically erodes the very conditions that make an environment defensible. ‘Supported’ in essence means ‘in flux’ and flux is inherently harder to secure. A team that knows exactly how a system behaves, knows where to look when something goes wrong and has years of institutional knowledge built around that environment is not a security liability.
Increasingly, IT leaders understand this. The conditions that make an environment defensible – stable behaviour, predictable integrations, teams with deep operational familiarity – are not automatically preserved through an upgrade cycle. In environments with significant integration complexity, they can take months to rebuild after a major change.
This doesn’t mean upgrades should always be off the table. But it does mean they should no longer be treated as an automatic risk-reduction mechanism, which is how they have traditionally been framed.
The questions worth asking before committing
All of this points to a more fundamental problem with how upgrade decisions are currently made. The question that matters isn’t ‘are we current?’ – it’s ‘can we absorb this change safely?’
That requires a different kind of assessment. What risk does this upgrade introduce and over what timeframe? What is the operational exposure during transition? What happens if the cutover stalls or fails and who owns that?
In ERP environments in particular, failures are expensive, highly visible and difficult to reverse. Deferring an upgrade in those circumstances is a considered risk-mitigation decision and one that deserves to be documented and defended as such.
This is a genuinely novel challenge, because it runs against the grain of how upgrade cycles have been sold and enforced. Vendors have strong commercial interests in keeping customers on current versions and they frame that pressure around security and technical debt reduction, regardless of whether the organisation is ready – or wants – to absorb the change.
Ultimately, the most important question IT leaders must ask about ERP systems is never actually about whether, or when, to upgrade. It’s about whether the risks that come with upgrading have been properly understood – or simply assumed away by a vendor with a stake in the answer.
