CIO Playbook: Transition from Oracle On-Premise Applications to Oracle Fusion Cloud

Why Oracle Is Pushing CIOs Off On-Premise

Oracle's strategic priority is clear: move its installed base from on-premise perpetual licences to recurring Fusion Cloud subscriptions. This is not a benign technology upgrade — it is a commercial transformation driven by Oracle's desire to convert one-time licence revenue into predictable, annually escalating subscription fees. The financial logic is compelling for Oracle. Once you are on a SaaS subscription, Oracle captures an annual fee that increases by 8% per year, has very limited contractual flexibility, and makes switching to an alternative significantly more difficult.

For CIOs, this creates a strategic inflection point. Oracle's on-premise product roadmap is effectively frozen. New capabilities — artificial intelligence, embedded analytics, regulatory compliance automation — are being delivered exclusively to Oracle Fusion Cloud customers. Oracle Agile PLM, for example, reaches end of life in 2027. Oracle Content Management Cloud Services was decommissioned at end of 2025. While Oracle has extended Premier Support for some on-premise products until at least 2035, the investment gap between on-premise and cloud will continue to widen.

The migration is genuinely complex. According to research by Deloitte, 48% of organisations identify data migration as one of the top three challenges in cloud migration projects. A PwC survey found that 67% of organisations faced significant challenges specifically around customisation during EBS to Fusion Cloud transitions. These are not abstract risks — they translate directly into cost overruns, delayed go-lives, and extended periods of dual-environment operation that consume both budget and internal bandwidth.

Understanding Oracle's On-Premise Support Trajectory

Before agreeing to any migration timeline, CIOs must understand what staying on-premise actually costs in the medium term. Oracle charges annual support fees at 22% of your net licence value, and those fees increase by 8% per year. This is not a guideline or typical range — it is Oracle's standard contractual position, and it is applied consistently across its on-premise customer base. An organisation paying $1 million in support fees today will be paying $1.47 million in five years, and over $2 million in ten years, without deploying a single additional user or using any additional functionality.

This trajectory is one of the most powerful commercial levers Oracle holds. For many large enterprises, Oracle support fees represent the single largest item in the software budget. The 8% annual escalator is a material long-term financial liability, and any migration discussion must be framed against this baseline cost. Staying on-premise is not a cost-neutral option — it is an actively escalating cost commitment with no innovation return.

Key End-of-Life Events to Track

The following on-premise Oracle products have significant end-of-life or end-of-Premier-Support milestones that CIOs should track when planning migration windows:

• Oracle Agile PLM: End of life 2027 — Oracle Fusion Cloud PLM is the designated successor
• Oracle E-Business Suite R12.2: Premier Support extended, but no new functional roadmap beyond current release
• Oracle PeopleSoft: Continued support available but investment heavily skewed toward cloud products
• Oracle JD Edwards: Cloud capability limited; Oracle positions OCI-hosted JD Edwards as a bridge path
• Oracle Content Management: Decommissioned December 2025

The practical implication is that even where Oracle provides extended support, the product innovation pipeline for on-premise applications is effectively closed. CIOs choosing to remain on-premise are paying an increasing premium for a static product footprint.

Licensing Strategy During the Transition Period

The Oracle licensing position during migration is more nuanced than Oracle's sales team typically communicates. There are several important protections and constraints that CIOs must understand before signing any migration agreement.

The 100-Day Concurrent Use Window

Oracle generally permits concurrent use of on-premise licences and Oracle Fusion Cloud subscriptions for a period of up to 100 days during an active transition. This window is designed to allow business continuity during cutover — you can run both environments simultaneously while you test, train, and migrate data. However, the 100-day limit is contractual, not flexible by default. If your migration takes longer, you will need Oracle to formally extend this concurrent use right, and that negotiation should happen before you sign the migration agreement, not after you have missed the deadline.

The existence of this 100-day window is also used by Oracle to create artificial time pressure. Oracle's sales representatives will often communicate urgency around the transition timeline, in part because the concurrent use period creates a natural deadline. CIOs should be aware that Oracle's Global Licensing and Advisory Services (GLAS) team — Oracle's internal licensing authority — can advise on what is contractually permitted during transition, but their primary interest is Oracle's commercial position, not yours.

Bring Your Own Licence (BYOL) and Public Cloud Deployments

If you hold a ULA (Unlimited Licence Agreement) or PULA (Perpetual Unlimited Licence Agreement) and are considering deploying Oracle technology on public cloud infrastructure such as AWS, Azure, or Google Cloud under BYOL terms, you must ensure your ULA or PULA explicitly permits this. Standard ULA and PULA language grants unlimited deployment rights on hardware you own or lease — not on shared public cloud infrastructure. Oracle has taken the position that BYOL deployments in public cloud environments are excluded from ULA certification counts, which means cloud workloads will need separate licensing once the ULA ends unless this is specifically addressed in your agreement.

This is a critical point for any organisation considering a hybrid on-premise/cloud strategy during the migration period. The interaction between your existing ULA or PULA, BYOL rights, and the new Fusion Cloud subscription must be explicitly mapped and contractually confirmed before you transition any workloads.

Shelving Rights: Stopping the On-Premise Support Clock

One of the most significant commercial levers available during an Oracle cloud transition is the concept of shelving rights — the contractual right to stop paying Oracle's annual support fees for on-premise licences while you transition to Fusion Cloud. This is not a standard Oracle term; it must be explicitly negotiated, and Oracle's willingness to grant it depends heavily on the commercial context.

A typical Oracle shelving arrangement works as follows: for a defined level of new Oracle Cloud subscription spend, Oracle will permit you to terminate a corresponding amount of on-premise support. The ratio varies — Oracle's standard position is often $3 of new cloud spend for every $1 of support you want to terminate, but in competitive or strategically important deals, Oracle has offered $1-for-$1 or even more generous terms. For large enterprises with $1 million or more in annual Oracle support fees, negotiating shelving rights can save millions of dollars over a three to five year transition period.

There are important structural requirements for shelving arrangements. The terms must be documented in writing, specifying exactly which on-premise licences are being terminated, the amount of support reduction, and the new cloud subscription commitment that triggers the shelving right. Without this contractual specificity, Oracle may later claim that the licences remain active and attempt to recover back support fees. The on-premise licences being shelved must also be formally retired — Oracle will not permit you to maintain active rights to on-premise licences you are no longer paying support on, so you must be genuinely committed to decommissioning the on-premise environment.

Oracle's Fiscal Year and the Q4 Negotiation Window

Oracle's fiscal year ends on 31 May. The Q4 window — March through May — is when Oracle's sales organisation is under maximum pressure to close deals, and when discount authority is typically extended most broadly. CIOs planning Oracle cloud migrations should time commercial negotiations to close in this window wherever possible. In Q4, Oracle will accept terms and pricing that are significantly more favourable than what would be available in Q1 or Q2. Organisations that have already signed migrations outside Q4 frequently report that they left material value on the table by not timing the commercial discussion correctly.

Negotiating Your Oracle Fusion Cloud Contract

Oracle Fusion Cloud list prices are high — Oracle's published prices for core HCM start at approximately $15 per employee per month (with a minimum of 1,000 employees), and ERP financial modules carry list prices of $100 or more per user per month. In practice, these list prices are heavily discounted. Large enterprises in 2025 and 2026 are routinely securing 30–50% off Oracle's list prices, with strategically important deals or competitive situations sometimes yielding discounts of 60% or more. Smaller organisations or standalone add-on purchases typically see discounts of 10–25%.

The following terms are among the most important to negotiate in any Oracle Fusion Cloud agreement:

• Annual price increase cap: Oracle's standard contract allows annual price increases. You must negotiate a hard cap — ideally zero for the first three to five years, and no more than 3–4% thereafter. Without this protection, Oracle can increase your subscription costs annually at its discretion.
• Minimum commitment vs actual use: Oracle prices subscriptions on committed users or usage tiers. Negotiate the right to scale down commitments at renewal if your actual use is lower than projected.
• Module bundling and scope creep: Oracle often bundles modules you do not need to inflate the subscription value. Negotiate the right to use only the specific modules required, and document precisely which modules are included in the scope.
• Data portability and termination rights: Ensure the contract includes rights to extract your data in a usable format on termination, with Oracle obligated to assist in a transition to an alternative platform.
• Shelving rights: As detailed above, negotiate the explicit right to terminate on-premise support as you progress the cloud migration.
• Implementation and professional services scope: Oracle's implementation cost estimates are consistently low. Negotiate a fixed-price statement of work or a capped time-and-materials arrangement before any professional services begin.

Managing the Technical Migration

The technical dimensions of an Oracle on-premise to Fusion Cloud migration are frequently underestimated. This is not an upgrade — it is a re-implementation on a fundamentally different platform architecture. Oracle E-Business Suite, PeopleSoft, JD Edwards, and Siebel were all built on an on-premise, heavily customisable model. Oracle Fusion Cloud is a multi-tenant SaaS environment where customisation is constrained by Oracle's update cadence. The two systems do not share the same data model, process flows, or integration architecture.

Data Migration Complexity

Data migration is consistently identified as the highest-risk element of Oracle cloud transitions. A Deloitte study found that 48% of organisations consider data migration one of their top three cloud migration challenges. The key issues are: differences in data models between EBS and Fusion Cloud require detailed field-level mapping; data quality issues that were tolerated in on-premise systems become blockers in Fusion Cloud's more structured architecture; and historical transaction data that does not migrate cleanly to Fusion must be archived separately, creating a long-term dependency on the legacy system for audit and reporting purposes.

Best practice is to plan for at least five full ETL (Extract, Transform, Load) cycles before go-live. Each cycle extracts data from the legacy system, transforms it to meet Fusion Cloud requirements, loads it into the cloud environment, and validates the results. This iterative approach identifies errors progressively and significantly reduces the risk of data quality failures at go-live. Critically, ETL cycles should be executed against a clone of the production environment, not live production data, to avoid synchronisation issues during the migration period.

Managing Customisations

Oracle EBS customers routinely have hundreds of customisations — bespoke workflows, modified forms, custom reports, and integrations with third-party systems. PwC research found that 67% of organisations face significant challenges with customisation during cloud migration. The core issue is that Fusion Cloud does not support traditional on-premise customisation approaches. Everything that has been custom-built in your EBS environment must be redesigned as either a standard configuration, a Fusion Cloud extension built using Oracle's approved toolsets (primarily Oracle Application Express and Oracle Integration Cloud), or a process change that eliminates the need for the customisation entirely.

Before beginning any migration project, you must complete a comprehensive customisation inventory. For every customisation, the decision should be: retire it (the underlying business requirement no longer exists), replace it with standard Fusion Cloud functionality, rebuild it using Oracle's approved extension framework, or re-evaluate whether the need is best met by a third-party application that integrates with Fusion Cloud. This analysis is not Oracle's responsibility — it falls entirely to the customer organisation, and underestimating its scope is the most common cause of cloud migration cost overruns.

Integration Architecture

Oracle Fusion Cloud operates on a REST API-first integration model. Legacy EBS integrations typically use Oracle's proprietary Open Interfaces and Business Events framework, which does not translate directly to Fusion Cloud. Every integration with a third-party system — financial systems, HR platforms, logistics providers, CRM, manufacturing execution systems — must be re-architected for the Fusion environment. Oracle Integration Cloud (OIC) is Oracle's preferred integration platform, but it is an additional subscription cost and its capabilities should be evaluated against alternative integration platforms before committing.

Building Your Migration Governance Model

Successful Oracle cloud migrations share a consistent governance structure. The following elements are present in organisations that complete migrations on time and within budget:

• Executive sponsor with cross-functional authority: Oracle migrations affect finance, HR, operations, IT, and procurement simultaneously. The executive sponsor must have the authority to resolve cross-functional conflicts and hold the programme accountable to business outcomes, not just technical milestones.
• Independent commercial advisor: Oracle's implementation partners are commercially aligned with Oracle and have an incentive to complete the implementation on Oracle's preferred timeline and scope. An independent advisor — with no Oracle implementation revenue — is essential for protecting your commercial position throughout the transition.
• Dedicated programme management office: Oracle migrations require sustained, dedicated programme management for two to four years. Resource this function adequately from the outset; under-resourcing the PMO is the most common driver of timeline slippage.
• Contractual milestone gates: Link phased payments to the implementation partner to independently verified technical milestones. Do not pay in advance of demonstrable progress against agreed deliverables.
• Business continuity planning: Maintain operational continuity planning for your on-premise environment throughout the migration. Cutover failures happen, and you must be able to revert to the legacy environment without business disruption if the go-live does not proceed as planned.

Post-Migration Licence Optimisation

Once you are operating on Oracle Fusion Cloud, the licensing work does not end. Oracle Fusion Cloud subscriptions carry their own set of compliance risks and optimisation opportunities. User licence types must be correctly mapped to actual system usage — Oracle has multiple user metrics (Full Use, Restricted Use, Employee Self-Service) with significantly different price points, and many organisations are over-subscribed for the level of access their users actually need.

AI and advanced analytics modules are increasingly being bundled into Fusion Cloud renewal proposals as Oracle positions Oracle AI Cloud Service and Oracle Analytics Cloud as mandatory components of the core ERP stack. These modules carry material incremental costs and should be evaluated critically on their standalone business value before inclusion in any renewal.

Annual renewal negotiations are the ongoing mechanism for managing Fusion Cloud costs. Unlike on-premise perpetual licences, which are a one-time purchase, SaaS subscriptions create a recurring commercial negotiation at every renewal. Organisations that do not invest in commercial preparation for each renewal cycle — benchmark pricing, usage analysis, competitive alternatives, negotiating leverage — will see their Fusion Cloud costs grow systematically year-on-year.

Phased Migration Approach for Large Enterprises

For large enterprises with complex on-premise Oracle estates, a big-bang migration — moving everything to Fusion Cloud simultaneously — carries unacceptable operational risk. A phased approach is strongly recommended, with the following sequencing logic:

Phase 1 — Assess and Prepare (3–6 months): Complete a comprehensive inventory of all on-premise Oracle applications, customisations, integrations, and data structures. Validate your current licence position, including any ULA or PULA agreements. Negotiate the Fusion Cloud contract and shelving rights framework before commencing any technical migration activity.

Phase 2 — Foundation Modules (6–12 months): Migrate core financial management and HR modules first. These modules have the most standardised processes, the least customisation risk, and the highest potential for adopting Fusion Cloud standard functionality without significant custom build. A successful Phase 2 builds organisational confidence and establishes the integration and data management patterns for subsequent phases.

Phase 3 — Operational Modules (12–24 months): Migrate procurement, supply chain, project management, and manufacturing modules. These carry greater customisation complexity and more extensive third-party integration dependencies. Phase 3 typically requires the most intensive business process re-engineering effort.

Phase 4 — Advanced Capabilities and Optimisation (24–36 months): Activate AI and analytics capabilities, complete legacy data archiving, retire the on-premise environment, and trigger shelving rights for remaining on-premise support obligations. Establish steady-state licence management and renewal governance processes.

How Redress Compliance Supports Oracle Cloud Transitions

Redress Compliance provides independent Oracle advisory services to CIOs and procurement leaders navigating on-premise to cloud transitions. Our advisors are former Oracle licensing specialists with more than 20 years of enterprise software licensing experience — we understand Oracle's commercial playbook from the inside.

Our support covers the full transition lifecycle: pre-migration licence assessment and compliance review, Fusion Cloud contract negotiation (including shelving rights and annual price caps), implementation partner selection and governance, and ongoing post-migration licence optimisation. Critically, Redress Compliance has no commercial relationship with Oracle or Oracle implementation partners — our advice is entirely independent and aligned with your commercial interests.

To discuss your Oracle cloud transition strategy, visit our Oracle advisory services page or visit the Oracle Knowledge Hub for additional resources including negotiation guides, audit defence kits, and case studies from organisations that have successfully transitioned to Oracle Fusion Cloud on favourable terms.