IFS Apps to IFS Cloud Upgrade: What Actually Changes for Your End Users

Most upgrade guides focus on the technology. This one focuses on the people who have to live with it on Monday morning.

The Pressure Is Real — And the Clock Ran Out Faster Than Most Expected

If you're running IFS Applications, you already know the story. Standard support ended in March 2025. Extended support is available, but it comes with a cost that escalates every year and a hard stop that's closer than it feels. The community of Apps customers who delayed is large, and the pool of IFS Cloud-experienced consultants is not keeping pace with demand.

What most organizations don't know is that the urgency isn't just contractual it's competitive. Every month on Apps is a month your competitors on IFS Cloud are absorbing biannual feature releases, tightening their operations, and building institutional knowledge of a platform that's actively improving. You're running a system that had its last planned update in early 2025. They're not.

But here's what I want to talk about that nobody else is writing about. The technical upgrade path is the easy part to plan. What actually determines whether this transformation succeeds or quietly fails is what happens to the people who show up to work the day after go-live. The maintenance supervisor who's been doing work orders the same way for six years. The department head who's been running your most complex process and knows exactly where the bodies are buried.

That is where upgrades succeed or fail. And that's what this article is actually about.

This Is Not an Upgrade. It’s a Decision Point.

We've been involved in IFS implementations and upgrades across defense, energy, manufacturing, and field service. We've seen organizations treat the move to IFS Cloud as a technical project, hand it to IT, let the partner drive, and assume that if the system goes live on schedule the project was a success.

Those projects fail quietly. The system goes live. The users work around it. The Excel files multiply. Three years later someone asks why they're not getting the ROI they projected, and the answer is that they upgraded the software but never changed how the business actually runs.

The organizations that get this right treat the move to IFS Cloud as a transformation event. Not because someone told them they should use that word, but because they made a deliberate decision to use the upgrade as a forcing function to question every process, retire every workaround, and make intentional choices about how they want to operate going forward.

You are not upgrading software. You are deciding what kind of organization you want to run for the next decade.

---

One of the most effective frameworks applied in this context is MoSCoW. This prioritization systematically evaluates every process, customization, and system behavior against four questions. Is this a Must Have, Should Have, Could Have, or Won't Have? It sounds simple. The discipline of actually applying it at scale, with leadership behind it, is not.

What a Successful Upgrade Actually Looks Like

I want to share a story from a client we worked with through exactly this transition.

This organization came into the upgrade with a clear mandate from leadership. They didn't just want to move to IFS Cloud. They wanted to use the event to challenge every process, align the platform to their long-term strategy, and remove the technical debt that had accumulated over years of customizations and modifications. They went in with eyes open.

Leadership Wasn’t Just Supportive — They Were In It

The difference I've seen in projects that succeed versus projects that struggle almost always comes back to one thing. Whether leadership treats it as a business transformation or an IT initiative. This leadership team chose the former, and they were genuinely in it. Not as executive sponsors who show up for kickoff and go-live, but as active participants who guided change through their teams, made hard decisions when they were on the table, and communicated clearly at every stage.

They understood that their people were being asked to change how they worked, not just what tools they used. They understood what that actually costs. The discomfort, the learning curve, the initial drop in efficiency before the gain appears and they prepared their teams for it honestly rather than overselling the experience.

The Recommendation They Didn’t Take

There was a moment in this project I think about often, because it illustrates something important about what good leadership actually looks like in an upgrade.

We were working through a process with a department leader. We walked through the recommendations, laying out the benefits, being clear about the risks on both sides. Our recommendation was directionally clear. This leader listened, asked good questions, pushed back on the assumptions, and ultimately decided to go a different way.

I wasn't surprised. And I want to be direct, that was a good thing.

This leader wasn't being resistant or difficult. They fully understood the risk of staying where they were. They also understood the work their team would have to do to go the other direction. The short-term pain, the process adjustments, the initial friction. They made an informed decision with clear eyes. And then they did something that's rare. They went back to their team, walked them through the challenges they were going to encounter because of that direction, made sure everyone understood their role, and made sure everyone understood that the initial pain would be short-lived.

The team was bought in. They were clear. And when the friction came, because it always does, they moved through it instead of around it.

That department built on that win. When new IFS Cloud features became available in subsequent releases, the business case for adoption was an easy sell internally because the team had already done it once and knew what success looked like on the other side.

The best outcome of a well-run upgrade isn’t just a successful go-live. It’s a team that knows how to change.

---

The overall transformation? Not without bumps no honest account of an ERP upgrade would say otherwise. But it was one of the best-executed I've been part of. I was proud of the team and genuinely respect the leadership for how they showed up for their people through it.

What Actually Changes for Your End Users

Let's get specific. Here's what the people on the floor and in the field actually experience differently when moving from Apps 10 to IFS Cloud. Written from the perspective of what it's like to be that person, not from the perspective of the technical release notes.

The Interface Is Different, Not Just Prettier

IFS Cloud is a genuine departure from what Apps 10 users know. It's browser-based, which means your workforce can access it from a tablet or phone without a dedicated client installation. The navigation logic is different. The terminology in some areas has shifted. Workflows that users completed through muscle memory will require relearning.

For experienced users, this is often the first source of friction not because Aurena is worse, but because competence that was invisible suddenly feels visible again. The fact that they have to think about it again is uncomfortable. Plan for this explicitly. It's temporary, but it's real.

Customizations Your Users Depend On May Be Gone

Apps 10 environments in most organizations have years of accumulated customizations and modifications (CRIMs) many of them built because the standard system didn't quite fit. Some of those will not migrate cleanly to IFS Cloud. Some shouldn't. IFS Cloud's standard functionality has been significantly expanded, and in many cases the workaround your team depends on is being replaced by something better built into the platform.

But your users don't experience it as the platform now does this natively. They experience it as 'the thing I relied on is gone.' The communication and preparation around this specific issue is one of the most underestimated challenges in the upgrade.

⚠ What We See Most Often

The highest-friction moments in Apps 10 to IFS Cloud upgrades are almost never technical. They happen when a user discovers that a familiar workflow has changed and no one prepared them for it. Inventory, work orders, and mobile debrief are where this surfaces most commonly.

Work Orders Are Fundamentally Different and Better

For field service and maintenance operations, work orders in IFS Cloud represent one of the most significant functional improvements over Apps. The native mobile experience in IFS Cloud is purpose-built in a way the older client wasn't. Work order creation, debrief, parts consumption, are more integrated and more intuitive for technicians who didn't grow up in ERP systems.

The challenge is that technicians who've been working with the old interface for years have their own rhythm. The new experience may be better, but 'better' doesn't prevent friction it just makes the friction worth it. Train them in the context of their actual job, not in a classroom with a demo environment.

Reporting and Visibility Are Different for Everyone

One of the most common Apps habits is the shadow report, the Excel file or manual extract that someone built because they didn't get exactly what they needed, when they needed it. IFS Cloud's reporting and analytics capability is substantially improved, but it requires intentional setup.

If you migrate and don't address the shadow reporting infrastructure, your users will keep using it. Which means your single source of truth never becomes one. This is worth auditing before go-live. Who is maintaining an Excel file they use to run their week, and what does it tell you about what the system isn't currently giving them?

The Framework That Separates Transformations from Technical Upgrades

The client described earlier applied a structured process to every customization, every report, every workflow before the upgrade. Not 'what do we want to keep?' but 'what does this actually do for the business, and is there a better way to do it in IFS Cloud?'

MoSCoW prioritization. Must Have, Should Have, Could Have, Won't Have isn't a new concept. But applied rigorously to an IFS upgrade, with leadership actively participating in the triage, it becomes a mechanism for organizational alignment. Every decision becomes explicit. Every tradeoff is named. The team doing the upgrade isn't guessing about priorities, and the business isn't surprised by outcomes.

Must Have Critical to operations. Non-negotiable. If this doesn’t work at go-live, the business cannot function.	Should Have High value, not critical to day one. Can be phased in during early post-go-live sprints.
Could Have Nice to have. Evaluated if time and budget allow not protected.	Won’t Have Explicitly out of scope for this release. Documents the decision so it isn’t relitigated.

 The 'Won't Have' category is the most important. Every organization going into an upgrade has people who believe their process is a Must Have. Getting leadership to explicitly categorize something as Won't Have for this release prevents the scope creep that quietly kills upgrade timelines and budgets.

It also creates something valuable a backlog of enhancements with organizational buy-in. When a new IFS Cloud feature arrives in the next biannual release and it covers something in the Won't Have column, the conversation about adoption is much simpler.

What to Do Before You Start the Technical Work

If you take nothing else from this article, take these. They are sequenced intentionally.

1. Get Leadership to Commit as Participants, Not Sponsors

This is a predictor of upgrade success. Sponsors write checks and show up at go-live. Participants make decisions, communicate with their teams, and hold the business accountable for engagement throughout the project. Be explicit with your leadership team about which role you're asking them to play.

2. Audit Your Shadow Systems

Check every department and ask. What Excel files does your team use to actually run the week? What do those files do that IFS currently doesn't? The answers tell you two things. Where your real requirements are hiding, and where your adoption risks live. Shadow systems don't disappear at go-live. They persist because they fill a need. Either fill the need or have an explicit conversation about why the team will stop needing them.

3. Apply MoSCoW to Your Customizations Before You Evaluate Migration

Don't start with 'how do we migrate this CRIM?' Start with 'does this CRIM still need to exist?' IFS Cloud standard functionality has grown substantially. Many customizations that were built to compensate for Apps limitations. Migrating unnecessary technical debt is how you import the past into your future.

4. Train for the Job, Not for the System

End-user training that covers IFS Cloud features in the abstract is not the same as training that shows your workforce how their process runs in the new system. Build your training scenarios from actual job workflows, with real data, in the actual module configuration your team will use. Generic training produces generic adoption.

5. Name the Short-Term Pain Honestly

The organizations that handle upgrade friction best are the ones who told their teams to expect it. Not as a warning, but as a plan. Here's where it will be hard, here's why, here's how long it will last, here's what we're doing to support you through it. When the friction comes and you already named it, the team moves through it. When it's a surprise, they build workarounds.

The Transformation That Sells Itself

The organization described at the start of this article did something rarely seen. By the time they completed their upgrade, the internal business case for the next round of improvements wrote itself. The team had been through a real change. They'd experienced the friction, moved through it, and come out on the other side with something better. When the next IFS Cloud release brought new capabilities to the table, adoption was easier because the organization had already proven to itself that it could change.

That's the compounding return of a transformation done right. It's not just a successful go-live. It's an organization that now knows how to evolve with the platform instead of fighting it.

If you're sitting on Apps and trying to decide whether to approach this as a technical upgrade or a transformation event, I hope this gives you a clearer picture of what the difference looks like on the other side.

The support clock is already running. The question isn't whether you'll move. It's whether you'll use the moment.

 Want to talk through your upgrade approach before you commit to a plan? Reach out at www.clersolutions.com