An IFS upgrade rarely stalls because the technology failed. It stalls because a handful of decisions got deferred until they became blockers — and by then the momentum, and often the budget, had drained away. After years of walking into these projects, the pattern is remarkably consistent.
1. Nobody owns the scope question
The single biggest cause of drift is an unanswered question: is this a technical upgrade or a reimplementation? Teams try to have it both ways — 'just move us across, but also fix everything while you're there' — and the scope quietly balloons. Decide this deliberately, in writing, before anyone touches a test environment.
2. The customisations are a mystery
Every long-lived IFS install accumulates modifications, extensions and integrations. On older versions, half of them are undocumented and a third are no longer used. Upgrades stall when the team discovers this mid-flight. The fix is unglamorous but decisive: inventory every customisation early, and for each one make an explicit keep / re-platform / retire call.
3. Data is treated as a late-stage task
Migration and cleansing get scheduled near the end, then explode. Bad master data doesn't just slow the cutover — it undermines trust in the new system on day one. Start data profiling at the beginning. It's the least exciting workstream and the one most likely to save the project.
An upgrade is the best chance you'll get to undo years of accumulated compromise. Treated as a chore, it just carries the mess forward.
4. Testing has no owner on the business side
When testing is seen as 'the consultants' job', defects surface late and acceptance drags. The business has to own test scenarios that reflect real operational edge cases — the awkward orders, the month-end, the returns nobody likes. That ownership is what turns a nervous go-live into a confident one.
Keeping it moving
None of these are technical problems. They're decisions and ownership gaps, which means they're fixable with the right structure early on: a clear scope call, a customisation inventory, data work from day one, and business-owned testing. Get those four in place and the technical upgrade tends to look after itself.
If your upgrade has already stalled, that's usually recoverable too — it starts with an honest assessment of where the real blockers sit, rather than pushing harder on the plan that isn't working.
Written from hands-on IFS Cloud delivery experience. Every engagement is confidential — this article contains no client names or project specifics.