IFS Cloud Project Failure: 8 Common Causes and How to Avoid Them

I have been implementing IFS Cloud for a long time. I have delivered projects that went well and I have walked into projects that were already in serious trouble. In nearly every case, the problems were not technical. They were predictable, structural issues set in motion weeks or months before anyone recognised them as risks.

IFS Cloud project failures are more common than most people in this industry are willing to admit. Projects run late, budgets get consumed, and in the worst cases, businesses go live on a system they are not ready to use. The frustrating thing is that the same causes come up again and again. After enough projects, you start to see them before they surface.

What follows are the eight causes I encounter most consistently, what they look like in practice, and what needs to happen differently.

‘IFS Cloud project failure rarely comes down to a single event. It is usually the compounding effect of several avoidable decisions made in the early weeks of a project.’

Thomas Brinsley
Head of Consulting at Change8

Poor or Incomplete Up-Front Scoping

The most reliable predictor of a troubled IFS Cloud project is a scoping phase that did not go deep enough. The reason is almost always the same: the people who actually carry out the work were not in the room.

Leadership can define the destination. But if operational staff are not consulted, the design gets built on assumptions. The person processing purchase orders every day knows more about where the process breaks down than their manager does. That knowledge needs to surface during scoping, not during testing, where fixing it costs more than twice as much.

How to avoid it

• Run discovery sessions with operational staff at every level, not just department heads.
• Have leadership present the future-state vision directly and early so everyone is designing towards the same outcome.
• Treat the scoping document as a living contract. Version it, get it signed off, and revisit it at every major project milestone.

Slow Decision-Making

Implementations run on decisions. Configuration questions, process design choices, exception handling, and integration approaches. Hundreds of decisions need to be made throughout a project, and when they stall, everything downstream stalls with them.

The cause is rarely a lack of commitment. It is usually the absence of a clear decision-making structure. Without a defined escalation path and genuinely empowered project roles, every question gets pushed upwards and waits for a steering committee. I have seen projects lose a month of progress because nobody was certain who was authorised to approve a single configuration decision. That does not show up as one dramatic failure. It accumulates quietly until the programme is in serious trouble.

How to avoid it

• Define in writing, at the outset, who is authorised to make which categories of decision without escalation. Trust the project leads and SMEs working on the project to make the decisions.
• Reserve steering committee time for genuinely business-critical decisions. Operational configuration questions should not need board-level sign-off.
• Keep a decision log. Record what was decided, by who and when. This prevents settled decisions from being reopened and provides a clear accountability trail.

‘The cost of a slightly imperfect decision made on time is almost always lower than the cost of the right decision made two weeks late.’

Thomas Brinsley
Head of Consulting at Change8

Data Migration Problems

Over 80% of ERP data migrations run over time, over budget, or both. That figure has been consistent for years and it continues to catch organisations out. The reason it persists is that data migration is routinely treated as a technical task to manage toward the end of the project rather than as a strategic workstream that should begin at the very start.

Legacy data is almost never clean. Duplicate records, inconsistent formats, obsolete master data, mismatched field structures between the old system and IFS. Each problem is solvable, but they take time, and they compound. Unclean data loaded into IFS on go-live day produces unclean outputs, and nothing erodes user confidence faster or more permanently.

I will say this plainly: if you are planning an IFS Cloud implementation and have not yet started thinking seriously about your data, you are already behind.

How to avoid it

• Begin data profiling and cleansing from the moment the decision to implement is made. Not six weeks before go-live.
• Treat migration as a standalone sub-project with its own lead, timeline, milestone gates and budget.
• Use the right tooling. Change8’s DM Agent is built specifically for IFS data migration and provides structured mapping that generic tools cannot replicate.
• Migrate selectively. Archive your legacy data and bring only active master data and open transactions into IFS.

Over-Customisation

IFS Cloud is highly configurable, and that flexibility is a genuine commercial strength. It is also one of the more consistent contributors to IFS Cloud project failure, because the instinct to replicate every existing process inside the new system leads to an implementation that is expensive to maintain and difficult to upgrade.

Every customisation is a long-term commitment. It needs to be designed, built, tested, documented, supported and revalidated against every future IFS release. Organisations that build heavily customised implementations often find that taking advantage of new IFS Cloud capabilities requires significant rework of the layer they have built on top of the standard product. They have effectively paid to make their own upgrades harder.

The question I always ask when a customisation is requested is whether the process itself is right. More often than I would expect, the answer is no.

How to avoid it

• If IFS Cloud handles it as standard, do it the IFS way unless there is a compelling business case otherwise.
• When standard configuration cannot serve a process, challenge the process before approving the customisation.
• Run regular cross-functional end-to-end sessions. Bringing departments together to walk through connected processes surfaces dependencies and prevents individual teams over-engineering their modules in isolation.

Late Discovery of Interface Requirements

Interfaces are one of the most consistently underestimated workstreams in any IFS Cloud project. A CRM system, a warehouse management system (WMS), a payroll platform, a third-party EDI provider. Each one requires careful design, development effort and dedicated testing time. Discovering a critical interface requirement in month eight of a ten-month project puts the go-live date under serious pressure.

The cost is not just the development work. It is the re-scoping, the delays to parallel workstreams, the compression of testing cycles and the risk that accumulates as everything gets pushed back at once.

How to avoid it

• Produce a complete interface register before design begins. Document every system IFS will need to connect to, the direction and frequency of data flow, and the criticality of each connection.
• Capture current state and future state separately. What does the integration do today and what do you want it to do in IFS? Conflating the two wastes time.
• Make a firm architectural decision on integration approach early. A middleware solution protects IFS as the single source of truth and simplifies long-term maintenance considerably.

Insufficient Training

A system performs perfectly until you introduce it to people. I do not say that to be dismissive of end users. Behavioural change is genuinely difficult and training delivered as a checkbox exercise three weeks before go-live does not produce capable, confident users.

The pattern I see most often is generic delivery where everyone receives the same session regardless of role, poor timing where training happens either too early to retain or too late to practise, and no real investment in super users who can support their colleagues once the project team steps back. The consequence is a go-live where the system works but the users are not comfortable with it yet. That is when workarounds appear and data quality starts to deteriorate.

How to avoid it

• Bring users into the process well before go-live. Regular visibility of the system as it is being built reduces resistance and builds familiarity long before formal training begins.
• Design training to the role. Finance users want to understand why a process works the way it does. Manufacturing and warehouse users want to know exactly what they need to do to be effective on shift. Training both groups the same way serves neither.
• Schedule training around the user’s working pattern. A night-shift operator should not have to attend a morning classroom session.
• Identify super users during UAT and invest in them deliberately. They do not need to be the most senior person in the department. They need to be credible with their peers and ready to support colleagues from day one of go-live.

‘The measure of successful training is not whether users have seen the system. It is whether they can operate independently from the first day it goes live.’

Post-Go-Live Support and Hypercare

Go-live is not the end of the project. In my experience, the highest concentration of problems in any IFS Cloud implementation emerges in the first 90 days after the system goes live. Users are operating under real conditions for the first time, edge cases that testing did not catch begin to appear, and the project team’s capacity is already stretched.

Organisations that treat go-live as the conclusion consistently struggle in the months that follow. The hypercare period needs to be planned with the same rigour as the build. It rarely is.

How to avoid it

• Build a structured 90-day hypercare plan before go-live. Define what support is available, how issues are escalated and prioritised, and what the handoff into business-as-usual looks like.
• Prepare error-handling documentation for the most common failure scenarios. Users need to know what to do when something goes wrong, not just when everything is working.
• Put the project team where the work happens. In a manufacturing business, that means the factory floor. In a logistics operation, it means the warehouse. A helpdesk ticket is a poor substitute for presence during the early weeks after go-live.
• Define a clear BAU handoff with agreed acceptance criteria. The transition from project team to internal support should be a planned milestone, not something assumed to have happened when the team moves on.

Lack of Internal Capacity or Wrong Roles on the Project

IFS Cloud implementations require genuine internal commitment. They cannot be run alongside existing responsibilities without protected time, and they cannot be handed entirely to a systems integrator. Organisations that assign the wrong people, or the right people without protecting their capacity, produce shallow requirements, slow decisions and inadequate testing because the people who should be driving those workstreams are already fully stretched elsewhere.

The most expensive resourcing mistake I see is discovering mid-project that a critical subject matter expert is unavailable because nobody formally secured their time at the outset. By that point, the project is behind, and the options are limited.

How to avoid it

• Define roles, responsibilities and time commitments in writing before the project begins. Every key workstream needs named owners and SME’s and not just a department.
• Secure resource formally and early. A verbal agreement that someone will be involved is not sufficient. Confirm the commitment in writing, including the proportion of their working week the project requires.
• Hold workstream leads accountable. They should be reporting on progress, surfacing risks and escalating blockers, not simply attending status calls.

The Causes of IFS Cloud Project Failure Are Predictable. So Are the Solutions.

None of the causes of failure have described here are inevitable. Every one is preventable with the right preparation, governance and an implementation partner who has enough real delivery experience to call them out before they become critical.

What separates a successful IFS Cloud implementation from a failed one is rarely technical expertise. It is the quality of the decisions made in the first weeks of the project. The depth of the scoping, the clarity of the roles, the rigour of the data strategy, and the commitment of the business to treat implementation as an organisational transformation rather than a software installation.

If you are planning an IFS Cloud project, or you are already in one that is not progressing as it should, we are happy to talk. Change8 brings direct delivery experience, practical tooling and an honest view of where your project stands.

---

Thomas Brinsley is Head of Consulting at Change8. Change8 is an IFS Cloud implementation partner with deep delivery experience across food & beverage manufacturing, logistics and service businesses. Get in touch to discuss your project.