Also, lessons about the build-place/use-place practices are interesting. They are of course an integral part of keeping up with the release+update flow.

Good background stuff f.ex. here at “Community > Knowledge base > IFS Product Release Notes > IFS Cloud Overview and Demos” by Bob Corrigan. The videos here seem to point to an external location ad need a separate external logon. There was another place here on Community by some other person where the videos were shown inside the Community (preferred, or maybe they were in YouTube because they were full of ads which was super annoying) but it is a struggle to find the links again.

@JukkaJ ,

I’ve been working as an independent IFS techno-functional consultant for an IFS Customer that implemented IFS Cloud 22R1 in autumn of 2022. Since then I have done

• upgrade from 22R1 SU6 to 23R1 SU2
• service update from 23R1 SU2 to 23R1 SU4

If the environment doesn’t have many modifications, then upgrading to a newer release in the buildplace can be done in 1 day. Of course, the person doing that should have a good understanding of Azure Devops / GIT / IFS Buildplace. The documentation that IFS provides on this is also very good.

Then, for moving the new release from buildplace to useplaces (CFG → UAT → TST → PROD) depends on business keyusers on how detailed the testing will be done + numbers of processes tested.

I would say buildplace administration + release upgrade + tech consulting (fields/events/page configs) could be done by 1 person in the IT dept with a bit of knowledge on DevOps + GIT alongside with reading the IFS Documentation.

I continue to be amazed on how smooth the upgrade process works from one version to the other and how well everything is orchestrated between Azure DevOps / GIT / IFS BuildPlace / ServiceNow.

thanks @Marcel.Ausan 

The crim’s can indeed have a big role in the game. Our count is around 200. They are still in the custom layer so it would also be interesting to understand deeper what kind of effects the higher crim count can have to the upgrade process in regards of work. From what I have understood about the number of changes compared to previous releases, the amount is on the other hand rising ever faster, but still usually most if not all changes are in whole different modules than what we are using. This should help the upgrade is “nothing changes”. What kind of impact analysis tools there are?

@JukkaJ 

Only the ‘M’ part of the CRIMs play a role in the upgrade → modifications. When you have modifications (i.e. code changes done in PL/SQL packages for example) you would need to do an impact assessment using  IFS Update Analyzer and if needed refactor the modifications.

IFS Update Analyzer will show exactly which files where your have some mods need to be analyzed due to code changes in the standard codebase.

Step by step instructions on the technicalities behind an IFS Cloud release upgrade can be found at below URL: https://docs.ifs.com/techdocs/23r1/020_lifecycle/090_release_update_studio/

In parallel with the technical upgrade, it’s a good idea for the business key users to read ‘What’s new in XX’ presentations created by @Bob Corrigan. Maybe there are new functionality that could help streamline the business processes.

https://community.ifs.com/ifs-cloud-23r1-updates-417

The infographic from the above “Release Update Studio” link sure is a good start for conversations about who should do what and how much work and time is needed for each step

https://docs.ifs.com/techdocs/23r1/020_lifecycle/images/RUprocess.png

How are you all using partners/IFS services with these steps?

Currently I see that going through the new release notes and deciding what effects us and whether they could replace some older crims and deciding how they should be configured to be used is an area where improvement is much welcomed. Cloud release update process has this built in. In apps versions this is easily only done in updates at a few years or more interval with a huge cost for a huge project. In Cloud version this work is more continuous but it also requires more continuous input from the customer. And to better understand this input change and how to preapare for it is in the core of this thread

What if you do not do a next release update during the 23 month support window for the one in use now?

It’s been quiet here, maybe everyone is busy planning the updates.

Cloud first appeared in 20xx(?).

2021 had two releases, R2 had at least 17 service updates ad R1 at least 16.

2022 had two releases and R2 at least 6 service updates

2023 has two releases.

Cloud having the 23 month? rolling support means that every supported Cloud customer should now be using at least 2021R2. If you are in this situation, what has it required from you? What if you are still using some older Cloud release, what has prevented the updates earlier and what do you do now?

If IFS R&D provides 24 monthly Service Updates per Relese and 21R1 was released in March-21 and 21R2 in October-21, it means that now there should be no one using 21R1 anymore. Has this succeeded?

Are you as a Cloud user now in at least 21R1? If not where do you think the stuggle is?

From IFS I have understood that the technical update phases go pretty smoothly. That is important but only the climax of the whole Release Update-process (which’s image link above is now broken). All preceding actions are done according to the somewhat customer-specific agreement on contents and roles. This is what I’m interested to hear more about and my main focus on the upcoming regional customer day events in April.

Now when 2024 is coming to an end and IFS Cloud 24R2 is out every Cloud user should be in 22R2 or newer versions. If not, what are your main obstacles and if you are, what has it required to keep up?