The email arrives. Your current software version is approaching end of support, and the vendor has attached a quote for the software upgrade. It’s a big number, and it isn’t optional. Stay on the old version, and you lose support, security patches, and eventually compliance.
If that sounds familiar, you’re not being singled out. It’s how traditional enterprise software works. But before you sign off on the bill, it’s worth understanding why it exists at all, and asking three questions that vendors would rather you didn’t.
Why upgrades cost so much in the first place
On a traditional system, your customisations live inside the product itself. Every calculation, report, and workflow you’ve added over the years is woven into the code or the database underneath it.
So when the vendor releases a new version, your system can’t simply move to it. Every customisation has to be checked, reworked, and tested against the new release. That’s not an update. It’s a mini re-implementation, complete with consultants, regression testing, and downtime. And because it’s painful, many operators skip versions and fall further behind, which only makes the next upgrade bigger.
This is worth knowing because it isn’t inevitable. It’s an architectural choice. On a platform where your configuration is stored as metadata, completely separate from the product code, upgrades don’t touch your work at all. Everyone runs the latest version, updates arrive without disruption, and there’s no upgrade project because there’s nothing to re-implement. Our Why PaaS page explains how that separation works.
With that in mind, here are the three questions.
1. What do the software upgrade costs actually cover?
Look closely at the quote. Most of it isn’t new capability. It’s the cost of moving what you already have onto a version the vendor is willing to support. You’re paying to stand still.
That matters more than it used to. PwC’s UK cloud survey found that organisations which have properly modernised their systems are realising value at twice the rate of those running outdated ones. The same research notes that a third of companies are only using the cloud to rewrite or rehost existing applications, which suggests that many “upgrades” deliver newer versions of the same limitations.
So ask the vendor directly: after this project, what can my team do that it couldn’t do before? If the honest answer is “receive support for another few years”, that’s a maintenance fee wearing an invoice for progress.
2. What will the next one cost?
An upgrade quote is never really a one-off. It’s one instalment in a cycle. If the architecture hasn’t changed, you’ll be back here in a few years with another version, another project, and another bill.
Add up the full picture. What do you spend on consultants or specialists every time something needs to change? How hard is it to train new people on an ageing system? What does it cost to scale up or down as assets come and go? These costs rarely appear on a single invoice, which is exactly why they’re easy to underestimate.
The wider industry context sharpens the question. Deloitte’s 2026 Oil and Gas Industry Outlook points to tightening margins, disciplined capital allocation, and digitally enabled operations becoming the next frontier for competitiveness. In that environment, committing budget to a recurring cycle of standing-still projects is a hard position to defend.
3. Is there an alternative to upgrading at all?
This is the question the quote is designed to stop you asking. An upgrade bill only makes sense if replacing the system is assumed to be harder and more expensive. Increasingly, it isn’t.
On a configurable platform, a new implementation is built through configuration, using standard spreadsheet functions and formulas your team already knows. Your own domain experts, the people who understand the calculations and the contracts, do the building. No software development, no army of specialists.
You also get a choice in how to approach it. Configure it yourselves and keep full control of the process. Take a phased approach, onboarding one asset at a time so you only pay for what you use. Or have a partner deliver the implementation with you, bringing platform knowledge and configuration patterns from projects like yours. Template applications for common solutions can give you a head start, provided you check you can extend and modify them yourself later.
And crucially, once you’ve moved, the upgrade cycle ends. Upgrades are included in the subscription, arrive without disruption, and never touch your configuration. You’ll never plan or pay for an upgrade project again. It’s worth saying that adoption alone doesn’t guarantee this: PwC found that while 78% of business leaders have adopted cloud in most of their organisation, over half aren’t yet seeing the outcomes they wanted. The difference lies in how the software is built, not where it’s hosted. A legacy product moved into a hosted environment still upgrades like a legacy product.
The real decision
An upgrade quote feels like a bill, but it’s actually a decision point. You can pay to keep the system you have, knowing the same bill will return. Or you can put that budget towards a system your own team can build, change, and never have to upgrade again.
Before you sign anything, do the comparison properly. Ask what the upgrade actually delivers, what the full cycle costs, and what the alternative looks like. If you want to see what an implementation involves in practice, we’ve laid it out on our Implementation page.
One Comment