Oracle EBS to Fusion Migration Licensing

From perpetual licence to subscription

Moving from E-Business Suite to Fusion Cloud Applications is not an upgrade; it is a change of licensing model. EBS is licensed perpetually, with a one time licence fee and an annual support stream you can, in principle, run indefinitely. Fusion is a subscription, priced per user per month or per defined metric, that exists only while you pay for it. The two are different products under different contracts, and migrating does not convert one into the other. You do not trade your EBS licences for Fusion entitlement; you acquire a new subscription and decide, separately, what to do with the perpetual estate you already own.

This distinction governs the economics of the whole transition. Because the EBS licences are perpetual, you are not forced to abandon them on a timetable Oracle sets; you can keep them supported, drop them to a third party maintainer, or let support lapse while retaining the right to run the software. Each option has consequences for cost and audit exposure, and the choice should be made deliberately rather than swept along by the Fusion project. The wider framing of how EBS entitlements behave sits in the EBS licensing pillar, and the support dimension is developed in the support renewal strategy article.

The dual maintenance window

No serious EBS estate migrates to Fusion overnight. The two systems run in parallel for months or years while data is migrated, processes are rebuilt, and users are cut over module by module. Throughout that window you pay for both: EBS support continues because EBS is still in production, and the Fusion subscription has begun because Fusion is being stood up. This dual maintenance cost is the single most underestimated line in transition budgets, and its size is a function of duration. A migration that drifts from eighteen months to three years can double the overlap cost without anyone deciding to spend the difference.

The buyer side response is to plan the EBS support drawdown explicitly against the Fusion ramp. As modules cut over and EBS usage falls, the EBS support base should be reviewed for reduction, subject to Oracle's matching service level and repricing rules that constrain partial termination. The aim is to compress the overlap and to ensure that what you continue to pay EBS support on is genuinely still in use, not a full estate left on maintenance out of inertia while Fusion absorbs the work.

Why you negotiate before you move

The most expensive mistake in a Fusion transition is negotiating from a position of commitment. Once you have publicly chosen Fusion, begun decommissioning EBS, and told Oracle the direction of travel, your alternative has evaporated and with it your discount leverage. Oracle prices Fusion deals in relation to the credibility of your alternative, and an active, supported EBS estate that you could plausibly keep running is the strongest alternative you have. The negotiation should therefore happen while EBS is fully live, before any irreversible step, when staying put remains a real option you can articulate.

This is the same leverage principle that governs every Oracle commercial event, and it is why a Fusion move benefits from being structured as a negotiation rather than a procurement. Where the estate also carries an unlimited agreement, the interaction between a ULA and a Fusion transition is intricate and should be handled with ULA negotiation support, because certification timing and cloud commitments can either fund or undermine the move depending on sequencing.

Customer bridge and credit programs

Oracle periodically offers mechanisms that recognise a customer's existing on premise investment when they move to Fusion, ranging from migration credits to support offset arrangements to OCI consumption programs such as Support Rewards. These can materially reduce the net cost of a transition, but they share three characteristics: they are discretionary, they are time bound, and they are negotiated rather than published. None of them should be assumed as an entitlement, and all of them should be quantified against the dual maintenance cost they are meant to offset rather than accepted as headline goodwill.

The OCI consumption route is worth particular attention because it connects the Fusion decision to infrastructure strategy. Running residual or transitional EBS on OCI can generate the consumption that funds Support Rewards, a path explored in the EBS on OCI article. The levers are most powerful when combined and sequenced, which again argues for negotiating the whole transition as one commercial event.

What happens to your residual EBS estate

Few EBS estates migrate to Fusion completely. Specialised modules, heavily customised processes, and integrations with no Fusion equivalent often remain on EBS long after the core financials have moved. This residual estate still needs licensing, still carries support cost, and remains fully auditable. The transition plan must therefore include a decision about the residual: keep it supported, move it to a third party maintainer, or rationalise it down to the minimum that genuinely cannot move. Leaving the residual undefined is how customers end up paying full support on a fraction of an estate while believing they have left EBS behind.

Crucially, the transition itself is an audit trigger. A migration signals change, and change prompts Oracle to verify the existing position before it is disturbed, which is why a clean support renewal strategy and an accurate baseline matter most precisely when you are leaving. The applications licensing practice structures the residual decision so that the estate you keep is deliberate and the estate you retire is properly closed out.

The buyer side view

A Fusion migration is a commercial event dressed as a technology project, and treating it only as the latter is how the economics go wrong. The buyer side discipline is to negotiate while EBS is still live and credible, to compress the dual maintenance window by drawing down EBS support as modules cut over, to pursue every credit and offset lever as a negotiated benefit rather than an assumed one, and to make a deliberate decision about the residual estate. Do these, and Fusion becomes a controlled transition; skip them, and it becomes an open ended period of paying for two systems with diminishing leverage.

The recurring theme is timing. Leverage, dual maintenance, credit eligibility, and audit exposure all turn on when you act relative to the migration's irreversible steps. Acting early, while the alternative is real, is worth more than any single discount Oracle will offer once you have committed. To structure a Fusion transition around your leverage rather than Oracle's timetable, request a consultation.

Data, customisations and the re-implementation reality

The phrase migration understates what moving from EBS to Fusion actually involves. EBS is highly customisable, and most long standing estates carry years of bespoke code, custom modules, personalisations, and integrations that have no direct equivalent in Fusion's standardised SaaS model. Fusion does not accept EBS customisations; it offers configuration within defined boundaries and extension through its own platform. The consequence is that a Fusion move is usually a re-implementation, not a lift and shift, and the licensing timeline is therefore long, which feeds directly into the dual maintenance cost.

This re-implementation reality has a licensing dimension that is easy to miss. The longer the project, the longer EBS must remain fully licensed and supported in parallel, and the customisations that take longest to rebuild are precisely the ones that keep specific EBS modules in production after the rest have moved. A single heavily customised module with no Fusion equivalent can hold an entire EBS support set open long after the core financials have cut over, which is how the residual estate problem arises. Scoping the customisation rebuild early is therefore a licensing exercise as much as a technical one, because it determines how long you pay for two systems.

The buyer side response is to inventory customisations at the start and classify each as replaceable by Fusion standard functionality, rebuildable on the Fusion platform, or genuinely unique and likely to keep a module on EBS. That classification drives both the project plan and the support drawdown schedule, and it prevents the common outcome where the migration is declared complete while a long tail of customised modules quietly keeps the EBS support bill alive.

Sequencing the move against the renewal

The timing of a Fusion negotiation should be set by your own contract calendar, not by Oracle's sales cycle. The strongest moment to negotiate is when your leverage is highest and your alternative most credible, which is typically well before an EBS support renewal while the estate is fully live. Negotiating a Fusion deal in the same window as a support renewal lets you weigh the two against each other: the cost of continuing EBS support is the explicit alternative to the Fusion subscription, and having both numbers on the table at once sharpens the negotiation.

The sequencing also interacts with any unlimited agreement in force. A ULA approaching certification, a renewal approaching its date, and a Fusion decision in flight should be planned as one connected event, because each affects the others and Oracle will certainly model them together. Handling them in isolation hands Oracle the advantage of the combined picture; planning them together with negotiation support keeps that advantage on your side of the table.