Pillar Guide · Knowledge Hub

Enterprise Licence Optimisation: The Rules That Cost You Most, by Vendor and by Environment

The published rules that decide what you owe Oracle, Microsoft, VMware and IBM across production, DR and every non-production tier, and where the recoverable spend actually sits.

Licence Optimisation Updated 2026-08-10 3232 words · about 15 min read

Almost nobody is non-compliant on purpose, and almost nobody overpays on purpose either. Both happen for the same reason: the counting rules are not the rules a competent engineer would guess, they differ sharply between vendors, and several of them changed after the architecture was designed.

This is the working reference. Every rule below is the vendor's published position, cited, and checked on 10 August 2026. Your signed agreement governs and may contain negotiated terms that override any of it, which is exactly why the agreement has to be read rather than assumed.

The single most expensive assumption in enterprise licensing#

That vendors treat non-production and DR the same way. They do not, and the spread is enormous.

Non-production (dev, test, UAT, SIT, QA)Passive DR / standby
Microsoft SQL ServerFree. Developer Edition, full Enterprise feature set, unlimited installationsFree with Software Assurance. HA, DR, and DR in Azure
Oracle DatabaseGenerally licensable, same metric as production, including options and packsTen separate days a year, clustered with shared storage, one node. A Data Guard standby is not covered
IBM (PVU)LicensableCold: free. Warm: 100 PVUs. Hot: full rating
VMware (Broadcom)LicensableNo relief, and the 72-core minimum applies again

A team that learned licensing on Microsoft and then designs an Oracle DR topology will be wrong by a large number. A team that learned it on Oracle and never turns on SQL Server Developer Edition will overpay for years without ever being non-compliant.

Microsoft: the most generous rules, the most under-used#

This is usually the single largest recoverable line in a Microsoft estate, and it is routinely missed because it sounds too good to be true.

Developer Edition is free, has the same feature set as Enterprise, and permits unlimited installations to design, develop, test and demonstrate. It receives updates and patches. What it does not include is production use or a production support agreement.

Every dev, test, UAT, SIT, QA and training instance running Standard or Enterprise is therefore a licence you are buying for something Microsoft gives away.

Two cautions, both of which have caught people:

  • "Non-production" means non-production. A UAT environment that real users depend on for real work is production, whatever the folder is called. If it is in the critical path for a business process, licence it.
  • Performance testing you intend to rely on should match production edition and configuration. Developer Edition has Enterprise features, so it is usually fine, but validate before you move a performance-critical rig.

Failover rights: passive is free, and reading from it is not#

With active Software Assurance, SQL Server grants three failover benefits: failover servers for high availability, failover servers for disaster recovery, and failover servers for DR in Azure. The passive replica needs no additional licence.

The condition is that passive means passive. Permitted: synchronisation, health checks, and periodic DR testing. Not permitted: reporting, analytics, or taking production backups from the secondary.

The most common way this benefit is lost is a well-meaning DBA offloading reporting onto an idle machine, which converts a free replica into a fully licensable instance without anyone raising a change request.

Note also what SA lapsing does. Dropping Software Assurance is usually taken as a pure cost saving; it is also a decision to start licensing your entire DR tier. Those two facts frequently sit with different budget holders.

The minimums that charge you for cores you do not own#

Windows Server 2025 requires at least 8 core licences per physical processor and at least 16 per server. SQL Server requires at least 4 core licences per physical processor and at least 4 per virtual OSE.

Both floors punish small machines. Four SQL VMs at 2 vCPUs each cost 16 core licences; one VM at 8 vCPUs costs 8 and gives every workload more headroom. Small, sprawling SQL estates are the most reliably over-licensed thing in enterprise IT, and the fix is consolidation rather than negotiation.

Windows Server: the break-even between Standard and Datacenter is 11 VMs#

Standard grants two OSEs per fully licensed server. To run more, you relicense the entire server again for each additional pair, which the terms call stacking. Datacenter grants unlimited virtualisation and needs no stacking.

Microsoft's published suggested MSRP is $1,176 for Standard and $6,771 for Datacenter, per 16-core pack. That makes the break-even calculable rather than a matter of opinion:

Datacenter is cheaper when ceil(VMs / 2) x 1,176 > 6,771, which is from 6 stacks upward, which is 11 VMs.

Windows VMs per hostStandard stacksStandard at MSRPDatacenterCheaper
84$4,704$6,771Standard
105$5,880$6,771Standard
116$7,056$6,771Datacenter
147$8,232$6,771Datacenter

The figure usually quoted from memory is "about twelve". It is eleven, and the ratio holds at any core count because both editions scale per core identically. Above the break-even Datacenter also removes the stacking arithmetic from every future capacity change, which has a value of its own.

CALs, and the multiplexing rule that catches everyone#

Both editions require a CAL for every user or device that accesses the server, directly or indirectly. Indirect is the part that costs money: putting a web front end, an integration layer or a reporting tool in front of the server does not reduce the count. That is multiplexing, and it is the most commonly misunderstood clause in Microsoft licensing.

Choose the basis per population rather than for the organisation. Shift workers sharing terminals are cheaper on device CALs; staff with a laptop and a phone are cheaper on user CALs. You may mix. At scale, check whether a Core CAL or Enterprise CAL Suite beats buying the components separately, which it usually does.

Terminal Server: the RDS CAL is a second CAL, not an alternative#

Every user or device connecting through Remote Desktop Services needs an RDS CAL in addition to a Windows Server CAL. Organisations routinely buy one and not the other.

This surfaces at audit rather than at purchase, because RDS keeps working for 120 days without a licence server. By the time it stops, the estate has been non-compliant for a quarter.

Per-device suits shared machines across shifts; per-user suits dedicated devices. The CAL families can be mixed, so device CALs for Windows Server and user CALs for RDS is a perfectly valid combination if that is what your usage looks like.

Azure Hybrid Benefit, and the Standard versus Datacenter difference nobody prices#

If you own Windows Server or SQL Server licences with active Software Assurance, you can apply them to Azure VMs instead of paying the pay-as-you-go licence rate of $33.58 per core per month. Microsoft states the saving can reach 80% for Windows Server and 30% or more for SQL.

Three conditions decide whether it works:

  • Minimum 8 core licences per VM, even for a 4-core VM.
  • Standard edition licences cannot be used on-premises and in Azure at the same time, except once, for up to 180 days, while you migrate that workload.
  • Datacenter edition licences can be used in both places simultaneously and indefinitely.

That second and third point together are worth more than the price gap between the editions suggests, and they are almost never modelled at purchase. If a workload is genuinely moving, Standard is fine. If you are running hybrid indefinitely, Datacenter is the edition that permits it.

One coupling to diarise: the benefit runs only for the Software Assurance term. Letting SA lapse is therefore also a decision to start paying full Azure rates, and those two budgets usually sit with different people.

For SQL specifically, one Enterprise licence carries the same coverage as four Standard licences across Azure SQL resource types.

Microsoft 365: the most reliably recoverable money in any estate#

Published enterprise pricing, paid yearly: E3 $39, E5 $60 per user per month, with Copilot $30 on top.

The recurring waste is not the tier, it is the count. Licences assigned to leavers and never reclaimed, and licences bought for projects that did not happen. At E3, 220 idle licences is $102,960 a year; at E5, $158,400.

Two actions, in order. Reclaim what is unused from the admin centre usage reports. Then put licence removal into the leaver process, because otherwise it returns within a year.

Only after that is the tier worth arguing about. The gap between E3 and E5 is $21 per user per month, $252 a year each, and E5 buys security and compliance capability that is frequently duplicated by tools already being paid for separately. Counting that duplication is usually a bigger number than the negotiation.

The agreement itself is a lever#

The Enterprise Agreement structural minimum is 500 seats. Since 1 November 2025, organisations at roughly 2,400 seats or fewer can no longer renew an EA and move to CSP through a partner or MCA-E direct with Microsoft, which carries a reported $500,000 minimum annual commitment.

The mechanical difference that matters more than the headline discount:

  • An EA true-up only ever goes up. It adds licences mid-term and does not remove them. If headcount falls or a project is cancelled, you carry the cost to the end of the term.
  • CSP annual subscriptions can be trued down at each anniversary.

For an organisation with volatile headcount, that asymmetry is worth more than a few points of discount. A common structure is hybrid: stable organisation-wide commitments inside the EA, volatile or pilot products in CSP where they can be reduced.

These agreement figures come from Microsoft licensing advisories rather than a Microsoft page, so confirm them against your reseller before planning a renewal around them.

Oracle: the most restrictive, and the most misread#

The ten-day rule is narrower than almost anyone believes#

Oracle permits an unlicensed spare to run the programs for at most ten separate days in a calendar year. The conditions matter as much as the number:

  • Only in a clustered environment with shared storage.
  • Only one failover node per cluster, even if several standby nodes exist.
  • Days spent on DR testing and maintenance count against the ten.

That last point is the one that turns a compliant configuration into a non-compliant one quietly. A quarterly DR test plus a single real incident can exhaust the allowance in a year, and the burden of showing you stayed inside ten days is yours. Keep the record: date, reason, duration. Nobody does until an audit asks.

A Data Guard standby is not covered by it#

This is one of the most expensive single misreadings in the discipline.

The ten-day allowance applies to an idle spare. A physical or logical standby is mounted and applying redo, and is therefore, in Oracle's reading, installed and running. It must be fully licensed at the same edition, with the same options and packs, as the primary. Active Data Guard, where the standby is open read-only, is additionally a separately licensable option on top of that.

If your standby exists only for disaster recovery and is never read, an idle spare in a shared-storage failover cluster is the configuration the ten-day rule was actually written for. That redesign is worth pricing against the licences.

Capability, not usage, in a virtual estate#

Where an Oracle VM could run matters more than where it does. In a cluster with no enforced host affinity, Oracle's position is that every host the VM could move to is licensable. On an eight-host cluster running Oracle on two hosts, that is the difference between 32 and 128 processor licences at the x86 core factor of 0.5.

Pinning Oracle workloads to named hosts, enforcing it in the platform, and retaining the configuration and change history as evidence is the highest-return lever in most estates. It costs engineering time rather than money.

Non-production carries the options with it#

There is no Oracle equivalent of Developer Edition for a full-feature non-production estate. Worse, Diagnostics Pack and Tuning Pack get enabled in test environments by default and are separately licensable, which turns a test box into a licence event nobody authorised. Audit which options and packs are enabled outside production; it is a five-minute query and it finds things.

The core factor does not apply in the cloud#

On AWS, Azure and GCP, Oracle counts vCPUs and the Processor Core Factor Table does not apply. With hyperthreading on, two vCPUs equal one processor licence; with it off, one vCPU equals one.

Teams routinely apply the 0.5 x86 factor in cloud and under-license by half, because that is what the on-premises rule taught them. Note also that this vCPU rule lives in a policy document, not in your contract, so Oracle can revise it. Ask for written confirmation that later policy revisions do not change the counting for deployments made under your order.

IBM: graduated, and free at the cold end#

IBM's standby treatment is the most reasonable of the four and the least known:

  • Cold standby: no licence required, provided the program is not started. The practical test is whether the instance is running, not whether the machine is powered on.
  • Warm standby: 100 PVUs, regardless of processor type. A substantial reduction on the full rating.
  • Hot standby: the full PVU rating. In a mirroring or duplexing configuration the program is considered to be doing work.

If your recovery objective tolerates warm rather than hot, the difference is 100 PVUs against the entire rating of the machine. That is an architecture decision with a licence price attached, and it should be made with both in view.

The ILMT trap#

Sub-capacity licensing is conditional on IBM License Metric Tool being deployed and reporting. The terms are specific: ILMT within 90 days of first sub-capacity deployment, mandatory with no exceptions since 1 May 2023, reports analysed, reconciled and signed at least quarterly.

Fail any of that and the charge reverts to full capacity on every activated core in the server, regardless of how small the workload is. There is no grace period and no true-up.

ILMT is included with the entitlement you already hold. Deploying it is the cheapest compliance action available anywhere in this document. Install agents on standby machines too, so cold and warm instances can be positively excluded rather than assumed away.

VMware by Broadcom: the smallest estates are hit hardest#

Perpetual licences are gone; everything is subscription. The general minimum order is 72 cores, raised from 16 in 2025, and reported list runs roughly $350 to $400 per core per year with term discounts of 18 to 38%.

Two consequences most affected organisations have not modelled:

  • A cluster below 72 cores pays for capacity it cannot use. The economics of staying are worst exactly where the estate is smallest, which inverts the usual assumption that migration is a large-enterprise problem.
  • A DR site below 72 cores pays the minimum twice, once for production and once for DR, because there is no DR relief.

There is also a reported 20% uplift for renewing after the anniversary date. That one is avoidable by diarising a date.

The levers, in the order they usually pay#

  1. Switch non-production SQL Server to Developer Edition. Free, full Enterprise feature set, unlimited installations. Normally the largest single recoverable line in a Microsoft estate.
  2. Reclaim idle Microsoft 365 licences, then fix the leaver process. Pure waste, immediately recoverable, and it comes back within a year unless the process changes.
  3. Apply Azure Hybrid Benefit if you hold Windows Server or SQL licences with Software Assurance. A toggle in the portal, not a migration.
  4. Deploy ILMT if you hold IBM sub-capacity entitlements. Free with the entitlement you already own, and its absence converts sub-capacity into a full-capacity bill.
  5. Pin and evidence Oracle workloads. Engineering time rather than spend, and the largest single Oracle reduction available in most estates.
  6. Check what your DR replicas are actually doing. Reporting or production backups off a passive SQL secondary silently forfeits the free failover right.
  7. Check the Windows Server edition against VM density. The break-even is 11 VMs per host at MSRP, and estates drift across it in both directions without anyone re-checking.
  8. Buy the right CAL basis per population. Device CALs for shift workers, user CALs for people with several devices. You may mix, and most organisations pick one and apply it to everybody.
  9. Verify RDS CALs exist at all. They are required on top of Windows Server CALs and RDS runs for 120 days without a licence server, so absence is invisible until it is not.
  10. Audit options and packs in non-production Oracle. Diagnostics and Tuning Pack get switched on by default and are separately licensable.
  11. Consolidate small SQL VMs and small hosts. Both Microsoft floors punish sprawl, and consolidation usually shrinks the Oracle and VMware footprints at the same time.
  12. Take IBM standbys cold where the recovery objective allows. Hot to warm is 100 PVUs against a full rating; warm to cold is free.
  13. Right-size before renewal, not after. Every metric counts allocated capacity, so an over-provisioned VM is a licence bought for headroom nobody uses.
  14. Model per-employee metrics against the headcount plan. Oracle Java rises with hiring whether or not usage does, and partial migration under a per-employee metric saves nothing at all.
  15. Match the agreement vehicle to how volatile you are. An EA true-up only goes up; CSP annual subscriptions can be trued down at each anniversary.
  16. Price the exit while you still have leverage, which is before a renewal or an audit rather than during one.

What to gather before anyone can advise you properly#

A deployment inventory, the signed agreements including negotiated amendments, the virtualisation topology with its affinity rules, the options and packs enabled per environment, and the last two renewal quotes. Most of the answer is in those five things and none of it is in a datasheet.

Run the Licence Compliance and Optimisation Calculator to see which of these apply to your estate before you start gathering.

Method and limitations#

Every rule here is the vendor's published position as at 10 August 2026, cited below. Vendor policies change, and some of the most important ones, notably Oracle's cloud vCPU rule, sit in policy documents rather than in contracts, which means they can be revised unilaterally.

Prices are quoted only where a vendor publishes them. Microsoft list pricing varies by agreement and channel and is therefore not stated here at all rather than being approximated.

This is not legal or contractual advice. Your agreement governs, negotiated terms override published policy, and Oracle agreements in particular vary more than any other enterprise vendor's.

Sources#

What else is coming for Licence Optimisation

Pillar Guide Ready

The definitive explainer, start here.

Tutorials Not yet

Step-by-step, with working examples.

Best Practices Not yet

What holds up in production, and what quietly doesn't.

Checklists Not yet

Run through before you ship.

Sample Reports Not yet

What the output should look like.

Worked Examples Not yet

A real case, with numbers.

Diagrams Not yet

The architecture, drawn.

Downloads Not yet

Templates and starter files you can edit.

Videos Not yet

Walkthroughs.

FAQs Not yet

The questions people actually ask.