Perpetual Licence Inventory Management: Complete Enterprise Guide

Perpetual licences are the silent liability in most enterprise Microsoft estates. Unlike subscriptions that expire and disappear from the entitlement register, perpetual licences accumulate over years — creating an inventory that is rarely audited, often poorly documented, and consistently undervalued as a financial asset and negotiation lever. The 5,000-user organisation that has been buying Microsoft products since 2008 is sitting on a perpetual licence estate worth $2M–$8M in replacement value. That estate is also carrying $400K–$1.2M in compliance risk from misallocated or undocumented assignments. This guide gives you the framework to take control of both.

The Perpetual Licence Landscape in 2026

Many IT leaders assume perpetual licences are a legacy concern — something relevant only to organisations still running Windows Server 2012 on-premises. This is wrong on two counts. First, most enterprise organisations still run significant perpetual licence volumes: SQL Server, Windows Server, Exchange, and SharePoint on-premises deployments remain common at scale, particularly in regulated industries where cloud migration timelines are 5–10 years. Second, perpetual licences with active SA are the source of Azure Hybrid Benefit entitlement — making them a current, high-value Azure cost management tool even in cloud-first organisations.

Perpetual Licence Categories in a Typical Enterprise Estate

Category	Source	Management Complexity	Common Issues
Volume perpetual (EA/Open)	VLSC	Medium — centralised in VLSC but version tracking required	SA expiry not tracked; version coverage gaps
OEM perpetual	Hardware COA / OEM records	High — tied to hardware, no central registry	COA lost; hardware decommissioned without licence documentation
Pre-EA Open Value perpetual	Historic VLSC / paper records	Very high — may predate electronic records	Agreement numbers lost; contact chain broken
SPLA-acquired perpetual (rare)	Distributor records	High — not in VLSC	Not transferable; often misclassified as standard perpetual
Academic/Charity perpetual	Separate VLSC agreements	Medium — separate programme constraints	Commercial use restriction violations; transfer restrictions

Building the Perpetual Licence Inventory

A complete perpetual licence inventory has three components: the entitlement record (what you purchased), the deployment record (where it is deployed), and the version coverage record (what versions the licence covers). Most organisations have acceptable entitlement records in VLSC but weak deployment records and almost no version coverage tracking.

Step 1: VLSC Entitlement Extraction

Begin with a full VLSC export of all perpetual licences across all linked agreements. Navigate to VLSC > Licences > Licence Summary and select "All Licence Types." Export in XML format for SAM tool import, or Excel for manual review. The export should show: product name, licence type (perpetual, SA, perpetual SA), quantity, purchase date, agreement number, and version entitlement.

Cross-reference the VLSC export against your internal purchase order records for the past 10 years. Any discrepancy — products in PO records not appearing in VLSC, or vice versa — indicates either an unlinked agreement (check VLSC Manage Agreements) or an administrative error that needs resolution before an audit. For the detailed VLSC navigation guide, see the VLSC administration guide.

Step 2: OEM Licence Inventory

OEM licences are the most difficult to inventory because they are physical — attached to hardware via Certificates of Authenticity (COAs) or embedded in BIOS/UEFI (particularly Windows OEM). For active hardware in the estate, use PowerShell to query the Windows licence key embedded in BIOS: Get-WmiObject -query 'select * from SoftwareLicensingService' will return the OEM product key for Windows on each machine.

For decommissioned hardware, OEM licences that were not documented before decommission are effectively lost — the COA goes with the hardware, and without the hardware (or proof of hardware permanent failure), the OEM licence cannot be proven to exist. This makes hardware decommission documentation a critical licence management activity that most organisations treat as purely a hardware task.

Step 3: Version Coverage Mapping

Every perpetual licence covers specific product versions. For licences with active SA, the version coverage extends to the current version. For licences with lapsed SA, the version coverage is frozen at the version current at the time SA lapsed. This distinction matters enormously for SQL Server: an organisation running SQL Server 2019 under a licence whose SA lapsed in 2020 (when SQL Server 2019 was the current version) is compliant. An organisation running SQL Server 2022 under the same lapsed-SA licence is non-compliant — SQL Server 2022 was released in 2022, after SA lapsed.

Build a version coverage matrix for all perpetual licences: product, licence version entitlement at purchase, SA expiry date, version at SA expiry, and current deployment version. Any deployment version newer than the version at SA expiry is a compliance gap. For the full version entitlement rules, see the product use rights interpretation guide.

Software Assurance Expiry Management

The single most commercially damaging event in perpetual licence management is allowing SA to lapse unknowingly. SA reinstatement after lapse is possible but carries a penalty: typically 100% of the annual SA cost for each year SA was not maintained, plus the current SA renewal cost. For large SQL Server estates, SA reinstatement penalties can reach $500,000–$2,000,000.

SA Expiry Tracking System

Build a rolling 18-month forward view of all SA expiry dates across the entire perpetual licence estate. The 18-month horizon is critical because EA renewal negotiations for large perpetual licence estates take 6–12 months, and you need the SA expiry timeline to inform which products must be renewed under which commercial vehicle.

The SA expiry calendar should trigger three review events per product:

• 18 months before expiry: Commercial review — should SA be renewed, allowed to lapse, or the on-premises product migrated to cloud subscription? This is a strategic decision requiring input from IT, finance, and procurement.
• 6 months before expiry: Renewal execution — if SA is being renewed, this is the latest point at which to commence negotiation without time pressure. See the EA negotiation advanced guide for renewal tactics.
• 3 months before expiry: Final confirmation — if SA is lapsing intentionally, document the decision and confirm the version coverage freeze date for the inventory record.

Perpetual Licence Inventory as Azure Cost Optimisation

For organisations with active SA on Windows Server and SQL Server, the perpetual licence inventory is directly linked to Azure spending. Azure Hybrid Benefit allows SA-covered licences to be applied to Azure VMs, eliminating the Windows or SQL OS component of Azure VM pricing.

Perpetual Licence Type	AHUB Benefit in Azure	SA Requirement	Typical Annual Saving per Licence
Windows Server Standard (2-core pack)	Cover 2 Azure VMs of same/lesser edition (Windows cost)	Active SA required	$2,800–$4,200/year (D-series VMs)
Windows Server Datacenter (2-core pack)	Cover unlimited Azure VMs of any edition (Windows cost)	Active SA required	$8,000–$25,000+/year depending on VM count
SQL Server Standard (per-core)	Cover 1 Azure SQL vCore (or SQL VM standard)	Active SA required	$3,500–$5,200/year per vCore
SQL Server Enterprise (per-core)	Cover 4 Azure SQL vCores or 1 SQL VM (Enterprise)	Active SA required	$14,000–$22,000/year per licence

An organisation with 200 Windows Server Datacenter 16-core licences (100 2-core packs) with active SA, deploying 300 Azure VMs, can cover all 300 Azure VMs with AHUB — saving $840,000–$1,260,000/year in Azure VM costs. This makes SA renewal on Windows Server Datacenter licences a straightforward financial calculation: if the Azure saving exceeds the SA renewal cost, renew SA regardless of on-premises deployment plans.

Perpetual Licence Disposition Planning

Perpetual licences reach end-of-useful-life in four scenarios: the product is migrated to a cloud equivalent, the hardware carrying an OEM licence is decommissioned, the business function requiring the licence is discontinued, or the licence version becomes too old to meet security or compatibility requirements. Each scenario requires specific documentation actions.

Disposal Documentation Checklist

• Record the last deployment date and decommission date in the inventory system
• Confirm uninstallation from all devices/servers (for OEM, confirm hardware destruction or secure disposal)
• Retain the entitlement record (VLSC export) for 5 years post-last-deployment
• For perpetual licences with SA at disposal: consider whether cloud equivalents can use AHUB before fully retiring the licence
• Update the SAM platform to remove the licence from active reconciliation while retaining it in historic records

For the complete reconciliation framework that incorporates perpetual licence lifecycle management, see the licence reconciliation automation guide. For the SAM programme governance that ties all perpetual inventory management together, see the SAM programme implementation guide.

Frequently Asked Questions

Do Microsoft perpetual licences expire?

No — perpetual licences do not expire. You retain the right to use the specific version licensed forever. What expires is Software Assurance (SA), which provides upgrade rights and other benefits. When SA expires, your right to run the specific version you were entitled to at SA expiry remains permanent.

How do I prove I own perpetual licences if I've lost the original documentation?

VLSC is the authoritative record for volume-licensed perpetual licences. Export the licence summary from VLSC — this serves as proof of entitlement in an audit. For OEM licences, the COA attached to the hardware is the primary proof. If the COA is missing, recovery options are limited.

Can perpetual licences be used after SA expires?

Yes — perpetual licences can be used indefinitely after SA expires. You retain the right to run the version covered at SA expiry. You lose upgrade rights to newer versions, licence mobility rights, and SA benefit access. You retain the right to run the version and downgrade rights to earlier versions.

What is the difference between perpetual and subscription licensing for inventory management?

Perpetual licences are permanent assets requiring long-term tracking — indefinitely, including through technology refreshes, M&A activity, and organisational changes. Subscription licences expire with the subscription period and are administratively simpler. The inventory challenge with perpetual licences is maintaining accurate records over a multi-decade horizon.

How should we manage perpetual licences during a cloud migration?

Track perpetual licences in three states: Active (still needed on-premises), Surplus (workload migrated, licence no longer needed on-premises), and AHUB-eligible (licence has active SA that can be applied as Azure Hybrid Benefit). Surplus licences with SA can be monetised as AHUB credits against Azure VM costs.

Can we sell or donate our unused perpetual Microsoft licences?

Volume licences (EA, Open, Select) generally cannot be resold to third parties — Microsoft's licensing terms prohibit resale outside specific M&A transfer scenarios. OEM licences transfer only with hardware. Unused perpetual licences should be retained as negotiation leverage or documented as available for future internal deployment.