Skip to main content
Question

IFS Cloud 25R2 - Architectural Changes

  • March 19, 2026
  • 2 replies
  • 215 views
BGPTESSSMITH
Sidekick (Customer)
Forum|alt.badge.img+2

Hoping someone could shed some light here.

We are currently upgrading from Apps10 to IFS Cloud 25R1, however, as the project timeline is being extended and taking far longer than it needs to be, it is looking likely that by the time we are live we could be into early 2027, meaning we are probably more likely to want to take a later version such as  26R1 instead. However, we have been informed there is MAJOR architectural differences between 25R1 and 25R2 and this would need to be factored into our current plan and our development of MODs and Configuration items would likely need complete re-work.

Is anyone able to divulge what the major changes are and how this will affect the upgrade process? Surely it makes sense to take a later release wave but in doing so we may need to roll back on work we have already begun…?

 

Thanks!

    2 replies

    spetkus27
    Do Gooder (Customer)
    Forum|alt.badge.img+6
    • spetkus27
    • Do Gooder (Customer)
    • March 19, 2026

    Essentially, IFS is changing its database architecture in a way that seems like it will allow upgrades in place. In other words, now the architecture tends to be xxx_tab → xxxx (view). It will change to add another layer into that current stack (forgive me but I forget the new suffix for the addition) but it will now be  xxx_new _addition → xxx_tab → views. 

     

    We are also upgrading from apps 10 to 25R1 and while its been a little bumpy we will manage to hopefully go live in 3 weeks.

      A
      Do Gooder (Customer)
      Forum|alt.badge.img+6
      • a.hutchings
      • Do Gooder (Customer)
      • March 19, 2026

      As spetkus27 has advised that is the significant change. However how you tackle this is very much a project problem. I would be internally asking a few questions

      • What benefit do we get taking the update during the migration?
        • Do you need a specific feature set? Function etc?
        • Does it affect things you are starting development on / already developed?
        • Will you be too far behind at the current project pace (unsupported)
      • How best to manage the update
        • Usually I would recommend freezing major activities, uplifting the version. Then perform end-to-end testing. Then re-activate development.
        • There are pro’s / con’s in doing it now, right before go-live or after go-live. Risks and costs need to be to be assessed internally.

      So it depends on the business appetite for risk really. Based on your statements though I would stick with what you have and get it live. The project sounds like it is already behind schedule and adding more complexity won’t help. You will have to upgrade post-live anyway as part of the evergreen model and testing that process sooner rather than later is a good exercise.

        Terms & ConditionsCookie settingsAccessibility statement