Transition from Oracle On-Premise
Applications to Oracle Fusion Cloud

Oracle's Journey to Fusion Cloud

Oracle's enterprise application portfolio has evolved from on-premises suites to a unified, cloud-based solution set. Over the past decade, Oracle invested heavily in Oracle Fusion Cloud Applications, a comprehensive SaaS suite covering ERP, HCM, CRM, supply chain management, and more. This transition was driven by customer demand for lower IT overhead, faster innovation cycles, and modern user experiences. The on-premises suites that enterprises have run for decades, E-Business Suite, JD Edwards, and PeopleSoft, remain supported, but they are no longer the strategic direction for Oracle's application investment.

Oracle continues to support its on-premises customers. Premier Support for EBS, JDE, and PeopleSoft has been extended to at least 2035, giving organisations a lengthy runway to plan their cloud strategy. Enterprises are not forced off legacy systems in the short term. Oracle delivers regulatory updates and periodic enhancements to ensure these products remain viable while customers prepare for the cloud. But the trend is clear: a growing number of Oracle customers are moving to Fusion Cloud to benefit from subscription-based applications running on Oracle's constantly updated, scalable cloud infrastructure.

The 2035 support extension gives you time, but not infinite time. CIOs should use this runway strategically to plan, negotiate, and execute the cloud migration on their own terms rather than being forced into a reactive transition when support eventually does end. The organisations that transition proactively, with a clear licensing strategy and strong negotiation position, consistently achieve better commercial outcomes than those that wait until they are under pressure.

On-Premises Licensing Versus SaaS: What Changes

The on-premises model uses perpetual licences. Large upfront licence fees per user or processor. Annual support and maintenance fees running 20-22% of the licence cost. The perpetual licence allows indefinite use of the software version owned. Support provides patches, upgrades, and Oracle support services. Licences are tied to specific modules or user counts with complex metrics. All licences in a licence set must share the same support status, meaning you cannot selectively drop support on individual modules within a set without consequences.

Oracle Fusion Cloud uses subscriptions. Subscribe on a per-user-per-month or per-employee basis. The subscription fee includes all support, maintenance, and updates. There is no separate maintenance line item: one predictable fee covers everything. Quarterly automatic updates are applied to all customers simultaneously. ERP spending shifts from CapEx to OpEx. You lease the software for the subscription term rather than owning it outright.

The key budget implication is the transition itself. When moving to SaaS, the organisation shifts from a perpetual licence plus maintenance cost structure to an all-in subscription cost structure. CIOs must anticipate the short-term overlap of costs, where the organisation is paying on-prem support and new cloud subscriptions simultaneously, and adjust financial planning to accommodate the new OpEx model. The strategies for avoiding this dual-cost period are among the most consequential decisions in the entire migration.

Licensing Pitfalls During the Transition

Migrating mission-critical systems from on-premises to SaaS requires careful planning to avoid licensing pitfalls that can add millions in unplanned costs.

The dual-use window is limited to approximately 100 days. Oracle generally allows up to 100 days of concurrent on-premises and cloud use during migration for business continuity. The organisation must time the migration carefully and ensure Fusion Cloud is fully operational within this window to remain compliant. If the migration takes longer than expected, which is common with complex ERP implementations, the organisation faces a compliance exposure unless an extension has been negotiated in advance.

Licence parallelism creates compliance risk during overlap. During the transition period, the organisation must maintain compliance on both environments with support paid on the on-premises system until cutover. Get written documentation from Oracle allowing concurrent use. Engage Oracle's Global Licensing Advisory Services (GLAS) for metric mapping between on-premises and cloud entitlements. Without this documentation, the organisation is exposed to audit risk on both environments simultaneously.

On-premises metrics do not map cleanly to cloud metrics. Fusion Cloud typically uses the "Hosted Named User" metric. Some modules use employee count, revenue, or other metrics. On-premises metrics based on Application User or Processor counts must be translated to the appropriate cloud metric for each service (ERP, HCM, SCM). Size cloud subscriptions correctly. Verify the specific metric for each cloud service to avoid over-licensing (paying for capacity you do not need) or under-licensing (creating a compliance gap that surfaces at the next Oracle review).

Customisations do not carry licence costs, but replicating functionality may. Custom modules built on the on-premises platform do not have separate licence costs. However, replicating that custom functionality in the cloud may require additional PaaS subscriptions or third-party solutions. Factor PaaS costs into the migration plan. Clarify how many environments are included with the subscription (typically two: production and test). If the organisation needs development sandbox or performance test environments, negotiate them upfront rather than discovering the cost later.

Data access and archival rights matter after migration. The perpetual licence allows read-only archival access post-migration. The organisation can terminate support on the old system while retaining the right to access historical data. Plan for archival use and consider "shelving" licences rather than fully terminating them. Shelved licences provide insurance: if the cloud migration fails or the organisation needs to fall back, the on-premises licences can be reinstated.

Converting On-Premises Licences to Cloud Credits

CIOs frequently ask: what happens to our existing EBS, PeopleSoft, or JDE licences and the money we have invested? Can we get credit when moving to Oracle Cloud? The short answer is that you cannot directly port an on-premises licence to SaaS because they are different delivery and licensing models. But Oracle offers programmes to leverage existing investments as you transition.

Oracle's Customer 2 Cloud Programme allows customers to redirect on-premises licence spend into cloud subscriptions. In practice, Oracle credits some of the support fees toward the Oracle Fusion Cloud subscription, effectively letting the organisation use its support budget to fund the new SaaS. The organisation stops paying support for the legacy product (or reduces it as modules move) and instead commits to a multi-year Oracle Cloud subscription contract. It is the annual support fees, not the sunk licence cost, that carry negotiating value. Oracle wants to keep ongoing spend in-house rather than losing customers to third-party vendors. They will apply support spend toward cloud services to deliver more value from the same budget.

Licence trade-ins or swaps are possible but require negotiation. Oracle may allow retiring certain on-premises licences in exchange for a cloud subscription discount, usually within the same product family (EBS Financials to ERP Cloud Financials, for example). This is a negotiated process, not an automatic entitlement. Outcomes may include reduced subscription prices, discounted migration services, or extended dual-use periods. The strength of the deal depends on the volume of licences being traded, the total value of the support stream, and the organisation's willingness to commit to a multi-year cloud agreement.

Shelfware represents an opportunity before migration. Before starting the cloud transition, audit licence usage. Unused modules represent wasted support dollars. Oracle may let the organisation terminate support on unused licences or trade them as part of the cloud deal, redirecting spend from idle shelfware to cloud services that will actually be used. This audit should happen well before the negotiation begins, as it establishes the baseline for how much support spend can be redirected.

Penalty waivers for partial support cancellation are negotiable. Oracle historically enforces penalties when customers cancel support on individual products within a licence set. However, these rules can be waived in a mutually beneficial cloud migration agreement. Negotiate which licences are being sunset and ensure Oracle agrees to let you discontinue support without penalty as you sign the cloud contract. This is one of the most frequently overlooked negotiation levers, and it can represent substantial savings.

Oracle SaaS Subscription Pricing

Per-user subscription pricing is the foundation. Fusion Cloud uses the Hosted Named User metric for most services, charged per-user monthly or annually. ERP Cloud lists at approximately $625/user/month at enterprise tier with a minimum of 10 users. HCM may use an employee count metric rather than named user. Enterprise deals rarely pay list price. Significant discounts are negotiable based on volume, commitment term, and the total value of the Oracle relationship including on-premises licence spend being redirected to cloud.

Modular purchasing versus bundled suites. Oracle offers both. Subscribe to the full ERP suite or select individual modules (Financials, Procurement, Project Management). Add-on modules come at additional cost. Map the cloud subscription to current on-premises functionality. Exclude modules that are unnecessary. Start with what is needed in Phase 1 and add later at contracted rates. Over-subscribing at the start locks in costs for modules that may not be deployed for months or years.

All-inclusive of support and updates. The subscription covers software usage, infrastructure, support, and quarterly updates. There is no separate maintenance line item. This simplifies budgeting but creates a different risk: subscription fees can increase at renewal. Negotiate caps on renewal increases, ideally no more than 3-5% annually. Without a cap, the organisation is exposed to whatever price Oracle chooses to set when the initial term expires.

Multi-year contracts drive deeper discounts. Commonly 3-year or 5-year agreements with payments often made annually in advance. Longer terms generate better discounts. But be cautious about over-committing. Balance the discount against flexibility. Generally, the organisation cannot scale down during the term. A 5-year commitment at a deep discount is only valuable if the user count and module mix remain stable for the full term. Consider a 3-year term for more frequent re-evaluation, even at a slightly lower discount, particularly during a first-time cloud migration where usage patterns are not yet established.

Growth and flexibility clauses protect future costs. Additional users and modules should be available at contracted rates rather than list price. Price-hold clauses lock the discount level for incremental purchases during the term. Negotiate these provisions now, during the initial deal, when Oracle is most motivated to win the cloud conversion. Adding users later without a price hold means paying whatever the current rate is at that point.

Environments and limits must be clarified upfront. Typically two environments are included (production and test). Additional environments for development, sandbox, or performance testing may incur extra costs. Clarify what is included before signing. If the organisation needs additional environments, negotiate them into the deal rather than purchasing them separately at list price after the fact.

Avoiding Duplicate Costs During Migration

One of the biggest financial risks in an Oracle cloud transition is paying for old and new systems simultaneously. Without proper planning, enterprises pay on-premises support and new cloud subscriptions concurrently, essentially double-paying for the same business capability during the transition period.

Leverage the 100-day transition window, and negotiate extensions if needed. Oracle permits approximately 100 days of concurrent use. Go live and decommission legacy within this window. If 100 days is insufficient for a complex migration, engage Oracle upfront. They sometimes extend the window for large customers or complex migrations if the extension is negotiated in advance as part of the cloud deal. Do not assume the extension will be granted after the fact.

Negotiate maintenance suspension during migration. Ask Oracle to suspend on-premises support fees during the active migration period. For a defined transition window, the organisation does not pay legacy support, freeing budget for the cloud subscription. Oracle may agree because they know the customer is moving off the on-premises product and committing to cloud. Get this documented in the contract. An informal agreement with the account team is not enforceable.

Co-term the cloud start with support expiration. Align the cloud subscription start date with the expiration of on-premises support. This way, the support payment rolls directly into the SaaS fee, avoiding writing two cheques for the same period. Time migrations with maintenance renewal cycles so the financial transition is clean.

Phased module migration reduces overlap costs. If moving in phases (Financials Cloud first, HR stays on PeopleSoft temporarily), negotiate reduced support costs for the modules that have been retired from on-premises. Work with Oracle to adjust support fees to match the reduced on-premises footprint as each module migrates. This requires explicit contractual language because Oracle's standard support policies do not automatically allow partial reductions.

Tight project governance prevents cost overruns from delays. A faster migration reduces overlap costs. While rushing an ERP project is inadvisable, tight project governance prevents delays that extend the dual-running period. Use Oracle's cloud implementation accelerators and experienced partners. Every month of delay represents a month of paying for both systems.

Third-party support is an alternative path but carries trade-offs. Some organisations switch to third-party support at approximately 50% of Oracle's fee for the final years of on-premises life. This reduces costs during the transition but can complicate the relationship with Oracle and make them less inclined to offer attractive cloud deals. If the end goal is Oracle Fusion Cloud, it is generally better to negotiate directly with Oracle, using the threat of third-party support as leverage rather than actually switching to it before the cloud deal is signed.

Contract Negotiation: Ten Strategies That Save Millions

Shelve, do not surrender, on-premises licences. Negotiate the right to shelve on-premises licences during the cloud subscription, retaining them as insurance. If the cloud journey fails or the organisation needs to fall back, the on-premises licences can be reinstated. Ensure the contract allows resuming support later if needed. Surrendering licences permanently eliminates the fallback option and weakens the organisation's negotiating position in future renewals.

Negotiate a formal transition period clause. Get a written clause for maintenance fee suspension or dual-use period. The contract should state that during migration, on-premises maintenance will not be charged (or those fees will be credited against cloud fees). Without a written agreement, the organisation may be stuck paying for everything. Verbal assurances from account teams are not enforceable.

Align cloud billing start with go-live. Align the billing start of subscriptions with the planned go-live date so the organisation is not paying for unused months. If the project slips, include a provision to adjust the start date or provide credits for lost time. Without this, it is common to waste a significant portion of the first-year subscription due to implementation delays. This single provision can save hundreds of thousands of dollars.

Avoid over-commitment by phasing purchases. Do not feel compelled to licence every user or module upfront. Start with what is needed in Phase 1 and include contractual options to add more later at the same discount. Clarify user definitions in the contract. Misdefining "user" or "employee" could mean you inadvertently need more subscriptions later when Oracle applies a different interpretation.

Negotiate renewal caps. Ensure the contract has a cap on price increases at renewal, no more than 3-5%. Verify the cap holds even if you renew with fewer users. Oracle's standard cap may be conditional on maintaining or increasing user count. Try to lock pricing for a range of user scenarios so the cap applies regardless of whether the organisation scales up or down.

Secure rebalancing rights. Negotiate a rebalancing clause that lets the organisation shift investment between cloud services (swap unused ERP users for HCM Cloud users, for example). Oracle sometimes allows exchanging a portion of unused subscriptions for others in their portfolio. Even partial rebalancing, say 20-30% of the contract value, provides valuable flexibility as the organisation's needs evolve.

Add a successor products clause. If Oracle discontinues or replaces a service, the organisation should get the equivalent new service at no additional cost. This protects against being forced into buying a more expensive package mid-term because Oracle changed its offerings. Oracle's product roadmap evolves constantly, and without this clause, the organisation is exposed to price increases driven by Oracle's packaging decisions rather than its own needs.

Balance long-term versus short-term contracts. Oracle will push for 5+ year terms with attractive initial discounts. Negotiate flexibility in any long-term deal: the right to reduce users at annual checkpoints, terminate specific modules, or an opt-out clause at a midpoint. Consider a 3-year term for more frequent re-evaluation, even at a slightly lower discount, particularly for a first-time cloud migration.

Use Oracle's fiscal calendar for leverage. Oracle's fiscal year ends May 31, with quarterly targets in August, November, February, and May. Plan the negotiation to coincide with quarter-end or year-end (Q4 is May) when sales representatives are under maximum pressure to close deals and may offer higher discounts. Do not let their timing rush a decision the organisation is not ready to make. Use it to the organisation's advantage when you are ready.

Engage expert help for Oracle mega-deals. If the organisation lacks experience in Oracle cloud deals, engage a third-party adviser or licensing expert. Firms experienced in Oracle contracts can benchmark the deal, identify hidden risks, and suggest additional terms (data export rights, SLAs, non-production usage rights). Oracle writes Oracle's contracts. You are allowed to propose amendments. Everything is negotiable, especially when transitioning to a major ERP platform. Oracle wants to win the cloud conversion, and that gives customers leverage.

Actionable Next Steps

Step 1: Inventory licences and contracts. Document all current Oracle application licences, modules, user counts, and support costs. Understand contractual renewal dates and restrictions including licence sets and ULAs. This is the baseline for negotiation and planning.

Step 2: Build the business case. Develop a multi-year TCO comparison between staying on-premises and moving to Fusion Cloud. Include software costs (licence versus subscription), hardware and infrastructure, support, personnel, upgrade costs, and qualitative benefits. This analysis must be done independently of Oracle's sales team.

Step 3: Engage Oracle and explore programmes. Contact your Oracle account manager or Customer 2 Cloud team to discuss available migration programmes, cloud credits, or financial incentives. Also consider a third-party licensing consultant for an independent view of your options and leverage points.

Step 4: Plan the transition phases. Identify which business processes or modules move first and the timeline. Coordinate with your licensing strategy. If Financials goes live in Cloud by Q4, plan to drop PeopleSoft Financials support by then. Account for the safe overlap period and contingencies for delays.

Step 5: Optimise contract timing. Time the cloud subscription purchase to coincide with support contract renewal or Oracle's quarter-end, whichever gives more advantage. If a support renewal is imminent, use the opportunity to negotiate a cloud deal instead of renewing another year of on-premises costs.

Step 6: Negotiate favourable terms. Push back on initial quotes and leverage the ten strategies in this playbook. Eliminate overlapping costs through maintenance holidays and credits. Include caps and flexibility. Secure pricing protections for future years. Address data residency, security, and compliance needs.

Step 7: Prepare internal stakeholders. Moving to the cloud changes how IT operates: no custom patches, a new update cadence, staff retraining. Assign someone to monitor cloud service usage and ensure compliance with user counts and terms. This prevents overage charges or true-up surprises.

Step 8: Execute and monitor. Track the timeline so on-premises use is terminated as planned. Verify Oracle delivers agreed services (integration assistance, training under Customer 2 Cloud). Post-migration, confirm all legacy support bills have stopped and new subscription billing aligns with the contract. Set reminders for renewal negotiation well before the initial term ends.