Independent IFS Cloud practice · Upgrade readiness
IFS Cloud upgrade readiness: a 10-point checklist before your next release
Key takeaways
- An IFS Cloud upgrade readiness checklist turns a twice-yearly scramble into a controlled, predictable event.
- The work is front-loaded: inventory and classify every extension before the release lands, not after it breaks.
- The riskiest points are custom logic outside the framework, reports on volatile views, and integration contracts.
- Readiness is not only technical: a rollback plan, executive sign-off and a realistic timeline are part of it too.
- Work all ten points and the upgrade becomes a re-validation, not a rebuild.
IFS Cloud moves forward on a fixed cadence, and each R1/R2 release can change the ground your customisations stand on. Teams that treat the upgrade as an event to be managed sail through it. Teams that treat it as something that happens to them pay the upgrade tax: broken flows, emergency hotfixes, a go-live that slips a fortnight. The difference is preparation. This checklist is the ten points to clear before you schedule the next release, so nothing on the far side surprises you.
1.Why do you need a readiness checklist?
Because the expensive part of an IFS Cloud upgrade is not the upgrade itself. It is discovering, in the new version, what you should have found beforehand. The IFS Cloud upgrade tax is paid almost entirely in things that were knowable in advance: an extension nobody realised reached into modified core, a report built on a view that changed, an integration wired to an interface IFS never promised to keep.
A checklist converts that risk into a to-do list. Each point below is something you can inspect, decide on and sign off before the release is booked, while you still have time and before the deadline forces rushed decisions.
2.The 10-point IFS Cloud upgrade readiness checklist
- Inventory every extension. Build one list of all customisations, reports, integrations, custom events, workflows and modifications, including the orphans nobody owns. You cannot assess what you cannot see.
- Classify each one by risk. Rate every item Safe, Refactor, Rewrite or Retire, based on whether it lives inside the Extensibility Framework or reaches outside it. This single step tells you where the upgrade tax will land.
- Check your custom events and workflows. Confirm each event still binds to a supported entity and that its logic uses standard interfaces. Events that reach into internal packages are the ones that fail quietly after a release.
- Review Quick Reports on volatile views. Reports built on database views that IFS may restructure are a classic silent break. Flag any Quick Report or SQL report reading from non-guaranteed views and plan to re-point or re-test them.
- Assess RBAC and Segregation of Duties exposure. A new release can add, rename or reshape permission sets and projections. Confirm your role model and SoD rules still hold, so the upgrade does not quietly widen access.
- Verify integration and OData contracts. List every inbound and outbound interface and confirm each uses a supported OData/REST projection, not an internal API. Check field mappings against the target version before, not after.
- Confirm test-environment parity. Your test environment must mirror production: same configuration, same data shape, same integrations connected. A dry run against a stale copy proves nothing.
- Write a rollback plan. Decide, in advance and in writing, how you revert if the upgrade fails validation: backup points, cut-over window and the exact trigger that says “stop and roll back”.
- Get executive sign-off. One named owner accepts the plan, the risk classification and the go/no-go criteria. Readiness without accountability is a wish, not a plan.
- Lock a realistic timeline. Sequence inventory, remediation, dry run, re-test and go-live with slack built in. A timeline that assumes nothing breaks is the one most likely to slip.
Work these ten points in order and the pattern is clear: the first two find the risk, the middle six remove it, the last two make sure someone owns the outcome.
3.Where do teams get caught out?
The same three points catch most teams, every release. Knowing them in advance is half the battle.
| Blind spot | Why it bites | Checklist point |
|---|---|---|
| Reports on volatile views | A restructured view returns wrong data or errors. Nobody notices until a decision already depends on it | Point 4 |
| Silent RBAC drift | New or reshaped permission sets widen access, breaking Segregation of Duties without any error | Point 5 |
| Integration contracts | An interface wired to an internal API stops exchanging messages; the queue backs up unseen | Point 6 |
RBAC drift is the quietest of the three: it throws no error, and access simply widens. If your SoD model matters for audit or compliance, treat the upgrade as a moment to re-prove it. The mechanics are covered in RBAC and Segregation of Duties in IFS Cloud.
4.How do you make readiness permanent?
A checklist you run once is useful. A checklist you never need to run is better. The durable fix is to stop generating upgrade risk in the first place: keep every extension inside the supported framework so there is nothing on the far side of the line to break.
- Build automation with Custom Events and Workflows, never modified core
- Read reports from supported, stable projections rather than volatile views
- Wire integrations to versioned OData/REST, not internal APIs
- Enforce access through RBAC and SoD, reviewed each release
That is the Clean Core discipline. It is the same one behind Clean Core IFS Cloud supply chain automation. Apply it to everything you build and the checklist shrinks to a re-validation, release after release.
5.Frequently asked questions
When should I start the IFS Cloud upgrade readiness checklist?
Before the release is booked, not after. The first two points, inventory and risk classification, take real calendar time, and everything else depends on them. Starting early means remediation and a proper dry run happen without deadline pressure, which is where rushed upgrades go wrong.
Which checklist point catches the most teams out?
Reports on volatile views and silent RBAC drift. Both fail without throwing an obvious error: a report returns wrong data, or access quietly widens and breaks Segregation of Duties. Because there is no error to chase, they are often discovered only after a decision or an audit depends on them.
Do I really need a rollback plan if the upgrade usually works?
Yes. A rollback plan is cheap insurance you write once and hope never to use. It defines your backup points, cut-over window and the exact trigger to stop and revert. Without it, a failed validation turns into an unplanned outage while people improvise under pressure.
Can I run this checklist myself, or do I need help?
You can run it yourself if you have a clear view of every extension and how it is built. If that inventory is fuzzy, or if nobody owns the older customisations, the Update-Safe Audit does points one and two for you in 10 business days, classifying each extension Safe / Refactor / Rewrite / Retire with a fixed-price roadmap.
6.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.
Walk into your next release ready
The first two points of this checklist matter most, and they are the ones teams skip. The Update-Safe Audit does them for you in 10 business days: every extension classified, a fixed-price roadmap, and the fee credited against the fix.