When stability became strategy: the post-upgrade enterprise

There has never been more pressure to upgrade enterprise systems. Vendors set deadlines, analysts warn of falling behind, and the rhetoric is relentless – much of it built on a misconception about what security and compliance actually require. Stay current, stay competitive, or risk falling behind.

But something has changed in how organizations respond. The conversations happening in finance departments, IT strategy sessions, and boardrooms increasingly sound different from the vendor messaging.

Questions that used to be settled are being reopened. Decisions that were once treated as inevitable are now being examined as choices. Chief among them: should we be upgrading at all?

The numbers help explain why. Gartner predicts that by 2027, more than 70% of recently implemented ERP initiatives will fail to fully meet their original business case goals, with as many as 25% failing catastrophically. These are game-changing numbers – big enough to change the risk-reward calculation behind an upgrade.

Delaying an upgrade, once viewed as falling behind, increasingly looks like risk management. Staying on a mature system, previously dismissed as resistance to change, is being reframed as operational prudence.

This is deliberate: enterprises treating operational stability as strategy, not as a temporary state awaiting the next vendor-driven disruption.

What changed to make this position defensible?

ERP upgrades have always been complex, costly, unforgiving…and the graveyard of more than a few CIO careers. What’s changed isn’t the degree of difficulty. It’s the absence of a compelling reason to attempt it.

For most of the last two decades, the disruption was justified: new capabilities, genuine process improvement, competitive necessity. But not anymore. Installed ERP systems are, in many cases, performing exactly as intended, and the competitive advantages most enterprises are chasing no longer come from the ERP core itself.

They come from analytics layers built on top of it, automation tooling that sits beside it, or domain-specific applications that integrate with it but don't depend on it being perpetually upgraded. The platform has become infrastructure, with value derived from its stability and predictability.

The only compelling event left, for many organizations, is the vendor-imposed end-of-support deadline.

But the consequences of getting it wrong are severe.

Systems that have been running for fifteen, twenty years now connect to almost everything: data models reflecting decades of business logic, integrations spanning dozens of downstream applications, customizations embodying years of process refinement, workflows embedded in how thousands of people do their jobs.

Each connection is a dependency. Touch one part, and you affect all the others. This creates real operational exposure – just consider the case of Birmingham City Council’s Oracle ERP implementation, which went live in 2022.

The project has now cost over £170 million (that’s £150 million over budget), declared the council effectively bankrupt, and the system still isn’t fully operational. This is not theoretical risk so much as a predictable consequence of trying to change a system with years of compounding dependencies baked in.

The risk profile of change itself

What's fundamentally different now is that the risk calculation has inverted. The question used to be: can we afford not to upgrade? For many organizations, it's become: can we afford to?

Upgrades now involve extensive remediation of customizations, complex data migration across incompatible structures, revalidation of downstream systems, rebuilding integrations, and the retraining of users across the organization.

Each element introduces uncertainty. Together, they create a level of operational exposure that many organizations simply didn't face in earlier upgrade cycles. This is why so many transformation programs now run over time, over budget, or both.

So, a gap has opened between how upgrades are still framed – as necessary, routine, progress – and how they're experienced in practice. Vendors talk about innovation and competitive advantage, while organizations face months of disruption, spiraling costs, and operational risk that's difficult to quantify upfront.

From the outside, choosing to delay upgrades can look like inertia, taking the path of least resistance. But in practice, it's often a conscious choice, made in full awareness of the arguments for and against and, sometimes, in the face of huge pressure.

The choice to extend the life of a mature, stable ERP environment is frequently the outcome of detailed cost-risk analysis, operational dependency mapping, and honest assessment of internal change capacity.

For enterprises where ERP underpins finance, supply chains, or regulatory reporting, the tolerance for disruption is low. Stability, in this context, becomes a form of risk management.

The assumption that change is inherently safer than stability simply no longer holds.

Vendor pressure as a forcing function

This change in thinking is happening against a backdrop of increasing vendor pressure to upgrade ERP systems. SAP's approach exemplifies this perfectly: set a deadline for ending mainstream support, then watch as customers struggle to meet it.

At the end of 2024, only 39% of SAP ECC customers had migrated to S/4HANA – SAP's next-generation ERP platform.

At the current rate, Gartner projects that 17,000 organizations – representing nearly half the customer base – will still be running the legacy platform when the 2027 deadline arrives. SAP, notably, has stopped volunteering the numbers publicly.

SAP has offered extensions for select customers willing to commit to cloud subscriptions and specific technical requirements, but don't be fooled. These aren’t acts of generosity.

They’re a mechanism for locking customers into SAP’s cloud migration path, often before those customers fully understand what they’ve agreed to. The message is consistent across major vendors: the path forward runs through their cloud solution, on their timelines, under their pricing models.

Stability as deliberate strategy

Those 17,000 organizations still running ECC aren't simply procrastinating. Many have carefully considered the trade-offs and decided that the operational risk of migration outweighs the rewards (on vendor-imposed timelines, at least).

They're making a different calculation entirely: building new capabilities in layers that don't require touching the foundation, delaying large-scale migrations until there's a clear operational or commercial case beyond vendor deadlines, and prioritizing predictability and control over access to features they may not need.

But stability as strategy only holds if the foundation remains genuinely secure. The obvious objection – and vendors are quick to raise it – is that running without vendor support means running without security patches, without regulatory updates, and without recourse when something fundamental fails.

For organizations where ERP underpins finance, supply chains, or regulatory reporting, that’s a very real concern.

This is where the framing of “upgrade or lose support” does the most damage. It presents a false binary. Third-party support arrangements exist that provide ongoing security coverage, tax and regulatory updates, and incident response for mature and complex ERP environments exactly as they are.

Staying on a stable, well-understood system stops being a countdown to obsolescence and becomes a defensive position, provided the support infrastructure around it is robust.

Who controls the timeline

When vendors tie support to upgrade cycles, they're making business decisions that serve their commercial interests. Migration pressure becomes external, and CIOs lose control over decisions that carry significant operational consequences.

Restoring that control means establishing support arrangements that can't be unilaterally withdrawn or repriced.

It means maintaining the ability to run mature systems as long as they meet business requirements. It means recognizing that operational stability, in many environments, is worth more than incremental feature access.

This doesn't mean none of these organizations will ever upgrade. It means each one will upgrade when – and only when – the organization is ready: when internal change capacity exists, when the business case is clear, when the risk exposure is acceptable… not when a vendor finds it commercially convenient to sunset a product line.

Post-upgrade enterprises haven't rejected modernization. These organizations have simply decided what progress means in their specific context: stability first, change when genuinely warranted, control over timelines regardless of external pressure.

When failure rates are high and the operational consequences of disrupted upgrades can be severe, that position deserves consideration, not dismissal as resistance to change.

We've featured the best business plan software.

This article was produced as part of TechRadar Pro Perspectives, our channel to feature the best and brightest minds in the technology industry today.

The views expressed here are those of the author and are not necessarily those of TechRadarPro or Future plc. If you are interested in contributing find out more here: https://www.techradar.com/pro/perspectives-how-to-submit