Oracle contracts contain no migration exception, so a parallel-run window can double your license liability for as long as both environments are live. This guide names where the exposure sits, quantifies it, and gives you the contractual and architectural moves that keep you from provisioning twice.
Oracle contracts contain no migration exception, so a parallel-run window can double your license liability for as long as both environments are live. This guide names where the exposure sits, quantifies it, and gives you the contractual and architectural moves that keep you from provisioning twice.
Oracle's licensing metric is deliberately simple and deliberately unforgiving. You must license every processor on which the software is installed and/or running. There is no clause anywhere in the standard Oracle License and Services Agreement (OLSA), the Ordering Document, or the Master Agreement that grants relief during a migration. If your legacy on-premises environment is live and your target cloud environment is also live during a phased cutover, both environments are licenseable at the same time. Oracle's own audit teams read this literally, and House of Brick, an Oracle audit-defense specialist, put it plainly in February 2026: "Oracle requires licenses for all processors where programs are installed and/or running, even if you're in a transition period. There is no migration exception in the contract."
The compounding rule is the "no double-dipping" prohibition. A single license entitlement cannot cover two concurrently running servers. So during a dual-active window you either hold enough entitlement to cover both stacks, or you keep the source stack genuinely offline until cutover. In 25 years of negotiating with this vendor, I have watched more migration budgets blow up on this single sentence than on any egress bill or cloud-rate arbitrage. The exposure is not exotic. It is the default state of a phased migration unless you engineer against it.
A phased Oracle migration doubles your license liability by default. Everything in this article is about engineering the exception Oracle never wrote into your contract.
Before you touch architecture, size the number you are trying to avoid. Oracle Database Enterprise Edition lists at 47,500 dollars per processor license. During a dual-run, that processor count applies on both sides. A modest 16-processor production estate that runs in parallel for a quarter is, on a strict reading, 16 processors of legacy plus 16 processors of target, which is 32 processors of entitlement (roughly 1.52 million dollars at list) instead of 16. The support stream (22 percent of net license, annually) rides on top.
Then add the options multiplier, which is where dual-running quietly detonates. Each licensable option applies to the same processor count on both source and target. Partitioning lists at 11,500 dollars per processor. If you run Partitioning, Advanced Compression, Diagnostics Pack, and Tuning Pack, the per-processor stack easily doubles the base EE price, and every one of those options is now counted twice for the overlap window. This is why a naive parallel run is not a 2x problem on the base engine, it is a 2x problem on the entire options tower.
| Cost component | On-prem source (16 proc) | Cloud target (16 proc) | Overlap exposure at list |
|---|---|---|---|
| Database EE base | $760,000 owned | $760,000 needed | +$760,000 if not BYOL |
| Partitioning option | $184,000 owned | $184,000 needed | +$184,000 |
| Advanced Compression | ~$187,000 owned | ~$187,000 needed | +~$187,000 |
| GoldenGate (both ends) | $280,000 source | $280,000 target | +$560,000 or 20% term |
| Support @ 22% | paid on source | paid on target | recurring, not one-off |
The table uses Oracle list prices from the current price list and standard 16-processor sizing to make the shape of the exposure visible. Your real number depends on your options footprint and negotiated discount, but the structure holds: the base engine is the smallest part of the problem. Model your own estate the same way before you approve any migration statement of work, and read the license review to run before you sign a migration SOW so this math is settled contractually, not discovered during an audit.
Oracle offers one formal, documented dual-run window, and it exists only when the target is Oracle Cloud Infrastructure (OCI). Under BYOL to OCI, Oracle typically grants a 100-day migration overlap during which you may run the same workload on-premises and in OCI without provisioning additional licenses. This is the closest thing to a contractual migration exception you will ever get from this vendor, and it is worth real money: 100 days of avoided double-licensing on a large estate is a seven-figure line item.
Three cautions govern this lever. First, it is OCI-specific. Oracle does not formally offer the 100-day window on AWS, Azure, or Google Cloud, so a parallel run into an Authorized Cloud Environment technically requires double licenses unless you negotiate the overlap into your Ordering Document. Second, 100 days is frequently too short for a complex phased migration, and many programs miss it. Third, when the window closes, the licenses you designated for cloud are deemed deployed there, and you lose the right to keep running them on-premises. The clock does not pause because your project slipped.
The 100-day OCI grace period is the only migration exception Oracle actually writes down. If your target is AWS or Azure, you have to buy that exception at the negotiating table.
Buyer action: if you have any pricing pressure with Oracle (a renewal, a cloud commitment, a support reinstatement), get the dual-use window written into the Ordering Document, extend it beyond 100 days in language, and remove the automatic "deemed deployed" trigger so a slipped project does not strand your on-prem rights. If your target is not OCI, treat the overlap as a negotiated concession you must extract, not a default you can assume. Compare the platform economics in which cloud makes the same Oracle workload cheapest to license before you commit the target.
The overlap window is only half the OCI advantage. The BYOL conversion ratio determines how much of your cloud target a given license count covers, and OCI is the most generous. Oracle's own BYOL FAQ confirms one Processor license maps to two OCPUs for Enterprise Edition, and Standard Edition converts at four OCPUs per license. So 16 Processor licenses cover an OCI VM of up to 32 OCPUs.
Authorized Cloud Environments are worse, and the reason is structural. Oracle explicitly disallows the Processor Core Factor Table in the cloud, and counts every two hyper-threaded vCPUs as one full Processor license. The worked example is stark: a 64-vCPU AWS m5.16xlarge instance requires 32 Processor licenses. The mechanics of that vCPU counting sit in the Oracle Authorized Cloud Environment policy and how cores are counted, and they change the math of any parallel run into a non-Oracle cloud.
A second warning on the vCPU rule: it is non-contractual. It lives in a policy document Oracle can revise at any time, not in your signed agreement. Pin the version of the policy in force on the date you deploy, and document each instance against that specific version. If Oracle later changes the counting, your evidence trail is your defense. The Standard Edition 2 cloud cap (eight vCPUs on AWS or Azure) and the Amazon RDS trap (Enterprise Edition on RDS is BYOL only, License Included is SE2) can also silently remove an entire migration pattern you assumed was available, so validate the target instance shape before you architect the cutover.
The tool most teams use to make a phased cutover work, Oracle GoldenGate, is itself a double-sided license event. GoldenGate is a separately licensed product that must be licensed on every database where it runs, source and target, using the same metric as the databases underneath it. So a GoldenGate-based migration between two 16-processor databases is 16 processors of GoldenGate on the source plus 16 on the target. At the list price of 17,500 dollars per processor, that is 560,000 dollars of tooling before the migration even begins.
The workaround exists and is well established. If GoldenGate will not be used beyond the migration itself, buy it as a one-year term license at 20 percent of perpetual cost. That converts the 560,000-dollar perpetual exposure above into roughly 112,000 dollars for the year, and the license terminates automatically one year from purchase. Buyer action: never let Oracle sell you perpetual GoldenGate for a migration. Scope it as a migration-only term license in the Ordering Document, and put the termination date in writing so it does not silently roll into your support base.
If you are using Data Guard rather than GoldenGate, know the boundary precisely. Standard Data Guard is included in Enterprise Edition and costs nothing extra. Active Data Guard, which lets you query a standby while it is in managed recovery, is a separately licensed option. Sources conflict on its list price (some cite 23,000 dollars per processor, others 11,500), so verify against the current Oracle price list before you assume you need it. Most migration cutovers do not require the read-on-standby capability that triggers the Active Data Guard charge. Do not enable it out of habit.
| Replication tool | List price / processor | Both ends? | Migration workaround |
|---|---|---|---|
| GoldenGate (Oracle-to-Oracle) | $17,500 | Yes, source + target | 1-year term at 20% of perpetual |
| GoldenGate (non-Oracle DB) | ~$17,500 | Yes | 1-year term |
| Data Guard (standard) | Included in EE | N/A | No cost, use it |
| Active Data Guard | $11,500 to $23,000 (verify) | Only where enabled | Do not enable unless read-on-standby is required |
The cleanest way to avoid paying twice is to make the dual-run window as short and as quiet as the migration allows. But be precise about what "offline" means to Oracle. House of Brick's decommissioning warning is the trap that catches experienced teams: because Oracle licenses where software is "installed and/or running," simply turning off a server or shutting down a RAC node may not clear the licensing threshold if the binaries remain installed and could run. The "shuffle game" of powering nodes down does not necessarily end the liability.
To genuinely remove a source environment from your licensed footprint you generally need to uninstall the software and document the state, not just stop the service. Build-ahead infrastructure follows the same rule: customers have no inherent right to stand up a build-ahead target and pay nothing for it. If Oracle is installed in both places, both places are licenseable. Sequence the work so the target is proven and cutover is clean, then decommission the source properly. The timing decisions that end your source liability are covered in when to decommission source licenses after an Oracle migration.
Your migration pattern also changes the license shape. A lift-and-shift rehost preserves your processor topology and is the easiest to license during overlap, while a refactor can change core counts and option usage on both sides. The trade-offs are quantified in how rehost, replatform, or refactor each change your Oracle license bill, and the broader portability picture, including egress cost, sits in the pillar on moving Oracle databases between clouds.
Consolidate the moves above into a sequence you can execute and defend in an audit.
The recurring theme across every one of these moves is the same: Oracle wrote no migration exception into your contract, so you must engineer one, either architecturally (short, quiet overlap; clean decommission) or contractually (a negotiated dual-use window and a term-licensed toolset). Do both. The difference between a controlled cutover and a doubled bill is entirely in the planning you do before the first byte replicates.
Only when the target is Oracle Cloud Infrastructure. Oracle typically grants a 100-day dual-use window for BYOL migrations to OCI, during which the same workload can run on-premises and in OCI without extra licenses. This grace period is not formally offered on AWS, Azure, or Google Cloud, where a parallel run technically requires double licenses unless you negotiate the overlap into your Ordering Document.
Possibly. Oracle licenses software where it is installed and/or running, so powering down a server or a RAC node may not clear the licensing threshold if the binaries remain installed and could run. To genuinely remove the source from your licensed footprint, uninstall the software and document the state rather than simply stopping the service.
Yes. GoldenGate is a separately licensed product that must be licensed on every database where it runs, source and target, using the same metric as the databases. At 17,500 dollars per processor list, that is double the tooling cost. Buy it instead as a one-year migration term license at 20 percent of perpetual, and document the termination date so it never enters your support base.
Two reasons. First, OCI's BYOL ratio is two OCPUs per Processor license, while Authorized Cloud Environments count every two hyper-threaded vCPUs as a full Processor license with the core factor disallowed. Second, OCI carries the 100-day dual-use grace period that AWS and Azure do not, so the overlap itself is cheaper on OCI.
More than the base engine does. Each licensable option (Partitioning at 11,500 dollars per processor, plus Advanced Compression, Diagnostics, and Tuning packs) applies to the same processor count on both source and target during the overlap. A full options tower can double the per-processor cost, so the biggest savings come from not enabling options on the target unless the workload requires them.
No. The Authorized Cloud Environment policy, including the vCPU counting rule and the disallowed core factor, sits in a non-contractual policy document that Oracle can revise at any time. Pin the version in force on your deployment date and document each instance against that specific version so you have an evidence trail if Oracle later changes the rules.
Oracle Cloud at Customer enterprise licensing framework. Buyer side framework across OCI Dedicated Region, Exadata Cloud at Customer, autonomous database.
Gated with a work email on the download page. No sales follow up you did not ask for.
Get the White Paper →
500+ enterprise clients. 11 vendor practices. Industry recognized. One conversation can change what you pay for the next three years.
One buyer side briefing a week. Renewal signals, audit moves, and the levers that work. No vendor spin.
