Moving to Fusion retires no license. You now hold two estates.
Moving off Oracle E-Business Suite or PeopleSoft does not retire a single perpetual license. Your licenses survive untouched, nothing is traded in automatically, and nothing is canceled for you, so you end up holding two estates at once and the commercial work is deciding what happens to the old one. Oracle presents this as a migration. Commercially it is an addition, and the overlap window, not the subscription, is the line most transition budgets get wrong.
Prepared by Redress Compliance · August 9, 2026 · Oracle advisory. Based on 20 to 30 E-Business Suite and PeopleSoft moves to Fusion worked 2024 to 2025.
Executive summary
You hold three positions during the move, and they move independently.
Your perpetual licenses stay yours and valid under their original agreement; your annual technical support is a separate stream you may keep, reduce or stop; and the Fusion subscription is a new contract with its own metrics, term and upward renewal.
The most common transition mistake is assuming that signing the third one automatically resolves the first two.
There is no exchange rate between an E-Business Suite license and a Fusion subscription: there is only a negotiation about what Oracle will give you for walking away from an annual support stream it currently collects.
And the model shifts you from owning software with predictable support to renting a service where stopping payment stops the system.
Partial support termination reprices the support you keep, so the saving you model is rarely the saving you get.
Oracle requires matching service levels across licenses in the same set, so support is an all-or-nothing decision at the set level, and it reprices the remainder when you reduce, which can erase most of the saving from the part you dropped.
A partial exit is therefore often worth less than it looks and a full exit worth more, so model both before you choose a sequence, because the sequence determines which one you get.
Reinstatement is not a rollback either: a lapsed stream is priced back from the period you did not pay, so the rule from the transitions we have run is simple, never lapse a stream you might need again inside two years.
The support credit is a negotiated number, not a formula, and it was understated in 40 to 60 percent of first proposals.
The credit is Oracle buying the annual stream it is about to lose, not a valuation of your perpetual licenses and not the same thing as Oracle Support Rewards, which touches infrastructure support rather than an applications subscription.
Anchor it to the documented annual support fee on the estate you are leaving: pull the last two renewal notices for every support identifier, list each product and fee, total it.
And make that total the reference point every conversation returns to, because the value rose when buyers produced the actual renewal invoices.
The best terms about the old estate are available only while Oracle still wants the new signature.
The double run is the single largest surprise in transition budgets, and it runs 12 to 24 months.
A ledger-by-ledger or country-by-country rollout means the last legal entity cuts over long after the first, and support cannot stop until it does, so legacy support stays at full cost throughout.
A consequence of matching service levels that makes the exit a single event at the end rather than a gradual reduction.
Attack the start date first, because it is the cheapest concession Oracle can make and the one with the largest cash effect: set the subscription start at first production use of the first module, activate quantities by wave.
And weight the support credit toward the overlap months where your cash pain actually sits, not spread evenly across a five-year term where it does nothing for the eighteen months you carry both cost bases.
The four things you can do with a dormant estate
| Option | What it costs | What you keep | When it fits |
|---|---|---|---|
| Keep Oracle support running | Full annual fee, with the usual increase | Patches, updates, and ticket rights | While any unit is still transacting |
| Move to third party support | Materially less, no Oracle patches | Break-fix and tax updates from the provider | Long tail archive or slow rollout |
| Drop support, keep licenses | Nothing ongoing, high reinstatement risk | The perpetual right to run what you have | A frozen archive you will never patch |
| Terminate the licenses | Nothing, and it is irreversible | Only whatever Oracle credited you for it | Only as a priced concession in the new deal |
Never terminate quietly. Termination is the one action with no way back, and it is also the only thing on this list Oracle actively wants, which tells you it should be sold rather than given.
Get the dormant position confirmed in writing, because if you might reactivate the old system for a divested unit or a slow region you want it recorded that the perpetual licenses stay valid and on what terms support can return.
During a transition the third-party support case is unusually strong, because you are not asking the provider to sustain the estate forever, only across the tail; that case sits in the Oracle third party support guide.
And there is no cliff forcing your hand: Oracle extended Premier Support for E-Business Suite 12.2 through at least 2036 and has repeatedly extended PeopleSoft, so confirm your exact release dates in the lifetime support policy, but the timetable is yours to set.
If the technology estate sits under an unlimited agreement, sequence the certification against the migration, because certifying mid-move produces the worst possible count; the Oracle ULA guide explains why.
The double run, and how to shorten it
| Period | Legacy support | Fusion subscription | What to negotiate |
|---|---|---|---|
| Months 1 to 6, build | 100 percent | Should be zero | Start date tied to first production use |
| Months 7 to 12, wave one live | 100 percent | Wave one quantities only | Activation by wave, not all on day one |
| Months 13 to 18, waves two and three | 100 percent | Rising toward full | Support credit weighted to this window |
| Month 19 onward | Archive only, or zero | Full | Clean exit from the whole support set |
Legacy support stays at full cost throughout the overlap, which is why the exit is a single event at the end rather than a gradual reduction.
Five moves shorten the window: set the subscription start at first production use of the first module written into the ordering document, activate quantities by wave so you pay for the population actually live, compress the tail by moving the smallest and slowest entities first rather than last.
Weight the support credit toward the overlap months, and set a hard date for the legacy support exit with the archive planned around it.
The start date is worth more than most discount arguments and almost nobody puts it on the table until the paperwork is drafted, because every month of subscription before first production use is money spent on an empty tenancy.
The subscription mechanics and the six unfixable terms sit in the ERP Cloud negotiation playbook, and the metric detail in the Cloud ERP pricing guide.
The cost outside the subscription
The transition usually costs more than the subscription itself, and almost all of it lands in customization, integration and testing, so model five years rather than one, because implementation is front-loaded while change never stops.
Custom code does not migrate: every extension, form personalisation, custom report, workflow rule and interface is a separate decision to retire it, replace it with configuration, or rebuild it outside the application.
And that inventory has to be compiled before design starts, because teams that compile it afterwards discover the rebuild scope halfway through the build, when it can only be handled as a change request at the systems integrator rates.
Custom forms become configuration or an extension outside the core with retesting every quarter, custom reports are rebuilt report by report on the delivered tooling often in the hundreds, workflow and approval rules are reimplemented in the delivered engine as a process redesign.
And database-level interfaces are rebuilt against the Fusion integration layer.
Statutory retention outlives the program too: finance, tax and audit obligations commonly require seven to ten years of transaction history while Fusion migrations carry only a limited number of years of open items, so a read-only copy of the old application usually has to live on.
And a running instance is a deployed instance that still consumes licenses.
Decide early whether history lives in Fusion, in a read-only legacy instance, or in a dedicated archive, price the archive option including the people who know how to query it, confirm the read-only licensing position in writing.
And agree with audit and tax in advance what evidence they will accept.
The Fusion destination is mapped in the Fusion SaaS renewal playbook.
- Percentile standing for your exact deal size and industry, from real closed transactions
- Scenario simulation before the call: test alternative terms and see the financial impact of each
- A negotiation playbook, talking points, and a two page executive brief on day one
What we saw across Oracle Fusion transitions, 2024 to 2025
Across 20 to 30 moves from E-Business Suite or PeopleSoft to Fusion Fredrik Filipsson worked on during 2024 and 2025, the old estate was treated as an afterthought, and the same four patterns recurred:
First proposals that understated the support credit value. It rose when the buyer produced the actual renewal invoices for every support identifier.
How long teams that planned to switch the old system off within months of go-live were still running a read-only legacy copy.
Nobody owned the legacy estate once the program started, so support renewals kept paying themselves automatically; the customization inventory was compiled after design started, which is how integration rebuild lands as an unbudgeted change request.
And the read-only copy nobody budgeted for outlived the plan by years.
The asset-by-asset position needs deciding deliberately: the E-Business Suite applications go dormant with support optional and the credit tied to the full documented fee, PeopleSoft modules stay supported until the final cutover.
The Oracle Database beneath the apps is still licensed and often still needed so it plans as its own track, middleware is inventoried for what the interfaces still use, and custom extensions are scoped for rebuild before signing.
On premises exposure is technical and can be remediated by changing the deployment; subscription exposure is contractual and can only be remediated by paying or negotiating, which is the row CIOs most underestimate.
Rank the estate by how badly it degrades without patches, payroll and statutory reporting first because legislative updates arrive on a statutory calendar, financials core and analytics last, and that ranking tells you what you can drop first and what must run until the last day.
The support repricing detail sits in Oracle's technical support policies, read before you cancel a single line.
Your first five moves
- Name an owner for the legacy estate on day one, because unowned support renewals pay themselves automatically for the whole double-run window.
- Anchor the support credit to the actual invoices: pull the last two renewal notices per support identifier, total the documented fee, and make it the reference every conversation returns to.
- Model a full exit against a partial one before choosing a sequence, because matching service levels and repricing on reduction mean a partial exit is often worth less than it looks.
- Set the subscription start at first production use and activate quantities by wave, then weight the support credit toward the overlap months where the cash pain sits.
- Compile the customization inventory before design starts and confirm the read-only archive licensing in writing, because a running instance is a deployed instance. The Oracle practice runs the transition with you.
Frequently asked questions
What happens to your Oracle perpetual licenses when you move to Fusion?
Nothing happens to them automatically. They remain perpetual, they remain yours, and Oracle does not take them back or credit them against the subscription unless you negotiate that explicitly.
There is no exchange rate between an E-Business Suite or PeopleSoft license and a Fusion subscription, only a negotiation about what Oracle will give you for walking away from an annual support stream it currently collects.
Never terminate a license quietly, because termination is irreversible and is the one thing Oracle actively wants.
Does dropping on-premises Oracle support save the full invoice?
Rarely, because of two policy mechanics. Oracle requires matching service levels across licenses in the same set, so you cannot support some and stop supporting others of the same product, and it reprices the remainder when you reduce, which can erase most of the saving from the part you dropped.
A partial exit is often worth less than it looks and a full exit worth more, so model both before choosing a sequence, and never lapse a stream you might need again inside two years, because reinstatement is priced back from the unpaid period.
How long does the double-run overlap last on a Fusion transition?
Twelve to twenty-four months on a phased rollout, and it is the single largest surprise in transition budgets.
A ledger-by-ledger or country-by-country rollout means the last legal entity cuts over long after the first, and legacy support cannot stop until it does, so it stays at full cost throughout because of matching service levels.
Shorten it by setting the subscription start at first production use, activating quantities by wave, and moving the smallest, slowest entities first to compress the tail.
How do you protect the Oracle support credit in a Fusion deal?
Anchor it to the documented annual support fee on the estate you are leaving and produce the invoices. The credit is a negotiated number, not a formula, and it was understated in 40 to 60 percent of first proposals, rising when buyers produced the actual renewal notices.
Pull the last two renewals for every support identifier, list each product and fee, total it, and make that the reference point. It is Oracle buying the stream it is about to lose, not a valuation of your licenses and not the same as Oracle Support Rewards.
Do you still need licenses for the old Oracle system after go-live?
Usually yes, for years.
Statutory retention commonly requires seven to ten years of transaction history, while Fusion migrations carry only a limited number of years of open items, so a read-only copy of the old application often has to live on, and a running instance is a deployed instance that still consumes licenses.
Decide early whether history lives in Fusion, a read-only legacy instance, or a dedicated archive, confirm the read-only licensing position in writing, and agree with audit and tax in advance what evidence they will accept.
Is there a deadline forcing a move off E-Business Suite or PeopleSoft?
No. Oracle extended Premier Support for E-Business Suite 12.2 through at least 2036 and has repeatedly extended PeopleSoft under its applications commitment, so no cliff is pushing your hand.
Confirm the current dates for your exact releases in Oracle's lifetime support policy, but the point is that the timetable is yours to set, which means the best commercial terms about the old estate are available while Oracle still wants the new signature, not under a manufactured deadline.
