Taking an IFS Cloud service update: a practical checklist

← Back to Insights

IFS Cloud is evergreen. There are two releases a year, and service updates in between that bring fixes and small improvements. On paper, a service update is the easy one. In practice, it is where most estates start to drift: an update gets skipped because the timing is bad, then the next one looks bigger, and before long the organisation is several updates behind and nervous about all of them.

The answer isn't heroics. It is a routine that is the same every time, so each update stays small and boring. This is the checklist we work through. Use it as it stands, or as a starting point for your own.

1. Before you start

• Know where you are. Confirm the release and service update each environment is on now. Mismatched environments make every later test result harder to trust.
• Read the release notes properly. Read them against your own estate, not in general. You are looking for changes to the areas you have customised, integrated or reported on.
• Keep your CRIM list current. List every Configuration, Report, Integration and Modification, with an owner. If this list doesn't exist, the update will find your customisations for you, usually in production. (See IFS customisation and CRIMs.)
• Check the support window. Make sure the release you are on is still supported, and know when it stops being supported. That date should drive your plan, not a surprise.
• Book the people. Agree the test window with your key users before you start, not after the delivery lands. Most delayed updates are waiting for testers, not for technical work.
• Freeze changes. Stop non-urgent changes to the customer solution while the update is in progress, so you are testing one thing at a time.

2. Rebuild in Build Place

• Bring the customer solution up to the new service update in the Build Place.
• Resolve conflicts deliberately. Where IFS has changed core code you have modified, decide case by case: keep your change, adopt IFS's, or merge the two. Record why.
• Check for fixes that replace your workarounds. Sometimes IFS fixes the very issue a modification was written to work around. Removing that modification is a win: it is one less thing to carry into every future update.
• Build and create the delivery. Treat a failed build as information, not an obstacle, and fix the cause rather than the symptom.

3. Deploy to test, never straight to production

• Deploy the delivery to a test environment with recent, representative data. Testing against stale data hides problems that only appear with real volumes and real edge cases.
• Smoke test first. Before the full test run, confirm people can log in, key pages open, background jobs run and the main integrations connect. There is no point starting regression testing on a broken environment.

4. Regression test what you own

IFS tests IFS. Your job is to test what makes your estate yours:

• Modifications: every modified process, run end to end, not just the changed screen.
• Configurations: custom fields, page configurations, custom events and workflows.
• Integrations: every inbound and outbound interface, with real messages. Watch for API and projection changes, and for permission sets that need new grants. (See IFS integration.)
• Reports: the layouts people actually print and send, such as invoices, delivery notes, labels and purchase orders. Check the output, not just that the report runs.
• Business processes: your key users run their own scripts for the processes they own. Keep those scripts short and current, so testing takes days, not weeks.
• Sign-off: get it in writing from each process owner before production is booked.

5. Go live

• Agree the window with the business and communicate it, including what users will notice afterwards.
• Know your way back. Before you deploy, know what you would do if production doesn't come back cleanly, and who decides.
• Deploy the same delivery you tested. No last-minute changes slipped in between test and production.
• Check immediately afterwards: logins, background jobs, integrations and one or two key transactions, before users arrive.

6. Afterwards

• Record what was applied and what broke, however small.
• Update the CRIM list and the test scripts with anything you learned, so next time is quicker.
• Put the next update in the diary now. The cadence is what keeps updates small. Once you skip one, the next one is bigger.

Service updates versus releases

Everything above applies to a release upgrade too, with more of it. Releases add functionality, deprecate features and change APIs, so the impact review starts earlier and testing runs longer. Crystal Reports, for example, is being retired from IFS Cloud by release 26R2 (what that means for your reports). If your service updates are routine, release upgrades become a bigger version of something you already do well, rather than a project in their own right.

How V2 helps

We take IFS Cloud service updates and release upgrades routinely for our clients: the impact review, the rebuild in Build Place, technical regression testing of modifications, reports and integrations, and controlled deployment to production. Your key users stay in charge of testing and signing off their own business processes. We're UK-based and work remotely with IFS customers worldwide.

If your estate has fallen a few updates behind, or every update feels like a project, get in touch. We can help you catch up and then keep you current.