The Ultimate Guide to IFS Cloud Tailoring Levels: Configuration, Customisation, and the Push for a «Clean Core»
If you are transitioning to IFS Cloud from legacy versions like IFS Applications 8, 9, or 10, you already know that the ERP landscape has fundamentally shifted. We are no longer living in the era of «big bang» upgrades. IFS Cloud operates on an Evergreen model, delivering continuous biannual major releases and regular patches.
While this guarantees you always have access to the latest IFS.ai and automation features, it completely changes how we must approach system modifications. In my years of implementing IFS, the most critical conversation I have with CIOs and ERP Project Managers happens during the blueprint phase: How do we tailor the system without creating technical debt that breaks future updates?
Based on official IFS architectural guidelines and real-world implementation data, this article breaks down the three IFS Cloud Tailoring Levels, best practices for configuration vs. customization, and how your choices directly impact your Total Cost of Ownership (TCO).
What is Tailoring in IFS Cloud?
In IFS terminology, tailoring is the comprehensive process of adjusting the standard, out-of-the-box software to meet your specific business requirements. This spans everything from a user dragging and dropping a column on their screen, to a developer writing complex, overriding business logic in PL/SQL.
To manage this safely, IFS Cloud categorizes system modifications into three distinct Tailoring Levels. Understanding these levels is the secret to maintaining a flexible, yet upgrade-safe ERP environment.
Level 1: Core (The «Clean Core» Approach)
The Goal: Stay as close to the standard software as possible.
-
What it is: At the Core level, tailoring is limited to basic personalization. This means individual user preferences like saved searches, bookmarks, and rearranging UI elements.
-
Who does it: End Users and Integration Developers (using standard APIs).
-
The Upgrade Experience: Fully automated via the IFS Lifecycle Experience.
-
Expert Insight: Implementing a «Clean Core» strategy is currently the gold standard in ERP rollouts. By shedding legacy «dead wood» (modifications built 10 years ago that are now standard features in IFS Cloud), you minimize setup costs and significantly accelerate your time to ROI.
Level 2: Configured (Extending on the Outside)
The Goal: Adapt the system to unique workflows without touching the underlying source code.
-
What it is: This level utilizes all of the robust configuration capabilities within IFS Solution Manager. It involves configuring processes, UI layouts, and automated rules. It also heavily features «Extending on the Outside» — using Premium APIs to connect IFS Cloud with third-party applications (like Power Automate, specialized WMS, or MES systems) without embedding that logic inside IFS.
-
Who does it: Power Users, Application Consultants, and Integration Developers.
-
Tools Used: Lobby Designer, Page Designer, Navigator, and Workflow designers.
-
The Upgrade Experience: Assisted automation. There is a slight risk that highly complex configurations may be impacted by a release update, requiring minor testing and tweaks.
Level 3: Customized (Extending on the Inside)
The Goal: Building entirely new functional capabilities or overriding standard IFS business logic.
-
What it is: This is the most intrusive level. It allows you to make additions or structural changes using the full developer toolset. Customizations utilize the Layered Application Architecture (LAA), meaning you are altering or adding to the system’s «inside» layer.
-
Who does it: Application Developers (Full-code or using IFS DSL).
-
Tools Used: IFS Developer Studio.
-
The Upgrade Experience: Manual, labor-intensive, and higher risk. Customizations require code merging, retrofitting, and extensive testing during every Evergreen update.
-
Expert Insight: While IFS Cloud provides incredible extensibility, over-customization is the number one reason implementation timelines blow out. A customization should only be approved after a strict «Business Value Audit» proves that standard functionality absolutely cannot meet a mission-critical requirement.
3 Golden Rules for IFS Cloud Configuration vs. Customization
When teams blur the lines between Configuration (Level 2) and Customization (Level 3), deployments fail and upgrades become nightmares. If you want a stable IFS architecture, strictly enforce these three rules:
1. Never make a Customization dependent on a Configuration
This is a fatal architectural flaw that breaks the principles of the Layered Application Architecture (LAA). For example, if you add a custom attribute using a front-end configuration tool, do not write backend customization code that depends on it. This will cause deployment and installation failures. Instead, add that custom attribute as part of the customization itself.
2. Stop writing complex SQL inside Configuration tools
It is tempting for application consultants to write massive blocks of complex SQL or PL/SQL inside configuration text fields. Don’t do it.
If your tailoring requires complex data queries, implement the «code» parts as a Level 3 Customization (e.g., encapsulating the complex SQL behind a view). Then, use a Level 2 Configuration (like a Lobby data source) built on top of that customization. This protects your investment from future deprecations and gives developers a proper environment (with static code analysis and unit testing) to manage the logic.
3. Treat Configurations as Code (Use the Repository)
Configurations should never be treated as temporary front-end tweaks. Regardless of where they are created, configurations must be exported and stored in the customer solution repository. Moving configurations between environments should be done via deliveries, not manual exports/imports. This ensures IFS Lifecycle Experience can run accurate impact analyses during updates and allows for robust automated testing.
The Financial Reality: How Tailoring Impacts ROI and TCO
Beyond technical architecture, tailoring levels directly dictate your bottom line. Industry data and implementation benchmarks reveal the following financial realities of IFS Cloud tailoring:
-
Initial Implementation Costs: Standard IFS Cloud implementations for mid-to-large enterprises typically range from $100,000 to $500,000+. However, businesses that lean heavily into Level 3 Customizations routinely see their implementation timelines extend by months, rapidly inflating consultant fees and delaying operational ROI.
-
The «Resource Crunch»: With legacy versions (Apps 8, 9, 10) nearing end-of-support, the market for senior IFS developers is tightening. Relying on complex Customizations means you will be forced to pay premium rates for specialized developers during every single biannual Evergreen update.
-
The Hybrid Approach: The most financially efficient organizations use a «Standard-First» approach. They utilize Level 1 (Core) for 80% of their processes, Level 2 (Configured via Low-Code platforms or API integrations) for 15% of their unique workflows, and reserve Level 3 (Customized) strictly for the 5% of operations that generate their unique competitive advantage.
Final Thoughts for IT Leaders
Transitioning to IFS Cloud is not just an IT upgrade; it is a shift to continuous delivery. Your goal should no longer be to bend the software to match your legacy processes. Instead, use the move to IFS Cloud as a catalyst to cleanse your data, adopt industry best practices, and return to a Clean Core.
By strategically leveraging the three tailoring levels and ruthlessly protecting your system from unnecessary Level 3 Customizations — you will ensure your ERP remains agile, cost-effective, and truly Evergreen.