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 documentation theatre. It is the one artefact that turns “how long will the upgrade take?” from a shrug into a number. And it is what lets you prove the business still works afterwards without a fortnight of manual clicking: capture the handful of flows that would stop you invoicing or shipping (order-to-cash, procure-to-pay, plan-to-produce, the close) as a repeatable check you run before and after. What was a nervous two weeks becomes a pass or a fail you can trust in a day.
The compounding kindThe costliest upgrade is the one you keep postponing
Evergreen gives you flexibility, and flexibility has a sharp edge. Skip one release and you are fine. Skip three because “we’re stable” and you have dug a chasm: more change to absorb at once, service updates running dry on your ageing release, and an upgrade that is now genuinely a project, because you turned three small steps into one cliff. Stable was never stable. It was deferred, and deferral compounds.
Pick a cadence and hold it. Teams often settle on one release a year, comfortably inside the window, taking the service updates in between. And whatever you adopt, rehearse it on a copy that looks like production first, not on a clean demo where your extensions never meet real volume. The custom event that is fine on ten rows and dies on ten million always shows itself in the dress rehearsal, never politely in the demo.
IFS keeps the product evergreen. Your solution is your garden.
The platform hands you a predictable path to stay current without a re-implementation. Whether that path is a weekend or a quarter is not set by IFS. It is set by how you extended, whether you wrote it down, and whether you can prove the business still runs. Those are choices made long before the release ever landed.
Next spring
Imagine the same team, a year on, deleting that line from the plan. Not because the upgrade got easier, but because they moved their changes above the line, wrote down what they own, and built a check they can run in a day. The release still lands twice a year. It has just stopped being weather they brace for and become a Tuesday.
That is the whole promise of Evergreen, and it was never really about the product. It was about the discipline underneath it.
Turn the upgrade back into a Tuesday
We build IFS Cloud extensions the release cannot break, and turn the twice-yearly upgrade dread into a scheduled non-event. If your last update ate a quarter, let’s make the next one boring.
Make the upgrade boring