Buyer Side Briefing

Decommissioning modules properly

Decommissioning Oracle modules properly means an evidenced shutdown, because a module that is still installed and capable of running stays licensable even after the business stops using it. The buyer move is to remove the software, disable access, and keep dated records of when each module last ran, so an audit counts only what was genuinely live.

When does an Oracle module stop being licensable?

An Oracle module stops being licensable when it is genuinely shut down and removed from use, not at the moment the business decides to retire it. The distinction matters because Oracle's auditors look at what is installed and capable of running, not at the intentions on a project plan. A module that a department considers dead, but that still sits installed on a server and could be started, can be counted as deployed in an audit. The licensing liability follows the software's presence and capability, not the calendar date a decision was minuted.

This is why a clean decommission is a specific technical act rather than a status change. The module has to be taken out of service in a way that is real and provable: removed from the servers where it ran, with access disabled and the database objects or schemas it depended on addressed. Until that happens, a module the business stopped using months ago is still, in audit terms, a live deployment. The gap between the business decision and the technical shutdown is exactly where avoidable exposure lives.

Does turning off a module reduce the support bill?

Turning off a module does not reduce the support bill by itself, because matching service level rules constrain how an Oracle support agreement can be partially terminated. Oracle support is typically sold across a set of licenses as a single stream, and the matching service level terms are designed to prevent a buyer dropping support on part of that set while keeping it on the rest at a lower blended cost. A decommission removes the technical liability for using the module, but the support line attached to its licenses does not fall away automatically.

This means the support consequence of a decommission has to be planned and negotiated within the rules rather than assumed. A buyer who shuts down a module expecting the next support renewal to drop proportionally can be surprised when the matching service level terms hold the figure up. The right approach is to treat the support question as part of the decommission project, understand how the matching service level rules apply to the specific agreement, and negotiate the support position deliberately. Support runs at roughly 22 percent of license value with annual escalation, so the stakes in getting this right are not small.

Indicative decommission steps. Anonymized and contract dependent.
StepPurposeEvidence held
Remove software from serversEnds capability to runUninstall records, dates
Disable user accessEnds live useAccess logs, change tickets
Address database and optionsStops hidden licensingConfig and option state
Plan the support positionManages the 22 percentRenewal and negotiation notes

What evidence proves a module was decommissioned?

The evidence that proves a module was decommissioned is a dated trail showing the shutdown, the removal from servers, the disabling of access and the date the module last ran. This trail is what converts a claim that a module was retired into a fact an auditor cannot easily dispute. Uninstall records, change tickets, access logs and configuration snapshots together establish that the software was not merely intended to be gone but was actually removed and out of use during the audited period. Without that trail, a retired module can be counted as if it were still live.

Holding this evidence also protects against the related options trap. Many Oracle options install by default, and a module that is decommissioned without addressing the database beneath it can leave options enabled and discoverable. The decommission evidence should therefore extend to the database and its options, recording that what supported the module has been cleaned up too. A line by line review of an audit finding will rest on exactly this kind of contemporaneous record, and an independent review of findings typically cuts claims by 60 to 80 percent when the evidence is in place. If you are retiring Oracle modules and want the decommission and the resulting position costed properly, a quote is the place to start.

The next step

This article is part of our EBS and Applications cluster. Read the pillar, the Oracle license compliance guide, for the full picture, and these related reads: EBS module licensing and scope, and custom code and EBS compliance.

Next step

Get a Quote

FAQ

Questions buyers ask first.

An Oracle module stops being licensable when it is genuinely shut down and removed from use, not when the business decides to retire it. As long as the software is installed and capable of running, an audit can treat it as deployed.
Not by itself. Matching service level rules constrain partial termination of an Oracle support agreement, so reducing support after a decommission has to be negotiated within those rules rather than assumed.
Dated records of the shutdown, removal from servers, disabled access and the date the module last ran. That evidence proves the module was not in use during the audited period, which is what limits the count.
The License Position

Read Oracle's next move before they make it.

A short weekly note on Oracle audits, Java, ULAs and negotiation, written for the buyer. One development, why it matters, and one move you can make this week.

No spam. Unsubscribe anytime.