IFS development and optimisation: from custom code back to the standard

IFS development and optimisation keeps your IFS environment as close to the standard as possible after go-live. With each release you switch on the features that help and replace custom code where configuration can do the job. Eqeep assesses which features and changes matter for your business. Each change starts with a design, so you see what it involves before anything is built.

Why should your IFS environment keep improving?

Processes change, and software that does not move with them becomes a brake. IFS ships two IFS Cloud release updates a year, plus monthly service updates. With the right choices, new functionality becomes an improvement instead of a maintenance task. That is the work of IFS development and optimisation: functional and technical improvements to your IFS environment, in line with the IFS release cycles.

How do you decide which IFS release features to use?

You compare each new feature with how your business works and switch on only what helps. Eqeep analyses which features in each release are worth turning on; you decide what creates value and what can wait. The IFS Cloud features hiding in plain sight shows how to review a release update for usable features.

How does the cycle from release to improvement work?

The cycle runs from release information and assessment through design to building, testing and deployment. Then the cycle starts again.

See what the release brings. We list what is new for the IFS solution you use.

Assess which features are worth turning on. We assess the new features against your processes and your set-up. People decide: which new features to turn on.

Design every change first. A small tweak gets a design too, just like a completely new module. We describe the change, estimate the costs and assess the expected effects before anything is built. People decide: whether a change is worth its cost.

Build, test, deploy and document. We build the change, test it and deploy it. We write a cut-over document for the transition and update the CRIM documentation after every change.

How do you add new functionality to your IFS set-up?

You design the process together and check it against the IFS Cloud standard. Then you build it in, structured and integrated with the rest of your IFS solution. An example is adding a service component to your existing IFS set-up.

What is the difference between configuration and customisation in IFS Cloud?

Configuration uses the designers and tools that come with IFS. Customisation changes the code itself. The IFS documentation on tailoring, its term for adapting IFS Cloud, names three types:

• Configuration. Consultants and key users extend the data model, change screens and automate processes with designers.
• Extend on the outside. Integrations and apps use the open IFS Cloud APIs, for example through PowerApps or Mendix.
• Extend on the inside. Custom code in its own layer, next to the standard code. An override adds code before or after the standard code, which still runs. An overtake replaces the standard code with your own copy.

Why does custom code cost time at every release update?

Because configuration and custom code must be reassessed at each release. IFS describes three tailoring levels: Core, Configured and Customized. According to IFS, the higher the level, the more manual work a new release takes.

At Core, with only personal settings and navigation, the update runs automatically. At Configured, with configurations and integrations, every release needs an impact analysis, sometimes an adjustment, and testing. At Customized, small code changes carry forward fairly easily; larger overrides and overtakes need adjusting more often.

IFS calls the overtake a last resort, because you maintain that copy yourself through every release and even service updates. Configuration can age too. IFS is working on phasing out Execute Online SQL event actions and recommends workflows or Query Designer instead.

Can you reduce custom code when you move to IFS Cloud?

Yes, as far as standard configuration can replace the code; that depends on what it does, your set-up and the data available. If you come from an older IFS version, you may carry custom code that is expensive to maintain. Moving to IFS Cloud is a good moment to change that.

Eqeep analyses your customisations and advises listing each one with its type. Start with what costs the most work at every release:

• First the overtakes, the copies of standard code you maintain yourself through every release and service update.
• Then the Execute Online SQL event actions, which IFS is phasing out.
• Then extra fields in custom code that are only stored and shown. A custom attribute can carry them, as long as no custom logic uses them.

For each item, your application manager and the process owner decide: keep it, rebuild it in configuration or drop it. The aim is an environment that is easier to maintain and update.

How do you assess a change request against the standard?

Run every request through four questions, lightest first, and stop at the first that works.

• Can the standard do it, now or in a coming release? Then set it up or adjust the process.
• Can configuration do it, without changing the code?
• Can it run outside IFS, through the APIs? Then the IFS code stays untouched.
• Is custom code really needed? Choose an override, and an overtake only when no other option exists.

IFS’s own example is a new field that only has to be stored and shown on existing pages or reports. That request stops at question 2, because IFS then recommends a custom attribute with Page Designer or Report Designer. If custom code uses the field in its business logic, IFS says the attribute belongs in that customisation.

Count the cost of two release updates a year in each answer: impact analysis, adjustment and testing. You decide which route a request takes, or whether it is dropped.

According to the customer story, Optronica’s requirements were met through standard configuration of IFS Field Service Management, without customisation. Read the Optronica story.

Not every customisation can go back to the standard, and IFS advises against forcing a requirement into a type that does not fit. Sometimes an override is the right choice, if you know its cost per release.

How do you use AI in IFS for real results?

AI is built into IFS Cloud, but its value does not show up by itself. Eqeep helps you choose the IFS Industrial AI applications that fit your processes, such as automating scheduling or predicting maintenance needs.

What do you get from development and optimisation?

• Roadmap

  An up-to-date roadmap with the optimisations that are planned.

• Solution Design

  A Solution Design for every change, made before anything is built.

• Cut-over document

  A cut-over document to support the transition to the changed set-up.

• CRIM documentation

  Updated after every change.

How does development fit with maintenance and training?

Development and optimisation works alongside Maintenance and support and Training and education. Together they form a loop: improve the application, keep it stable, train the users. Then go again.

Who helps you with IFS development and optimisation?

An IFS Specialized Partner like Eqeep advises on, implements and supports IFS Cloud. Eqeep does this for enterprise resource planning (ERP), enterprise asset management (EAM) and field service management (FSM). We work for manufacturers, energy and utility companies and service organisations in the Benelux, from the first analysis to support after go-live.

Questions about IFS development and optimisation

How do you turn IFS updates into improvements?

You assess which new features in each release help your business and switch on only those. Eqeep analyses the release and helps you choose what creates value and what can wait. Every change starts with a design: we describe the change, estimate the costs and assess the expected effects.

What does IFS development and optimisation cover?

It covers functional and technical improvements to your IFS environment. Think of new modules, the rollout of AI features, less customisation and continuous delivery of improvements in line with the IFS release cycles. Every change starts with a design, and the work runs alongside Maintenance and support and Training and education.

Can Eqeep help reduce legacy customisations?

Yes. Eqeep advises starting with the overtakes, then the Execute Online SQL event actions, then extra fields that are only stored and shown. For each item, your application manager and process owner decide whether it stays, returns as configuration or goes.

Is custom code covered by IFS support?

Not by default. Under the IFS support policy (version 2026-02, February 2026), IFS supports only unmodified code of a current release. Customisations need a separate support agreement with IFS. IFS closes a case that turns out to sit in your configuration as a false alarm.

This article describes one of the five phases in our approach. Tell us where you stand with IFS. You get one conversation and a clear next step. Discuss your IFS question.

New articles appear in our newsletter. Subscribe to the newsletter.