A retirement programme will switch off 23 of 140 applications this year. Eleven of them sit on an Oracle Database Enterprise Edition estate licensed by the Processor metric - 4 servers of 32 physical Intel cores each. The business case claims the retirements save 11/140 of the database licence and support cost. Estimate what is actually saved in year one and say which number should drive the retirement order.

The assumptions, stated

• The licence unit is cores, not applications. Oracle's published Database Licensing document states that under the Processor metric the licences required are the total cores multiplied by the core factor from the Processor Core Factor Table, aggregated and with fractions rounded up. Intel and AMD server cores are commonly listed at a factor of 0.5 - check the current table for the exact processor.
• Support renews on the quantity held, annually, at a percentage of licence value, so a reduction lands only at a renewal boundary and only if the agreement permits it.
• Workload does not equal footprint. Eleven applications leaving frees CPU and storage; it frees a licence only if it frees a server.

The arithmetic

Licensed quantity today: 4 servers × 32 cores = 128 cores; 128 × 0.5 = 64 Processor licences. Note that Oracle's own worked example in that document is instructive about the rounding — 6 cores at a 0.25 core factor is 1.5, which rounds up to 2 — so fractional reductions book nothing.

The business case's claim: 11/140 = 7.9% of the licence and support line. The actual saving depends entirely on bin packing:

• If the 11 databases are spread across all 4 servers, nothing is freed. Year-one saving: zero, beyond a little storage and backup volume.
• If consolidating the remaining load onto 3 servers is feasible, the licensed quantity falls to 96 × 0.5 = 48 licences, a 25% reduction — three times the claim, and available only at renewal and only if partial termination is permitted by the agreement. Check that clause before writing the number down.
• If the 11 sit on one server and it can be switched off, the same 25% applies without any consolidation work, which is the cheapest 25% in the programme.

Which assumption dominates the error

Whether whole servers can be vacated. It swings the answer from 0% to 25% and it is a scheduling question, not a portfolio question. The second-largest is contractual: whether support can be reduced on partial termination, which is a clause to read rather than an estimate to make. Everything else — storage, DBA effort at roughly 2 to 5 days per retired schema, monitoring noise — is rounding error.

What the number rules in and out

It rules out sequencing retirements by business value alone, which is how most programmes order them. Sequence by licence boundary: retire every application on one licensed server first, even the ones with more remaining value, because that is the only sequence that books a saving this year. One server fully vacated beats eleven applications half-vacated across four.

It also rules out presenting a licence saving without a renewal date: a saving unrealisable until month 19 is a different business case from one landing this year.

When this is the wrong answer

When the estate is on consumption-priced cloud services, the pro-rata logic mostly holds: switching off a managed instance stops the meter in hours and there is no rounding to a licence unit. The licence-boundary rule applies wherever the cost unit is coarser than the thing being retired — perpetual per-core licences, per-socket agreements, fixed-term hardware leases, minimum-commitment support contracts. Where the unit is an hour of compute, retire in value order.

Common weak answers

• Pro-rating by application count. It implies every application consumes cost in proportion to its existence, which is true of none of the coarse-grained cost units in an enterprise estate.
• Counting the saving at switch-off. Cost stops at the renewal or the decommission of the licensed host, not on the day the users leave.
• Ignoring what must keep running. An application switched off whose schema is still read by a report keeps the server alive and the licence with it.