In the deployments I supported through the first half of 2026, the pattern repeated itself. A team schedules the Windows Server 2025 upgrade, validates the hardware, tests the applications, and only then opens the licensing spreadsheet. By that point, the edition choice is already locked in, and the true-up conversation starts six months later when someone notices the VM count has climbed.

Windows Server 2025 did not reinvent the core-based model. It still requires a minimum of eight core licenses per physical processor and sixteen core licenses per physical server. What changed is the practical weight of the decisions that sit on top of those minimums: how you count virtualization density, whether Software Assurance is still worth carrying, and how Azure Hybrid Benefit actually gets applied once the hosts are running the new release.

The single largest underestimated friction remains the gap between “we have the cores covered” and “we have the rights that match the density and hybrid model we actually run.” Everything that follows is written from the side of that gap.

Core Licensing Still Starts With the Hardware

Open the server inventory and look at every physical host. Count the sockets and the active physical cores. A dual-socket system with two 12-core processors needs 24 core licenses. A single-socket 8-core box still needs 16. There is no exception for disabled cores or hyper-threading; the license count follows the physical cores present in the hardware.

Licenses come in 2-core and 16-core packs. Most organizations buy the 16-core packs for the base coverage and then fill the remainder with 2-core packs. When you license the physical cores of a host under Standard, you receive rights to two operating system environments or two Hyper-V isolated containers, plus unlimited Windows Server containers that use process isolation. The physical instance itself can run solely as the Hyper-V host. Datacenter removes the limit: once the physical cores are fully licensed, you can run any number of OSEs and containers.

That difference looks simple on paper. In practice it is the first place the cost model breaks.

Standard Stacking Versus Datacenter Reality

Standard stacking is allowed. Every additional pair of VMs requires another complete set of core licenses for the host. On a 16-core host, the first two VMs are covered by one Standard pack. The next two require a second full pack. Six VMs require three packs. Twelve VMs require six packs. At that point, the list price of the stacked Standard licenses already exceeds a single Datacenter pack, and the administrative overhead of tracking the stacks is higher.

I still see environments that start with one Standard pack per host because the initial VM count is low. Over the following year, the application teams request more VMs. The licensing team is not in the change-control meeting. The true-up arrives after the upgrade is complete and the budget has already been spent on the OS media and the labor.

Run the density projection for the next 24 months before you choose the edition. Include Hyper-V isolated containers in the count; they consume the same OSE rights as full VMs. Process-isolated Windows Server containers do not, but most mixed workloads use both.

Per-VM Licensing and the Software Assurance Gate

If the licenses carry active Software Assurance or are subscription licenses, you gain the option to license by virtual machine instead of by physical core. Each VM is assigned core licenses equal to its configured virtual cores, subject to a minimum of eight cores per VM. This path is useful when Windows Server VMs sit sparsely on large shared hosts or when you place workloads with Authorized Outsourcers under the Flexible Virtualization Benefit.

Without Software Assurance or a subscription, the per-VM option disappears. That single requirement still catches buyers who dropped SA during the previous renewal cycle and then discover they cannot use the more flexible model after the upgrade.

Azure Hybrid Benefit and Dual-Use Rights

Azure Hybrid Benefit remains the largest single cost lever for hybrid environments. Qualifying core licenses (Standard or Datacenter with active Software Assurance or subscription) can be applied to Azure VMs so that you pay only the base compute rate.

Standard licenses generally force a choice: use the license on-premises or in Azure, with a 180-day overlap window during migration. Datacenter licenses with Software Assurance allow simultaneous dual use. The core allocation rule is straightforward but frequently misapplied: a minimum of eight cores must be assigned to each Azure VM even if the VM itself has fewer virtual cores. A 16-core on-premises entitlement can cover two 8-core Azure VMs or one 16-core VM.

In the hybrid deployments I walked through in early 2026, the most common error was applying the benefit to the wrong edition or forgetting to toggle it on the specific Azure resources. Azure does not apply the discount automatically. Unclaimed entitlements simply sit unused while the full Windows rate is charged.

Pay-as-You-Go Through Azure Arc

Windows Server 2025 added a pay-as-you-go path via Azure Arc. Once a server is Arc-connected, you can enable usage-based billing instead of perpetual licensing. Microsoft charges a published per-core monthly rate that covers the Windows Server software component. Traditional Windows Server CALs are not required under this model (RDS CALs still are). The feature set available follows the edition you select for the instance.

PAYG works well for burst capacity, short-lived test environments, or workloads whose core count fluctuates. It does not replace the need to license the steady-state perpetual estate correctly. It simply gives you another tool when the perpetual model would leave cores idle for long stretches.

KMS Hosts and the Coming TPM Requirement

Windows Server 2025 KMS hosts begin showing readiness messages in August 2026 for the upcoming hardware-attestation change. TPM attestation will become mandatory for KMS Hardware-Secured activation in a later Long-Term Servicing Channel release. Physical hosts need a TPM that meets the requirements and must be listed in the Windows Server Catalog. Guidance for virtualized KMS hosts is still incomplete as of July 2026.

This change does not affect MAK or retail activation. It does affect any organization that still relies on a traditional KMS infrastructure. Inventory those hosts now, confirm TPM status, and decide whether the KMS role needs to move to hardware that already meets the future requirement.

Concrete Planning Steps Before the Upgrade

1. Export the current physical host inventory with socket count, core count, and installed edition.
2. Count existing virtual OSEs and Hyper-V isolated containers per host. Project the count 24 months forward based on known application roadmaps.
3. Calculate the Standard stacking cost for that projected density against the cost of a single Datacenter pack on the same host.
4. Confirm whether active Software Assurance or subscription licenses exist. If they do not, model the Hybrid Benefit and per-VM rights against the cost of adding SA.
5. Map any current or planned Azure or Authorized Outsourcer workloads and apply the eight-core minimum allocation rules.
6. Identify any capacity that is better suited to Azure Arc PAYG.
7. List every KMS host and check its TPM readiness.
8. Verify that the CAL pool matches or exceeds the highest Windows Server version that will be present after the upgrade.

DirectDeals operates as a Trusted Site for genuine Windows Server 2025 core licenses, additional core packs, and the related CALs. Once the density and hybrid numbers are clear, the right mix of Standard, Datacenter, and Software Assurance can be sourced without introducing gray-market risk that later appears in activation or audit.

The OS upgrade path itself is well documented. The licensing math that surrounds it is where the real work sits. Run the density projection and the Hybrid Benefit allocation before the first media is mounted, and the majority of the post-upgrade cost surprises disappear.