IFS Cloud Service Update vs Release Update Explained

A Release Update changes the release number, for example from 24R2 to 25R2, and so changes what the system can do. A Service Update keeps the release number and raises the service update level, for example 24R2 SU13 to 24R2 SU14. Community threads use exactly this naming: releases are written as year plus sequence (23R1, 23R2, 24R1, 25R2), and maintenance builds are called SUs (IFS community thread on releases by month).

The difference matters because the two carry different amounts of change. A Release Update is a new baseline for your configuration, customisations, integrations and reports. A Service Update is meant to stay inside the baseline you have tested, although it can still touch behaviour you rely on, so the release notes of each one are worth reading before it reaches production.

The table compares the two update types. Frequency comes from an IFS employee's answer on the community; the other rows describe how the two are normally handled and should be checked against your own contract and release notes.

For the monthly rhythm, an IFS employee on the community states that service updates are monthly and released on the third Thursday of every month, and that major updates normally come twice a year, in May and November (IFS community thread on IFS Cloud updates). A partner in the same thread gives 25R1 on 29 May 2025 and 25R2 on 27 November 2025 as examples. Dates for later releases are not given there, so take them from the official Product Release Notes.

Yes. A Service Update can be applied inside Release Update Studio while a Release Update is in progress, before the Release Update is completed. In one community thread a user started a 24R2 Release Update on the service update level available at that time, and was told that the newer Service Update could be applied on top of it in Release Update Studio, with the procedure described in the IFS documentation page "Applying Service Updates" (IFS community thread on combining the two). The same thread notes that if the next Service Update is only days away, you can wait and upgrade directly to it.

A second thread shows the business reason: a client asked for a later Service Update because it contained a critical security update, and the question was whether it could be taken before the Release Update was finished and tested together (IFS community thread on a Service Update during a Release Update). The accepted answer points to the same documentation section. The thread does not list the steps, so follow the documentation for your release.

The practical rule for planning: fix the target (release plus service update level) before the test cycle starts, and test that exact combination. Changing the level in the middle of UAT means part of the evidence no longer applies.

IFS does not prescribe one frequency in the sources reviewed for this article, and customers choose differently. Answers from the 2026 service webinar state that upgrading immediately after a release is not required, that a customer can stay on a stable release and still receive service updates, and that each release is supported for approximately two years from general availability (IFS community Q&A from the service webinar). That gives a floor: the Release Update has to happen inside the support window.

Within the window, community practice varies:

• One customer describes upgrading once a year to the previous release (n-1), testing it in UAT before the switch, and installing a Service Update only when it addresses an issue they are actually experiencing (IFS community thread on deliveries and updates).
• A partner in the same thread describes applying only Release Updates, three in two years, and waiting for the next Release Update for a fix that exists only in a Service Update.
• A poster in another thread recalls that IFS recommends a new Release Update every 12 months after go-live, but is unsure of the source. The thread points to a support-portal document, "Release Update Best Practices", which was not available for this article (IFS community thread on release update recommendations). Treat the 12-month figure as unconfirmed and check that document in your portal.

These are individual customers, not IFS policy. A defensible default is to set a fixed rhythm for Release Updates well inside the support window, and to decide the Service Update rule explicitly: either take them on a schedule, or take them when the release notes show a fix or security item that matters to you. A missing rule is the real risk, because then the first incident makes the choice.

The amount of core change in your system sets how expensive each Release Update is. In a community thread about keeping up with releases, a partner consultant states that only modifications, the "M" in CRIM, affect upgrades, that code changes need an impact assessment with IFS Update Analyzer, and that with few modifications a release upgrade in the build place can be done in a day; the customer who started the thread says testing is the most time-consuming part (IFS community thread on keeping up with releases). Both statements are individual experience, not IFS guidance.

The consequence is a design rule: prefer configuration, then framework-supported extensions, and treat a core modification as a cost paid at every Release Update. The reasoning is developed in the clean core, strategic IFS Cloud customization and the ultimate guide to IFS Cloud tailoring. When custom code breaks without an error after an update, debugging silent custom code failure shows how to find it.

Plan the test window backwards from the production date, and scale the scope to the update type. The webinar answers state that a new release can be deployed to test environments and checked against your existing customisations and configuration, so the first need is a test environment that mirrors production configuration. These steps work for both types:

1. Freeze the target. Write down the release and the Service Update level that will go to production, and test that combination.
2. Read the notes and list affected processes. For a Service Update, the processes touched by the fixes. For a Release Update, the changed areas plus every custom object, integration and report you own.
3. Name testers and block their time. Key users need protected days in their calendar, and each business area needs a named approver.
4. Run regression on a recorded script set. Reuse the scripts from the last UAT and add the new cases. A tracker such as the UAT test tracker template for IFS Cloud keeps the evidence in one place, and UAT in IFS Cloud describes the sign-off itself.
5. Decide the go decision and the rollback in advance. Name who signs, which defects block, and what happens if production fails.

Preparation that makes this faster is covered in IFS Cloud upgrade readiness, and for the project side see strategies in ERP upgrade planning and being prepared for an ERP upgrade. For the causes of failed upgrades, read why ERP upgrades fail. If part of your checking runs outside the core, the SCM Automation Pack reads IFS over read-only OData and creates no objects in IFS, so it leaves nothing of its own to rework in the core; the projections it reads belong on your regression list like any other integration.

The same discipline starts in the implementation itself: environments and gates are described in the IFS Cloud ERP implementation guide, and general test practice in IFS Cloud testing.

Everything on cadence and combining comes from IFS community threads, which mix IFS employee answers with statements by customers and partners, so the threads do not replace the Product Release Notes. The IFS documentation page "Applying Service Updates" in the ALE documentation is the reference for the procedure, and its steps are not reproduced here. Release dates after 25R2, the exact content of any single Service Update, and the 12-month recommendation should be checked in your own release notes and support portal.

Dariusz Myśliwiec: 18 years hands-on with 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.

IFS is a registered trademark of IFS AB; this practice is not affiliated with IFS AB.