When to Decommission Source Licenses After an Oracle Migration

Your migration go-live does not end your source-environment liability, and powering off a server does not free a single license. This guide sets out exactly when binaries qualify for reclaim, why the DBA feature-usage record outlives your cleanup, and how the support-matching rules quietly erase the savings you assumed you had booked.

Most migration plans treat decommissioning as an afterthought: a line at the bottom of the runbook that reads 'shut down old environment.' In my experience across 25 years of Oracle negotiations, that line is where seven-figure liabilities hide. The migration is the interesting engineering; the decommission is where the money is either recovered or forfeited. Oracle knows this, which is why the audit letters so often arrive during the exact window when both environments are running.

This page walks the decommission decision on the buyer's side: when a source license actually becomes reclaimable, what the database records against you permanently, how to reallocate entitlement without paying twice, and why terminating the deployment does not terminate the support bill. Read it alongside the dual-running cutover guide, because the two problems overlap during the parallel-run period.

The rule that governs everything: installed and used

Oracle's liability trigger is not 'active use.' It is 'installed and/or running.' Redress Compliance's own analysis (April 2026) states the foundational rule plainly: 'simply installing Oracle software on a server creates a licensing obligation, whether or not the software is actively used. Passive installation counts.' Oracle's metric definitions confirm the software must be licensed once it is 'installed and/or running.'

Two operational consequences flow from this. First, there is no migration exception in the contract. House of Brick put it bluntly in February 2026: 'There is no migration exception in the contract.' Your source environment is fully licensable for every day it sits installed, regardless of whether production traffic has moved to the target. Second, powering off is not decommissioning. Again from House of Brick: 'simply turning off a server or RAC node may not actually meet this threshold.' A stopped instance with binaries still on disk is still installed. Oracle can and does count it.

The reclaim timing rule is therefore precise and narrow. Version 1 (February 2022) states it correctly: 'As soon as you have removed your binaries from your on-premises environment, you can remove the associated license.' Binary removal, not a graceful shutdown, is the event that frees the entitlement. Until the ORACLE_HOME is gone from every host in the source estate, you own the liability.

Powering off a server is not decommissioning. Only binary removal frees the license, and Oracle counts everything installed until then.

Why teams get trapped: the delay reflex

The behavioral pattern is consistent. Version 1 again: 'people take a long time to decommission servers; naturally, they are wary about switching off servers that have been in use for years.' The rollback anxiety is legitimate. A validated cutover can still surface an edge case a month later, and no operations lead wants to be the person who bulldozed the fallback environment. So the source estate lingers. It lingers for 60 days, then 120, then a fiscal quarter, and every one of those days is a fully licensable, fully supported deployment sitting on your books.

The buyer discipline here is to separate rollback preservation from license reclaim. You can keep a cold backup, a snapshot, or an offline image that contains no running or installed Oracle binaries, and you lose nothing on the audit-defense side. What you cannot do is keep a warm, patched, installed source environment 'just in case' and expect Oracle to treat it as decommissioned. If it is installed, it is licensable. Decide upfront how long rollback capability is genuinely needed (I recommend a fixed window tied to your first month-end close and reconciliation), then remove binaries on schedule.

The permanent record: DBA_FEATURE_USAGE_STATISTICS

Here is the trap that catches even careful teams. Decommissioning cleanly frees the base license, but it does not erase the history of what ran on that database, and Oracle audits history, not just the snapshot on audit day. Fredrik Filipsson's analysis (May 2025) is explicit: 'the audit isn't just about your status on the day of the audit, but also about any past period of under-licensing.'

The mechanism is the DBA_FEATURE_USAGE_STATISTICS view, refreshed by a hidden internal job roughly weekly. Redress Compliance's August 2026 analysis describes the behavior most buyers miss: 'Drop every partitioned table in the database, and the Partitioning row survives with its FIRST_USAGE_DATE, its LAST_USAGE_DATE, and its DETECTED_USAGES count intact. Once a feature appears in the view it is recorded permanently.' House of Brick confirms this is the same data Oracle references in a formal audit.

The licensing consequence is disproportionate. Per Redress Compliance: 'The view records that a feature was touched; Oracle's licensing rule then requires that the corresponding option be licensed on every processor of the database where it was touched.' A five-second developer experiment with Partitioning, Advanced Compression, or a Diagnostics Pack function becomes a per-processor claim across the entire instance. And these options are enabled by default at install, which Palisade Compliance (September 2025) calls a 'revenue trap,' noting that more than 80 percent of database-audited customers are found using unlicensed options inadvertently.

The worst move you can make before decommissioning is to 'clean up' by dropping the objects and hoping the record disappears. Redress Compliance calls this 'the worst of both worlds': dropping objects clears your evidence that the feature was never really deployed, while the row that generates the claim stays exactly where it was. Do not sanitize the database before you have captured the full feature-usage output and had it reviewed. Extract DBA_FEATURE_USAGE_STATISTICS to a preserved file first, then plan the decommission with that evidence in hand. If you are still scoping which packs are exposed, the Cloud Management Pack breakdown shows how a self-enabling pack becomes an audit line.

Deleting objects before you decommission destroys your defense and preserves Oracle's claim. Capture the feature-usage record first.

Reclaim and reallocation mechanics during the parallel run

You almost never need to buy net-new entitlement to run both environments during cutover. Several buyer-side mechanics bridge the gap:

• Shelf licenses. House of Brick: 'Shelf licenses are unused entitlements you already own. You can apply them to the new environment during migration, then reassign old licenses once decommissioned.' Inventory your unused entitlement before you assume you are short.
• The shuffle game. Cintra (March 2025) describes reallocating existing licenses by consolidating running infrastructure, for example temporarily removing a RAC node or decommissioning a physical host in a VMware cluster to free processor entitlement for the target.
• NUP bridging. When the target starts with few users, House of Brick suggests licensing it on Named User Plus rather than Processor 'until the old environment license can be reassigned.' This can cost a fraction of a processor buy for the overlap window.
• DR and non-production licenses. Before you reuse them, House of Brick warns to 'double check your contract to ensure that they are full use licenses,' because non-production and DR entitlements are commonly tied to a specific environment and cannot legally cross over.

Expect scrutiny during exactly this window. Version 1: 'Oracle may examine your estate during this parallel running period to ensure that you do not breach your license entitlement.' Treat the parallel run as a monitored period. Keep a running reconciliation of what is deployed where and against which entitlement, dated. The dual-running guide covers the double-payment exposure in more detail, and the migration path you chose (covered in rehost, replatform, or refactor) changes how much overlap entitlement you actually need.

The sequencing table: what happens when

Note the deliberate ordering: validation before teardown, teardown before reclaim, reclaim before any support action. Newt Global (March 2026) frames the cutover discipline correctly: 'Execute a phased cutover, application by application, with rollback capability. Only after each application is validated in production should the corresponding Oracle license and support be formally wound down.' Do not compress these stages to hit a project date. A skipped validation that forces a rollback into a torn-down environment is far more expensive than a two-week delay.

Decommissioning does not automatically cut your support bill

This is the point most migration business cases get wrong. Removing binaries frees the license for reuse, but it does not, by itself, reduce your annual support. Redress Compliance (August 2026): 'Oracle technical support is charged at 22 percent of the net license fees on the ordering document. It is not a usage fee and it does not fall when deployment falls.' You can decommission every source server and still pay the same support invoice next year unless you take a separate, deliberate contractual step.

That step runs into Matching Service Levels. Per Oracle's Software Technical Support Policies, quoted by Support Revolution (September 2025): 'You may not support a subset of licences within a license set; the license set must be reduced by terminating any unsupported licences.' You cannot simply stop paying support on the freed portion. And when you do terminate a subset, repricing bites. AMIS Technology quotes the policy: remaining licenses on that order get repriced 'at Oracle's list price for support in effect at the time of termination or reduction minus the applicable standard discount,' which frequently means a much smaller effective discount than the one you originally negotiated.

The magnitude is real. Redress Compliance: 'Naive partial cancellations triggered repricing that erased 60 to 90 percent of the intended saving. License set restructuring, where Oracle agreed to it, unlocked partial termination worth 15 to 30 percent of the support base.' The difference between those two outcomes is entirely a matter of how the license set is structured and sequenced before you notify Oracle. See how this played out in practice in the Costco support optimization case and the LVMH case.

Decommissioning frees the license. It does not cut support. Matching Service Levels and repricing can erase 60 to 90 percent of the savings you assumed.

Timing the support decision: start at 270 days, not 90

Support cannot be terminated mid-term. You must wait for the renewal window, and written notice is required 30 days before renewal (some contracts require 45 or 60). But the notice window is not when the work happens; it is the deadline. Redress Compliance: 'Engagements that started inside 90 days of renewal captured far less than those that started at 270 days.' Restructuring a license set into terminable units, and getting Oracle to agree to it, takes months of negotiation. If you begin when the renewal invoice arrives, you have already lost your leverage.

One final warning: once you drop support on a subset and terminate those licenses, you lose the right to use them. There is no reactivation without repurchase at current list. So the sequence must be: migrate, validate, remove binaries, confirm the freed licenses are genuinely surplus (not needed for the target, DR, or a future workload), restructure the license set, then terminate at the renewal window. Skip a step and you either pay twice or lose entitlement you will pay full price to recover. Before you sign anything, run the pre-migration review described in the license review to run before the SOW.

What the reader should do

• Fix a decommission date at project start, tied to first month-end reconciliation, and separate rollback preservation (cold images with no installed binaries) from license reclaim.
• Capture DBA_FEATURE_USAGE_STATISTICS from every source database and preserve it before any object cleanup or teardown.
• Inventory shelf, DR, and non-production entitlement and confirm which licenses are full-use before reallocating any of them to the target.
• Maintain a dated, daily reconciliation across both environments during the parallel run, and prepare for an Oracle approach.
• Confirm reclaim only after binary removal, not shutdown, on every host.
• Start the support-reduction workstream 270 days before renewal, restructure the license set before you notify, and never terminate a subset until you have confirmed it is genuinely surplus.

Related advisory: the full topic guide.

Frequently asked questions

When can I actually reclaim an Oracle source license after migration?

Only after you have removed the Oracle binaries from every host in the source environment. Powering off or stopping the instance does not qualify, because Oracle's liability trigger is 'installed and/or running.' Until the ORACLE_HOME is gone, you own the license and the support obligation for that deployment.

Does decommissioning reduce my Oracle support bill?

No, not automatically. Support is charged at 22 percent of the net license fees on the order and does not fall when deployment falls. To reduce it you must terminate licenses within a license set, and Matching Service Levels plus repricing rules can erase 60 to 90 percent of the intended saving if you sequence it badly.

What is the installed-not-used trap?

It is the gap between what you use and what you are liable for. Oracle requires a license once software is installed, regardless of whether it is actively running. During a migration, a source environment left installed 'just in case' remains fully licensable and fully supported for every day it sits there.

Why does deleting objects before decommissioning make things worse?

The DBA_FEATURE_USAGE_STATISTICS view records feature usage permanently. Dropping objects clears your evidence that a feature was never really deployed, but leaves the row that generates Oracle's per-processor claim intact. You lose your defense and keep the liability. Capture the feature-usage record first.

How early should I start the support-reduction process?

Around 270 days before your support renewal date. Restructuring a license set so it can be partially terminated, and getting Oracle to agree, takes months. Written notice is due 30 to 60 days before renewal depending on your contract, but starting inside 90 days of renewal captures far less value.

Can I run both environments during cutover without buying new licenses?

Usually yes. You can bridge the parallel run with shelf (unused) licenses you already own, license the target on Named User Plus while it has few users, or shuffle entitlement by consolidating existing infrastructure. Check that any DR or non-production licenses are full-use before reallocating them.