Oracle license migration rights decide whether you can move the value you already paid for into a different product or metric — and on what terms. Migrations and trade-ups both terminate your original licenses, reset your support base, and are governed by Oracle's migration policy, not by any free right to swap products. Former Oracle insiders explain how the mechanics work and where buyers quietly lose value.
Short answer: Oracle license migration rights are the contractual rules that let you move existing license value from one Oracle product or metric to another. A migration or trade-up terminates the original licenses, issues new ones, and recalculates your support base — it is a one-way, Oracle-controlled transaction, not a free right to swap products.
Definition: Oracle license migration rights are the contractual rules that let a customer move existing license value from one Oracle product or metric to another. A migration terminates the original licenses, issues new ones, and applies the prior support stream to the new product, governed by Oracle's migration policy rather than a general right to swap.
Migration is how Oracle handles the situation where the product you bought is no longer the product you need. You might be consolidating a discontinued product line onto a current one, moving from a packaged application onto a successor, or shifting a database deployment that has outgrown its original edition. The migration mechanism lets the money you have already committed follow you — but only within the boundaries Oracle sets.
The critical point most buyers miss is that migration is a privilege Oracle grants, not a right you hold. Your Order Form licenses a specific product on a specific metric. Anything else — a different product, a different edition, a different counting model — is a migration that Oracle prices and approves transaction by transaction. Understanding that asymmetry early is the difference between a clean conversion and a back-license claim. We treat migration modelling as a core deliverable of our Oracle license optimization service, and frame it against the wider Oracle Database Licensing Guide.
Definition: An Oracle trade-up is a transaction where a customer exchanges older or lower-tier licenses for newer or higher-tier ones, usually receiving a credit for the value of the licenses surrendered. Standard Edition 2 to Enterprise Edition is a common trade-up. The original licenses are terminated and the credit reduces, but rarely eliminates, the cost of the new licenses.
A trade-up is migration's commercial cousin. The textbook case is an enterprise that has outgrown Oracle Database Standard Edition 2 (SE2) and needs Enterprise Edition (EE) features — Partitioning, Advanced Security, or Real Application Clusters. Rather than buy EE from scratch, the customer trades up, surrendering the SE2 licenses and receiving a credit against the EE purchase. On paper it rewards loyalty; in practice the credit is whatever Oracle decides it is worth.
The trade-up credit is the negotiation. Oracle frames it as a fixed entitlement, but the credit value, the list price it is applied against, and the discount on the net are all movable. Accept the first number and you typically leave money on the table. In our engagements, roughly 1 in 3 enterprises that accepted an Oracle trade-up at face value overpaid because the credit was applied to inflated list pricing rather than a negotiated rate (Oracle Licensing Experts benchmark, 2026). The trade-up only protects value if you challenge every component of the maths.
Before you accept, have it modelled buyer-side. Our Oracle contract negotiation team challenges the credit, the list price, and the support recalculation — line by line.
Direct answer: A migration moves license value between products or metrics, often at parity, to keep an existing investment usable. A trade-up specifically exchanges lower-value licenses for higher-value ones and almost always requires additional payment beyond the credit. Both terminate the original licenses; only the trade-up reliably costs more money.
The terms overlap and Oracle uses them loosely, but the distinction matters for budgeting. A migration is frequently value-neutral on its face — you are relocating an entitlement you already own. A trade-up is by definition an upgrade, so Oracle expects incremental revenue. Knowing which conversation you are in tells you whether to expect a bill and how large it should be.
| Dimension | License migration | License trade-up |
|---|---|---|
| Purpose | Move value to a different product or metric | Upgrade to a higher-tier product |
| Typical direction | Lateral (product to product) | Upward (SE2 to EE, lower to higher edition) |
| Original licenses | Terminated | Terminated, partial credit issued |
| Net cost | Often near parity; fees vary | Almost always additional payment |
| Support base | Recalculated to new net price | Recalculated, usually higher |
| Reversible | No | No |
Read the table and the shared row jumps out: neither is reversible, and both reset support. That is the structural risk in any conversion. You are surrendering a fixed, paid-up entitlement with a known support base in exchange for a new one whose terms Oracle sets. Get the new pricing wrong and you are locked into a higher annual support bill for the life of the licenses.
Direct answer: The support stream carries over to the migrated product, but the support base is recalculated against the new license's net price. Because Oracle charges 22% of net license value per year for Enterprise Support, migrating to a higher-value product can raise your annual support bill even when the upfront migration credit looks generous.
Support is where migrations bite quietly. Oracle's Enterprise Support is priced at 22% of net license value per year (Oracle Technology Price List, 2026), so your annual cost is anchored to the net price of whatever licenses you hold. When you migrate or trade up to a higher-value product, that anchor moves with it. The upfront credit grabs the headlines; the recurring support increase runs for as long as you own the licenses and compounds with Oracle's annual uplift cap.
This is also where Oracle's matching service levels and repricing rules come in. Migration cannot be used to drop support on part of an estate and keep it on the rest if the licenses sit in the same support set — Oracle's policy is designed to prevent exactly that kind of partial termination. Before agreeing to any conversion, model the multi-year support trajectory, not just year one. Our Oracle support reduction analysis exists precisely to surface these recurring costs before they are locked in.
Support trap: Oracle frequently presents a migration credit as a saving while the recalculated support base raises your annual bill for a decade. Always compare the net present value of the support stream before and after — not just the one-time credit.
Direct answer: Sometimes, but a metric change — for example Named User Plus to Processor — is not an automatic right. Oracle treats it as a migration under its migration policy and may reprice the licenses at current list rates. Always confirm the conversion ratio and the resulting support base in writing before agreeing.
Metric migrations are among the most contested conversions because the counting models are not interchangeable. A Named User Plus (NUP) license counts people; a Processor license counts cores after the Core Factor Table is applied. Moving between them is not arithmetic Oracle is obliged to perform in your favour — Oracle decides the conversion ratio, and it will often anchor the new Processor quantity to current deployment rather than the historical NUP entitlement, which is where unexpected back-license exposure surfaces.
If you are considering a metric migration — typically because a deployment has grown past the point where user-based licensing is cheaper — model both metrics independently first. Calculate the Processor requirement using the correct Core Factor, compare it to your NUP minimums, and only then engage Oracle with your own number in hand. Going in without an independent count means accepting Oracle's, and Oracle's count is built for Oracle's revenue. This is core forensic work in our Oracle compliance review.
Direct answer: Buyers lose value in four places: an underpriced trade-up credit, inflated list pricing the credit is applied against, a silently higher support base, and the loss of legacy discount levels and contract terms attached to the surrendered licenses. Each is negotiable, and each is easy to miss.
The first leak is the credit itself — Oracle sets it, and the opening figure is rarely its ceiling. The second is the list price the credit offsets: a generous-looking credit against full list can be worse than a smaller credit against a negotiated rate. The third is support, covered above. The fourth, and the most overlooked, is contractual: the licenses you surrender often carry a discount level, a favourable metric definition, or legacy terms that simply vanish when those licenses are terminated.
That last point is where migrations do lasting damage. If your 2015 licenses sit on a 75% discount and an older, narrower definition of "Processor," trading them up resets you to today's pricing and today's broader definitions. You can win the credit negotiation and still lose the war if you have surrendered terms worth more than the credit. Always inventory exactly what you are giving up before you focus on what you are getting. We document this kind of preserved-value outcome in our client case studies.
Direct answer: Negotiate a migration in four steps: inventory the licenses and terms you are surrendering, model the target product on both pricing and support, challenge the credit and the list price it offsets, and never let the migration ride a deadline Oracle sets. Treat the conversion as a fresh purchase, because that is what it is.
A migration is a one-way door, so the leverage all sits before you sign. The sequence that protects value is deliberate. First, document precisely what you hold — product, metric, quantity, discount level, and any legacy clause attached. Second, model the target product fully, including the recalculated support base over the full life of the licenses. Third, treat the credit, the list price, and the net discount as three separate negotiations. Fourth, refuse to be rushed: Oracle's quarter-end and year-end deadlines exist to compress your analysis, not to help you.
Done in that order, a migration can genuinely protect the value you have already paid for. Done in Oracle's order — credit first, deadline pressure applied, support glossed over — it quietly transfers value back to Oracle. The right-sizing and benchmarking that make the difference are exactly what our Oracle contract negotiation team delivers, and you can explore more across the Oracle Licensing Experts blog.
We inventory what you surrender, model the target on price and support, and negotiate every component buyer-side. Talk to a former Oracle insider before you sign a one-way deal.
Oracle license migration rights are the contractual rules that let a customer move existing license value from one Oracle product or metric to another. A migration terminates the original licenses, issues new ones, and applies the prior support stream to the new product. Migrations are governed by Oracle's migration policy, not by a general right to swap products freely.
An Oracle trade-up is a transaction where a customer exchanges older or lower-tier licenses for newer or higher-tier ones, usually receiving a credit for the value surrendered. Standard Edition 2 to Enterprise Edition is a common example. The original licenses are terminated, and the trade-up credit reduces but rarely eliminates the cost of the new licenses.
No. A migration or trade-up terminates the original licenses permanently. You cannot revert to the old product or metric, and you lose any legacy pricing, discount level, or contract terms attached to the surrendered licenses. Because the decision is one-way, it must be modelled fully before signing.
The support stream usually carries over to the migrated product, but the support base is recalculated against the new license's net price. Because Oracle support runs 22% of net license value per year (Oracle Technology Price List, 2026), a migration to a higher-value product can increase your annual support bill even when the upfront migration credit looks generous.
Sometimes, but metric changes — for example Named User Plus to Processor — are not an automatic right. Oracle treats them as a migration governed by its migration policy and may reprice the licenses at current list rates. Always confirm the conversion ratio and the resulting support base in writing before agreeing to any metric migration.
Rarely. A trade-up credit reflects a portion of the value of the licenses you surrender, applied against the list price of the new licenses. Oracle sets both the credit and the new pricing, so the net cost can still be substantial. Treat the headline credit as a negotiation starting point, not a fixed entitlement.
Only if you genuinely need Enterprise Edition features and have modelled the full cost. A trade-up from Standard Edition 2 to EE terminates the SE2 licenses, applies a partial credit, and resets your support base to the higher EE net price. Confirm the feature requirement, the credit, and the recurring support increase before committing — the move is permanent.
Migration and trade-up benchmarks, support recalculation tactics, and negotiation intelligence from former Oracle insiders. Corporate email required.
Written by the Oracle Licensing Experts Team — former Oracle executives, LMS auditors, and contract managers with 25+ years of combined Oracle licensing experience. Not affiliated with Oracle Corporation. All advisory is independent and 100% buyer-side.