IFS Cloud Migration Guide: 53% Still On-Premise. What Changes, What Breaks, How OasisPro Helps | OasisPro

OasisPro · IFS Cloud Migration · On-Premise to Cloud · CrystalWorks · PermissionWorks

53% of IFS customers are still on-premise.
The complete IFS Cloud migration guide.

 · 10 min read ·  IFS Cloud Migration Guide 53% Still On-Premise (July 2026)

IFS Cloud migration on-premise to cloud guide OasisPro IFS consultants CrystalWorks PermissionWorks

IFS Cloud migration is the near-term reality for the majority of the IFS installed base. Research published in July 2026 by Original Software shows that 53% of IFS customers are still running on-premise and expect to move to IFS Cloud within the next 24 months. That is a significant migration wave about to hit the IFS ecosystem. And most of the businesses in that 53% are underestimating what the transition actually involves.

Moving from IFS Applications 10 or earlier to IFS Cloud is not an upgrade. It is a platform transition.

The data model shares significant DNA with earlier IFS versions.

But the application layer, the customisation framework, the reporting infrastructure, the security model, and the integration architecture are fundamentally different.

Understanding what changes, what breaks, and what needs to be resolved before go-live is the difference between a successful migration and one that generates months of post-go-live firefighting.

OasisPro has delivered IFS Cloud migrations across dozens of environments. This is the honest guide to what you are actually taking on.

IFS Cloud migration: the platform transition that consistently surprises businesses who thought they were doing an upgrade.

Three things break in almost every IFS Cloud migration: Crystal Reports, permission sets, and custom objects. OasisPro provides senior IFS Cloud consultants with 15 or more years of experience, CrystalWorks to keep Crystal Reports running natively in IFS Cloud with zero rebuilds, and PermissionWorks to automate permission set creation from real user navigation. The three most common migration failure points, addressed by one partner, at the best market rates.

15+ Years IFS Experience CrystalWorks: Zero Report Rebuilds PermissionWorks: Automated Permissions Technical and Functional Consultants Apps 9 and 10 to IFS Cloud Custom Object Review Integration Assessment Best Market Rates
53%
Of IFS customers still on-premise, expecting to move to IFS Cloud within 24 months (July 2026 research)
15+
Years of IFS experience across every OasisPro consultant supporting IFS Cloud migration projects
0
Crystal Reports that need to be rebuilt when CrystalWorks is deployed before the migration
26R1
Current IFS Cloud version and the last with Crystal Reports. The right upgrade target for migrations starting now.

What actually changes in an IFS Cloud migration: the honest assessment

Here is how to think about the migration. Some things are genuinely compatible and migrate cleanly. Others change fundamentally.

Knowing which is which before you start is what determines whether your project timeline is realistic.

Critical change

Reporting: Crystal Reports is removed

Crystal Reports integration is permanently removed from IFS Cloud from 26R2 onwards. Every RPT file used for invoices, delivery notes, work orders, and management reports must be addressed before the migration. Rebuild in IFS Report Studio or deploy CrystalWorks. This is the most commonly underestimated risk in IFS Cloud migrations.

Critical change

Security: completely new permission model

IFS Cloud uses a permission set model that is significantly different from earlier IFS versions. Permission sets built for Apps 10 cannot be migrated directly. They need to be designed from scratch based on the IFS Cloud application structure and what users actually navigate. This is a significant workstream if done manually, or a fast automated process with PermissionWorks.

Important change

Customisations: different framework

Custom entity objects, projections, event actions, and navigators built for Apps 10 or earlier use the IFS Object Framework. IFS Cloud uses a different, more modern customisation framework. Every custom development item needs assessment and, in most cases, rebuilding for the IFS Cloud framework. The scope of this work varies enormously by environment.

Important change

Integrations: REST API replaces SOAP

IFS Cloud exposes REST APIs and uses IFS Connect for integration. Earlier IFS versions used SOAP and different connection architectures. Every third-party integration, middleware connection, and automated data feed needs to be assessed against the IFS Cloud API surface and either updated or rebuilt. This includes any eInvoicing or payments middleware.

Compatible

Data: largely compatible

The IFS data model maintains significant compatibility between Apps 10 and IFS Cloud. Data migration is required but the transformation requirements are generally manageable. Master data, transactional history, and configuration data all migrate through IFS-provided tooling with cleansing and validation work required.

Improvement

User experience: significantly better

IFS Cloud delivers a modern browser-based UI with role-based lobbies, mobile support, and AI-native capabilities including IFS Zero for emissions management. Users transitioning from Apps 10 typically find IFS Cloud more intuitive once past the initial learning curve, which is a genuine migration benefit worth capturing in your change management programme.

The Crystal Reports risk: why it breaks IFS Cloud migrations that seemed on track

Crystal Reports is the single most commonly underestimated risk in IFS Cloud migrations from on-premise environments. Not because it is technically complex. Because it is discovered late.

Most migration projects do not fully audit the Crystal Reports library until well into the project.

By that point, the upgrade timeline is fixed, the go-live date is committed, and the discovery that rebuilding the full reporting library in IFS Report Studio is a multi-month project causes a planning crisis.

Crystal Reports is discovered late in almost every IFS Cloud migration. CrystalWorks is the only solution that eliminates the discovery entirely.

IFS Cloud 26R1 is the last version where Crystal Reports exists. From 26R2, it is permanently and completely removed.

Businesses migrating to IFS Cloud on 26R1 have a window to deploy CrystalWorks and keep their RPT files running natively through subsequent upgrades. Businesses migrating directly to 26R2 or later have no native Crystal Reports capability and face a full rebuild in IFS Report Studio unless CrystalWorks is deployed. The sooner this is addressed in the migration plan, the more options are available.

CrystalWorks eliminates the Crystal Reports risk entirely. Your existing RPT files continue to run natively inside IFS Cloud after the migration. No changes to the reports. No retraining for users.

The IFS Cloud user opens the report, runs it, and receives the same PDF or export they always have.

CrystalWorks is deployed before migration go-live and the Crystal Reports question is resolved before it becomes a crisis.

Permission sets in IFS Cloud: why you cannot just migrate them from Apps 10

IFS Cloud's permission set model is built around the IFS Cloud navigation structure.

Permission sets from earlier IFS versions map to an entirely different application model.

Attempting to translate them produces permission sets that are either over-permissive or under-permissive.

There is no reliable way to know which until users start working in the new system. That is not a testing gap you want to discover after go-live.

Manual permission set creation for a complex IFS Cloud environment is a significant workstream.

It requires knowledge of every navigation in IFS Cloud, understanding of which users need which access, and ongoing maintenance as IFS Cloud adds new areas in each release.

PermissionWorks automates IFS Cloud permission set creation from real user screen navigation. No manual mapping. No IFS Solution Manager required.

PermissionWorks captures what users actually navigate within IFS Cloud and generates permission sets that match real usage patterns rather than theoretical access models. For IFS Cloud migrations, this replaces the most labour-intensive permission workstream with an automated process that runs continuously as the system and the user base evolve. New 26R1 navigations are covered automatically without any manual update required.

The three OasisPro capabilities that address the most common IFS Cloud migration failure points

IFS Cloud migration preparation checklist: what to assess before you commit to a timeline

Critical: resolve before migration starts
!
Crystal Reports audit. Catalogue every RPT file in your IFS environment. Identify which are business-critical, which run daily, and which are rarely used. Decide: CrystalWorks for zero-rebuild continuity, or IFS Report Studio migration for each category. This decision shapes the migration timeline significantly.
!
Custom object and modification inventory. Every custom entity object, projection, event action, and navigator built for your on-premise environment needs assessment against the IFS Cloud framework. The scope of rebuild work determines the technical workstream size and timeline.
Important: assess and plan
Permission set strategy. Decide whether permission sets will be created manually (high effort, specialist knowledge required, error-prone) or automated through PermissionWorks (fast, accurate, continuously maintained). For most migration projects, PermissionWorks is significantly faster and more reliable.
Integration compatibility matrix. Every third-party integration, SOAP-based connection, and middleware integration needs to be assessed against the IFS Cloud REST API and IFS Connect architecture. Build the compatibility matrix before committing to a go-live date.
Data migration scoping. Master data, transactional history, and open items all need scoping. Agree on historical data cut-off dates, what migrates in full and what moves as balance forward, and how data quality issues in the on-premise environment will be resolved before migration runs.
Recommended: plan from the start
IFS Cloud version target. Migrations landing on 26R1 can deploy CrystalWorks and address Crystal Reports before 26R2 removes it. Migrations targeting 26R2 or later need Crystal Reports resolved earlier in the project. Your target version shapes the Crystal Reports workstream sequencing.
UAT test script library. Build test scripts for Finance, SCM, Manufacturing, MRO, and every module your organisation uses heavily before the migration begins. Testing should be planned from the start, not assembled under pressure in the final weeks before go-live.
Change management and training plan. IFS Cloud's UI is significantly different from Apps 10. Users who have worked in the same IFS interface for years need genuine preparation. User adoption is a workstream in its own right, not a post-go-live afterthought.

Why IFS Cloud migrations work better with OasisPro than with large SI partners

Large system integrators bring methodologies, global delivery capacity, and brand assurance.

They also bring overhead: account management layers, junior consultants on the actual delivery, and pricing structures that reflect the cost of that overhead rather than the value of the expertise.

OasisPro is structured differently. Senior IFS Cloud consultants with 15 or more years of IFS experience are the people actually doing the work on your migration. Not managing a team doing it.

Decisions are made by people who have solved the same problems on dozens of previous IFS migrations.

👥

Senior consultants do the work, not manage it

Every technical and functional lead OasisPro puts on a migration project has 15 or more years of IFS experience and works directly on your environment. You are not paying for an engagement manager to coordinate a team of less experienced resources.

🛠️

Products that solve the hardest problems

CrystalWorks and PermissionWorks exist because IFS Cloud migrations have repeatable, predictable hard problems. Every other partner sends Crystal Reports customers to IFS Report Studio. Only OasisPro gives you the option of zero rebuilds through a single SAP-approved solution.

💰

Best market rates for senior IFS expertise

Without the overhead structure of large SI delivery models, OasisPro provides senior IFS Cloud consultants at the best market rates for that level of experience. The same expertise costs significantly less through OasisPro than through major system integrators.

Planning an IFS Cloud migration? Talk to OasisPro before you commit to a timeline.

The decisions made in the first weeks of an IFS Cloud migration determine whether the project succeeds or creates expensive post-go-live problems. OasisPro can assess your on-premise environment and give you an honest picture of what your migration actually involves before you commit to dates and budgets.


Frequently asked questions about IFS Cloud migration

What changes when migrating from IFS on-premise to IFS Cloud?

Moving from IFS on-premise to IFS Cloud is a platform transition. The data model has significant compatibility but the application layer, customisation framework, reporting infrastructure, security model, and integration architecture all change fundamentally. Crystal Reports is removed from IFS Cloud from 26R2. Custom objects need to be rebuilt. Permission sets need to be designed from scratch. Integrations need to be assessed against the IFS Cloud REST API.

Does IFS Cloud remove Crystal Reports?

Yes. Crystal Reports integration is permanently removed from IFS Cloud from 26R2 onwards. IFS Cloud 26R1 is the last version where it exists in any form. CrystalWorks by OasisPro is the only SAP-approved solution that keeps existing RPT files running natively in IFS Cloud with zero report rebuilds and zero changes to the reports themselves.

How long does an IFS Cloud migration take?

Migration timelines vary by environment complexity. Simple environments with limited customisation may complete in six to nine months. Complex environments with large Crystal Reports libraries, many integrations, significant custom development, and broad module coverage can take eighteen months or more. A pre-migration assessment by OasisPro gives a realistic timeline based on your specific environment rather than a generic estimate.

What is the biggest risk in an IFS Cloud migration?

The most commonly underestimated risk is Crystal Reports. Many businesses discover late in the migration project that their reporting library cannot move to IFS Cloud without a full rebuild in IFS Report Studio. That discovery, made when the go-live date is already committed, creates a planning crisis. CrystalWorks eliminates this risk by keeping existing RPT files running natively in IFS Cloud without any changes.

How does OasisPro help with IFS Cloud migration?

OasisPro provides senior IFS Cloud migration consultants with 15 or more years of IFS experience for technical and functional workstreams. OasisPro also provides CrystalWorks to keep Crystal Reports running in IFS Cloud without rebuilds, and PermissionWorks to automate permission set creation for the new IFS Cloud environment. These three capabilities address the most common IFS Cloud migration failure points from one partner at the best market rates.

53% of IFS customers are planning this migration. The ones who plan it honestly succeed. The ones who underestimate it do not.

The migration wave ahead for the IFS ecosystem is significant. Fifty-three percent of the installed base moving to IFS Cloud within 24 months means a large number of migration projects starting in 2026 and 2027.

The projects that go well share a common characteristic: an honest pre-migration assessment.

That assessment identifies Crystal Reports, permission sets, custom objects, and integrations as real workstreams with real effort attached, not assumptions that these will be manageable once the project starts.

Talk to OasisPro before you commit to a migration plan. We will give you the honest picture.