Every spring, the same line appears in their plan: “IFS upgrade: allow one quarter.” Nobody questions it anymore. It is treated like weather. Three months of a developer re-applying the same modifications, a nervous fortnight of clicking through screens to check nothing broke, and a go-live-sized knot in everyone’s stomach, twice a year, forever.
Two floors down, a competitor on the exact same product takes the same release over a weekend and barely mentions it on Monday. Same platform. Same cadence. Wildly different lives. The difference was decided years ago, by how each of them built.
The cadence that keeps IFS Cloud modern is the same cadence that bills you for every shortcut you took at build.
IFS ships a Release Update twice a year (24R2, 25R1, 26R1), each with new features and cumulative fixes. Between them come monthly Service Updates: high-severity fixes only, no new functionality, nothing that breaks your data model unless a critical bug forces it. And because each release keeps getting those service updates longer than the gap to the next one, you get a real say in when you move. That is the “Evergreen” promise. The promise is genuine. Whether you get to enjoy it is up to you.
The line that decides everythingTwo ways to change the same system
IFS draws a hard line down the middle of every customisation, and your future sits on one side of it or the other.
Above the line
The Extensibility Framework (custom fields, custom logic, custom events) plus configuration through Page Designer. It layers on top of the core, so when a release lands it simply comes along. No drama, no re-work.
Into the core
Modifications that reach into IFS’s own behaviour. They work. They demo beautifully. And every single release, someone has to re-apply and re-test them against a core that moved underneath, a bill that only arrives at the first upgrade.
The rule is unglamorous: exhaust configuration and framework extension before you cut into the core. Every core change is a standing subscription, re-tested twice a year for the life of the system. Sometimes that price is worth paying. It is never free, and it should never be paid by accident at whichever desk the ticket landed on.
Know the differenceA release and a service update are not the same animal
Half the panic around upgrades comes from treating every update as if it were the big one. It is worth keeping the two straight.
| Release Update (RU) | Service Update (SU) | |
|---|---|---|
| How often | Twice a year (24R2, 25R1, 26R1) | Monthly, cumulative |
| What’s inside | New functionality and cumulative fixes | High-severity fixes only |
| Can it move the ground? | Yes; APIs and data models can change | No, unless a critical bug forces it |
| Your part | Choose when to adopt, inside the Evergreen window | Take them; they are the safety net in between |
If you cannot list your changes, you cannot upgrade cheaply
Ask a team in trouble what they have changed from standard, and you get a pause. Someone starts a sentence about a thing finance asked for years ago. Someone else is not sure if that nightly job is theirs or shipped. That pause is the whole cost of the upgrade, in advance.
An upgrade costs exactly what it costs to know what might break. The silence when you ask is the invoice.
Keep a living register instead: every extension, event, custom field, integration and core change, each with an owner and a reason. It is not
