We spoke with Christian Tidemann, Solution Architect at Align, about what upgrading to IFS Cloud really demands — based on personal experience and IFS Cloud upgrade projects at Align.
IFS Cloud is not just a technology upgrade. It demands a new way of thinking — and it is a significant shift for operational teams and consultants alike. Those of us who have spent years delivering tailored solutions now need to think and work differently.
What actually needs to change?
The mindset. For years the default has been: «If it can be solved in IFS, we solve it there — with a customization.» With IFS Cloud, we need to flip that question: should this really be solved inside IFS at all?
Many processes feel unique simply because they have been that way for a long time — shaped by history, habits and old system limitations rather than real competitive advantage. So we should ask early:
Are we really so unique that standard IFS isn’t good enough?
If standard IFS supports a good process, we should consider changing the process rather than the system. That can be difficult. But if we want an evergreen solution, it is often necessary. Customizations are not only expensive to build. They are expensive to keep.
What does complexity actually cost?
The most common reason for customizations is legitimate: standard IFS doesn’t support the process the organisation wants to run. But every customization blocks your ability to adopt new IFS functionality — because new releases may conflict with what you’ve built. In practice, we risk coding ourselves back to a previous IFS version. «Everything was better before» can become a self-fulfilling prophecy.
A more hidden problem is misuse of standard functionality. A spare field gets used for something it was never designed for — because it solved a problem at the time. Later, IFS delivers functionality that depends on that field being used as intended. What was once a quick fix suddenly becomes a blocker.
That is not just technical debt. It is functional debt.
Customizations cost you future opportunities — and a customization is not fully paid for when it goes live.
What about complex configurations — aren’t those safer?
Not necessarily. In older IFS versions, customers couldn’t write customization code themselves — so advanced configuration was the fast, flexible workaround. That was the right choice at the time, and explains why so many complex configurations exist today.
In IFS Cloud, you own the code. That changes everything. Complex configurations — events, custom LUs, migration jobs — are effectively hidden customizations. Fragmented, poorly documented, and often nobody remembers why they were created. They can be even harder to keep evergreen than actual code.
They look like standard — but behave like bespoke development. If a customization is justified, build it properly. Don’t hide it in configuration.
What if standard IFS genuinely doesn’t cover the need?
Then ask whether IFS is even the right place to solve it. Keep IFS as the core — but don’t force it to become everything. Two approaches often work better than customizing inside IFS:
- A dedicated UI on top of IFS – Instead of customising IFS screens for a specific user group, build a simple purpose-built interface using standard IFS projections and APIs. IFS does the heavy lifting in the background — the interface is loosely coupled and unaffected by new releases
- App-to-app integration via standard APIs – Do we already have systems that solve the need better? Let them talk to each other. Map visualisation is a good example — IFS has map functionality, but for organisations where maps are central to daily work, a dedicated mapping tool will often be better. It can pull data directly from IFS via standard APIs, display it on the map, and let users initiate work orders from there — with zero customization inside IFS. Each system does what it does best.
So what’s the bottom line?
Zero customizations is a utopia for most organizations. Some needs are real, and some customizations are justified. But every one you keep must have a clear business case — not only for development, but for the full lifecycle. What does it cost to test, maintain and upgrade? For most organizations that means regression testing once or twice a year. If no one can defend that cost, retire it.
Design the solution for the next release — not only for go-live. That is when you start thinking evergreen.
Christian Tidemann
Solution Architect, Align Consulting AS
Application Management – Independent of Hosting Model
