Most operations leaders know their ERP system is ageing. The signs are rarely subtle – workarounds documented in spreadsheets that nobody fully owns, reports that take hours to generate, integration points that break whenever a connected system updates. Yet the decision to upgrade keeps getting deferred. Another quarter, another budget cycle, another competing priority.
What is less understood is that postponing the upgrade does not pause the cost – it simply shifts it from visible project expenditure to invisible operational drag. According to Novacura, which provides expertise in the IFS upgrade process, the accumulated cost of staying on an outdated platform typically exceeds the upgrade investment well before the project is finally approved.
Understanding where those costs actually accumulate is the first step toward making a more rational decision about timing.
The Compounding Problem of Technical Debt
Every customisation applied to an older ERP version is a liability that grows over time. When a manufacturer modifies IFS Applications 9 to handle a specific production reporting requirement, that modification works – until the underlying platform changes around it. At that point, the modification either breaks or requires rework to remain functional.
The deeper problem is not any single customisation. It is the interaction between dozens of them. Each one narrows the path to a future upgrade, because every modified component needs to be identified, documented, tested, and either migrated or rebuilt. Organisations that have been running the same ERP version for seven or eight years frequently discover during pre-upgrade assessments that their modification inventory is larger than anyone realised – including the IT team responsible for maintaining it.
Technical debt of this kind does not sit still. It actively slows the organisation down by making routine changes harder, testing cycles longer, and vendor support thinner as the platform version ages out of active maintenance.
What “Unsupported” Actually Costs in Practice
When an ERP version reaches end of mainstream support, the immediate impact is often understated. Vendors do not typically switch off older versions overnight – they simply stop issuing security patches, functional updates, and integration fixes for them. The operational consequences take time to surface, but they are predictable.
Running an unsupported ERP version exposes the business to several compounding risks:
- Security vulnerabilities that are identified in newer versions but not backported to legacy releases
- Connector failures when third-party systems update their APIs and the older ERP version cannot accommodate the change
- Compliance gaps when regulatory reporting requirements shift and the platform cannot generate the required output format
- Loss of vendor support for critical incidents, leaving the organisation dependent on internal knowledge or expensive emergency consulting
Each of these risks carries a financial tail. A compliance gap in financial reporting, for instance, is not just an IT problem – it is a finance and legal problem with associated remediation costs. The probability of encountering at least one of these scenarios increases significantly with each year the upgrade is deferred.
The Misconception About Upgrade Scope
One of the most persistent errors operations leaders make is equating an ERP upgrade with a full reimplementation. The assumption is that moving from IFS Applications to IFS Cloud requires rebuilding everything from scratch – all configurations, all customisations, all integrations, all training materials.
That assumption is incorrect, and it inflates the perceived cost of upgrading to the point where deferral feels rational when it is not.
A well-scoped upgrade project distinguishes between what must be migrated, what should be rebuilt in a cleaner form, and what can simply be retired because the business process it supported has since changed. Organisations that approach the upgrade as a structured migration rather than a blank-slate deployment typically find the scope more manageable than initial estimates suggested.
The key is having an accurate picture of the current system state before scoping begins. That means a pre-upgrade assessment covering active customisations, integration dependencies, data quality issues, and the gap between current system behaviour and the target platform’s standard functionality. Skipping that assessment – or conducting it superficially – is where upgrade projects most commonly generate unexpected cost.
Why Timing Matters More Than Most Leaders Realise
There is a compounding logic to ERP upgrade timing that works against organisations which delay. The longer a business runs on an older platform, the more its processes adapt to the system’s limitations rather than the system adapting to operational needs. Workarounds become embedded in how people work. Unofficial data sources – local spreadsheets, shadow databases, manual reconciliation routines – become load-bearing parts of the operation.
When the upgrade eventually happens, the project now has to account for all of those informal dependencies. Data that lives in a spreadsheet needs to be assessed, cleaned, and migrated. Processes built around system limitations need to be redesigned. Staff trained on workarounds need reorientation toward standard functionality. None of that appears in an upgrade proposal built on the assumption that the current system is the source of truth.
Upgrading earlier – while the gap between the current platform and operational reality is still narrow – reduces this hidden scope considerably. The project is cleaner, the data is closer to a reliable state, and the retraining burden is lower.
How to Build a More Honest Business Case
Accurately accounting for the cost of delay requires going beyond the upgrade project budget and calculating what the current situation is already costing. A more complete picture includes:
- Hours spent per month on manual workarounds that a current-version platform would handle automatically
- IT team time consumed by maintaining ageing integrations and custom modifications
- Vendor support costs for out-of-mainstream-support incidents
- Risk-adjusted cost of compliance exposure from reporting limitations
- Opportunity cost of features available in current platform versions that the business cannot access
When these figures are aggregated over a two or three-year deferral period, the result frequently changes the framing of the upgrade decision entirely. The question shifts from “can we afford to upgrade?” to “can we afford to keep deferring?”
Conclusion
Deferring an ERP upgrade rarely saves money. It reallocates cost from a planned, manageable project into unplanned operational friction, growing technical debt, and escalating risk exposure. Operations leaders who make that trade-off typically do so based on an incomplete view of what staying put actually costs.
The more productive framing is to treat the upgrade decision as a risk management question rather than a capital expenditure question. Approached that way, the calculus tends to change – and the case for acting sooner becomes considerably harder to argue against.
