Independent IFS Cloud practice · Clean Core
The IFS Cloud upgrade tax: why custom extensions break at every R1/R2 — and how to stop paying it
Key takeaways
- The IFS Cloud upgrade tax is the recurring cost of fixing customisations that break at each R1/R2 release — regression testing, hotfixes and delayed go-lives.
- Extensions built outside the IFS Extensibility Framework touch things IFS is free to change, so they break by design, not by accident.
- The cost is rarely a line item — it hides in test cycles, frozen backlogs and reputational drag every six months.
- Clean Core removes the tax by keeping every extension inside supported, versioned interfaces.
- Before your next release, inventory and classify every extension — Safe, Refactor, Rewrite or Retire.
Every IFS Cloud customer pays a tax they never signed up for. It arrives twice a year, on the schedule of the R1 and R2 releases, and it is collected in test hours, hotfixes and slipped go-live dates. If your last upgrade turned into a scramble — buyers unable to release orders, a report throwing errors, an integration silently dropping messages — you have felt it. This is the IFS Cloud upgrade tax, and most teams treat it as the price of doing business. It is not. It is the price of building in the wrong place.
1.What is the IFS Cloud upgrade tax?
The upgrade tax is the labour and delay you spend, every release, to keep customisations working across an IFS Cloud version change. IFS ships evergreen: the product moves forward on a fixed cadence, and each release can change database views, API signatures, page structures and internal logic. Standard functionality is carried across for you. Anything you bolted on that reaches past the supported surface is your problem to re-validate — and, when it breaks, your problem to fix under time pressure, with the release already booked.
The tax is not one invoice. It is a bundle of costs that recur on the release calendar:
- Regression testing every custom flow, twice a year
- Emergency hotfixes when something breaks in the new version
- Delayed go-lives while fixes are written and re-tested
- A frozen backlog — no new value ships during the scramble
- Consultant day rates spent re-doing work you already paid for
- Lost trust in the system from the people who depend on it
2.Why do custom extensions break at every release?
Extensions break because of where they are built, not how well. IFS Cloud draws a line: on one side is the supported Extensibility Framework — Custom Fields, Custom Events, Custom Logic, projections and configuration that IFS commits to carrying forward. On the other side is everything that reaches around that framework: code against internal packages, queries against volatile database views, page hacks, undocumented API calls, integrations wired to interfaces IFS never promised to keep.
IFS is free to change anything on the far side of that line, and each release it does. An extension anchored there is not unlucky when it breaks — it is doing exactly what an unsupported dependency does. The framework exists precisely so your logic rides on a contract IFS honours across versions. Step outside it and you have opted into the tax.
The rule of thumb: if IFS didn’t promise the interface would survive the upgrade, assume it won’t. Build against the surfaces IFS versions on purpose.
This is why two customers on the same release can have very different upgrade experiences. The one whose extensions live inside the framework re-validates and moves on; the one whose logic sits in modified core spends weeks. Same release, different bill. For the mechanism that keeps automation on the right side of the line, see IFS Custom Events explained.
3.What does the upgrade tax really cost?
The headline number — consultant days to fix broken customisations — is the smallest part. The expensive parts are the ones nobody puts on a purchase order.
| Cost | Where it hides | Who pays |
|---|---|---|
| Regression testing | Weeks of manual re-testing across every custom flow, each release | Key users, pulled off their day job |
| Hotfixes | Rushed fixes under a live deadline, often re-broken next release | IT budget and consultant day rates |
| Delayed go-live | The upgrade slips; the new version’s value is postponed | The whole business waiting on it |
| Frozen roadmap | No improvements ship while everyone firefights the release | Every team that wanted something built |
| Eroded trust | Users route around the system after each broken upgrade | Data quality and adoption, long-term |
Multiply that by two releases a year, over as long as you stay on IFS Cloud. The upgrade tax is not a one-off — it is an annuity you pay to your own technical debt, and it compounds every release you defer the fix.
4.How does Clean Core remove the tax?
Clean Core is a simple discipline with an outsized payoff: keep the standard product standard, and put every piece of custom logic inside the supported Extensibility Framework. When your extensions only touch surfaces IFS commits to versioning — Custom Events and Workflows, Custom Fields, projections, configuration delivered via ACPs, integrations over OData/REST — the release carries them forward the way it carries standard functionality forward.
The upgrade stops being a rebuild and becomes what it should be: a re-validation. You confirm your automations still fire, your reports still run, your integrations still exchange messages — and you move on. Nothing to hotfix, because nothing was anchored to something IFS was free to change.
- Automation via Custom Events + Workflows, not modified core
- Integration over supported OData/REST projections, not internal APIs
- Security through RBAC and Segregation of Duties, not bespoke workarounds
- Delivery as versioned ACPs you can move between environments cleanly
This is exactly how the Clean Core approach to IFS Cloud supply chain automation is built — supply-chain logic that survives the upgrade because it never left the framework. Clean Core is not a feature you buy. It is a rule you apply to everything you build, and it is the only durable way to stop paying the tax.
5.What should you do before the next release?
You cannot Clean-Core your way out of debt you cannot see. Before the next R1/R2 lands, get an honest picture of what you have and what it will cost you:
- Inventory every extension. List all customisations, reports, integrations and modifications — including the ones nobody owns any more.
- Classify the risk. Mark each one Safe, Refactor, Rewrite or Retire, based on whether it lives inside the framework or reaches outside it.
- Retire the dead weight. Every extension you switch off is one you never pay the tax on again.
- Refactor the fixable. Move logic that reaches outside the framework back onto supported interfaces before it breaks under deadline.
- Book a dry run. Validate in a test environment that mirrors production, so the real upgrade holds no surprises.
For the full pre-flight sequence, work through the IFS Cloud upgrade readiness checklist. If you want it done for you, the Update-Safe Audit delivers exactly this classification in 10 business days — every extension rated Safe / Refactor / Rewrite / Retire, with a fixed-price remediation roadmap.
6.Frequently asked questions
What exactly is the IFS Cloud upgrade tax?
It is the recurring cost of keeping customisations working across each IFS Cloud release — regression testing, emergency hotfixes and delayed go-lives that arrive on the R1/R2 schedule. It is rarely a single invoice; it hides in test hours, frozen backlogs and slipped dates every six months.
Why do my extensions break when IFS itself is upgraded cleanly?
Because the break is about where the extension is built. Standard functionality and anything inside the Extensibility Framework is carried forward. Logic that reaches around it — modified core, volatile views, undocumented APIs — touches surfaces IFS is free to change each release, so it breaks by design.
Does Clean Core mean I cannot customise IFS Cloud?
No. Clean Core means you customise inside the supported framework — Custom Events, Custom Fields, projections, configuration — rather than modifying the core. You keep the automation and integration you need; you just build it on interfaces IFS commits to versioning, so upgrades become re-validation rather than rebuilds.
How do I find out which of my extensions will break?
Inventory every extension and classify each as Safe, Refactor, Rewrite or Retire based on whether it lives inside the framework. The Update-Safe Audit does this in 10 business days and returns a fixed-price remediation roadmap, with the fee credited in full against any fix work within 90 days.
7.About the author
Dariusz Myśliwiec — 25+ years in ERP and supply chain, 17+ on IFS (Apps 7.5–10 and IFS Cloud). IFS Certified Associate Consultant. PRINCE2® 7. Based in Kraków, delivering remotely across Europe and globally through an independent practice — you talk to the consultant who does the work, not a sales layer.
Selected clients: Fugro · LGC · BVI Medical · Betafence (PRÆSIDIAD) · Barlinek · NGK Ceramics · Newag · Oleofarm.
IFS is a registered trademark of IFS AB; this practice is not affiliated with IFS AB.
Stop paying the upgrade tax
Your next IFS Cloud release is already on the calendar. In 10 business days, the Update-Safe Audit tells you exactly which extensions will survive it and which will cost you — with a fixed-price roadmap and the fee credited against the fix.
