IFS Apps 10 to IFS Cloud: The Risks No One Talks About

I have been working on ERP projects for thirty years, first as a customer and then as a supplier. I started in automotive, spent time in Oil and Gas, Medical and FMCG, and most of the last decade has been in Food and Beverage, working with cake manufacturers, cheese businesses, dairy companies. Every industry is different but the reasons that cause projects to fail are, in my experience, broadly the same.

In the last five years I have focused specifically on IFS, managing five IFS Cloud upgrades and five implementations during that time. I have seen projects run smoothly and I have seen projects go badly wrong. The difference is rarely the technology.

“This is a business transformation. Not a technical project.”

John Breedon
Programme Manager at Change8

That is my answer when people ask what organisations most underestimate about moving from Apps 10 to IFS Cloud. The rest of this article tries to explain what that means in practice.

The risks

1. Not enough planning before you start

Planning is the one area where I have never seen a project do too much. The most common mistake before kick-off is a misunderstanding of what the project involves. Teams agree a scope, sign off a contract, and then mid-project things surface that nobody accounted for. Change requests follow, and the project starts to morph.

Pre-project work always pays back. A proper business readiness review, genuine discovery with the people who use the system rather than just their managers, and real board-level commitment secured before anything kicks off. Not commitment in principle, commitment in practice. When the project starts competing with day-to-day operations, you need leadership who will back the project. If that backing is not there from the start, you will feel it.

• You can never do enough planning
• Discovery needs to involve the people affected, not just those managing them
• Board-level support needs to be confirmed, not assumed
• If scope is not properly validated upfront, expect change requests

2. Legacy customisations and the technical debt nobody told you about

Apps 10 environments carry history. The more developed, the more complex the upgrade becomes. The hardest situations are the ones where nobody can tell you why something was built a certain way. The person who built it left years ago. There is no specification.

Sometimes the pragmatic question is simply whether the functionality is still needed at all. Legacy integrations are a related issue. If you are connecting to external systems through older technology, that needs to be looked at early. In some cases, IFS Cloud has standard functionality that can replace the legacy system entirely. That is worth exploring before the project starts rather than halfway through.

• Audit and clean your Apps 10 environment before kick-off
• Identify what customisations exist and whether they are still relevant
• Review external integrations early and plan what needs replacing
• Gaps in data validation before migration will create rework and a poor experience in Cloud

3. Wanting IFS Cloud to behave like Apps 10

I have seen this add significant cost and time to projects. IFS Cloud is a different system. Pushing it to replicate Apps 10 behaviour adds customisation, extends the timeline, and often stops organisations from using standard Cloud functionality that was built precisely to replace the workarounds they had running in the old system. The mindset shift is easy to describe and genuinely difficult for most organisations to make.

You are not upgrading software. You are changing how the business works. That change has to be led from the top. Where I have seen leadership frame this as a technical project, the business does not engage, and the project suffers for it.

• Treat this as a business change programme, not a system upgrade
• Challenge requests to replicate Apps 10 behaviour before agreeing to build anything
• Regular cross-functional end-to-end sessions help surface resistance early
• Check whether standard Cloud functionality already covers what the customisation was doing

4. IT running the project with the business on the outside

When IT own the project and communication with the wider business is weak, the business turns up at go-live unprepared. They have not been part of the decisions. They do not understand why things look different. Getting adoption back on track after that is difficult.

Leadership indecision is a related problem. In my experience, a delayed decision almost always moves the timeline to the right, and deferred decisions accumulate. The principle I try to operate to is that only genuinely business-critical decisions need to be escalated. Everything else should be resolved by the people closest to it.

• This is a business project, not an IT project
• Leadership need to be making decisions, and empowering the team to do the same
• IT and operations misalignment does not resolve itself, it needs to be managed
• Delayed decisions have a cost, even when that cost is not immediately visible

5. Not enough resource on the project, particularly for testing

People are busy with their day jobs. This is the most consistent resourcing problem I see on every project. Testing is where it shows up most because testing is less visible to senior stakeholders. Nobody sees the testing that did not happen. Everyone sees the problems at go-live.The financial logic is simple. If testing is not thorough at each stage of the build, another iteration is needed. That iteration costs money. The projects I have seen go-live most cleanly are the ones where testing was treated as seriously as any other workstream throughout the project, not squeezed at the end.

• Secure resource formally and early, with a confirmed allocation of their working week
• Do not let testing be shortened because it is less visible than other activity
• Happy path testing is not sufficient, real-life scenarios need to be covered
• Issues not found before go-live will be found after, and they are harder and can be more costly to fix

6. Training that does not fit the people receiving it

Finance users and manufacturing users are not the same. Finance typically want to understand the reason behind what they are doing. Manufacturing typically want to know what they need to do to get through their task. Training that ignores this difference works for neither group particularly well.

When you train matters as much as what you cover. Getting someone to attend a session outside their shift creates friction and tends to produce worse retention. Super users should be identified early, and the right criterion is that they understand the system and care about it, not simply that they are the most senior people available.

• Design training for the audience, not a generic version of it
• Bring users along throughout the project, not just at the end
• Identify super users early, seniority is not the right filter
• Train on shift where you can

7. Underestimating go-live and hypercare

Most of the problems I have seen happen at go-live and in the hypercare period that follows. A system that worked in testing behaves differently when real users are running real operations on it. If cut-over has not been properly planned, the team spends hypercare firefighting.

Whether hypercare lasts four weeks or four months comes down to how much testing was done and how well the cut-over was planned. A robust plan, agreed by stakeholders across the business, and daily support sessions that are visible and accessible to the people who need them. In a manufacturing business that means being on the factory floor. In logistics it means being in the warehouse.

• Define the cut-over plan in detail and get it agreed across the business before go-live
• Build a structured 90-day hypercare plan with clear error handling and handoff into BAU
• Make support sessions visible and accessible to the right users
• If testing is being compressed in the final weeks before go-live, that is a warning sign

What separates the projects that go well

When I look back at the upgrades that ran smoothly, the common factors are the level of testing that was done and how involved end users were throughout the project. Not just informed, involved. Everything else tends to follow from those two things.

Getting pre-project structure right is a significant topic in itself, but the starting point is making sure everyone understands the journey before it begins. What the project team will need to do at each stage, what decisions will need to be made and by whom, and what needs to be in place before the next phase can start. Time spent on that at the beginning is rarely wasted.

‘If you are running Apps 10 or an earlier version, you are moving towards end of life. The practical consequences are increased maintenance costs and reduced availability of bug fixes, security patches and legislative updates. The question is not whether to upgrade, but when to start planning for it.’

John Breedon
Programme Manager at Change8

If you are looking at an upgrade in the next 18 to 24 months, the time to start is now. Assess where your system is, understand what the journey will involve, clean your data and configurations, and start conversations with an IFS partner you trust. Organisations that use that lead time tend to have better projects. Those that do not end up compressing the early stages, and that compression shows up later.

The real risk

None of the risks I have described here are unusual. I have seen every one of them on multiple projects. The difference between a project that handles them and one that does not is usually preparation and honesty, about where the business actually is, how much testing has genuinely been done, and whether the decisions that need to be made are being made.

The real risk in moving from Apps 10 to IFS Cloud is not the change itself. It is a lack of testing. And behind that, a lack of honesty at every level of the project about whether the work has been done.

If you are planning an upgrade, or you are in one that is not going the way you expected, I am happy to talk through where things stand.

---

John Breedon is a Senior Project Manager at Change8. Change8 is an IFS Cloud implementation and upgrade partner with delivery experience across manufacturing, food and beverage, logistics and service businesses. Get in touch to discuss your upgrade.