Veeam per instance or per socket counts different things

For 40 virtual machines, socket licensing often looks cheaper, but that comparison only makes sense for a company that already owns perpetual socket licenses with current support. Veeam no longer sells new perpetual socket licenses. For a new project, the practical choice starts with Veeam Universal License (VUL), not with two equal options on a price list.

The answer is different for an existing owner of four socket licenses. If 40 VMs run on two dual-socket VMware vSphere or Microsoft Hyper-V hosts and the estate grows within those same hosts, retaining the sockets and adding a few VULs for physical and cloud workloads can cost almost half as much as a full move to VUL. Cluster density, support dates, and cloud plans can change the result faster than the current VM count in an inventory.

The calculations below compare both models in Kazakhstani tenge over three years. The example prices are not presented as a public Veeam price list. They are demonstration rates that you should replace with numbers from a partner quote. This model is more useful than a price found online because the SKU, edition, term, payment schedule, discount, and VAT differ in a real proposal.

Sockets count hosts, not virtual machines

A socket license covers occupied CPU sockets on source hosts from which Veeam backs up or replicates VMs. Two hosts with two occupied sockets each consume four socket licenses. It makes no difference whether they run 20, 40, or 60 VMs, provided the hosts have enough capacity and every protected VM remains on those licensed hosts.

A replication target host does not require a socket license. The Veeam End User Software Licensing Policy and the Veeam Backup & Replication guide state this directly: one unit is consumed for each occupied motherboard socket on a source host, not on the replication target. In a cluster, account for every node on which a protected VM can run. Do not automatically treat a powered-off standby node whose hypervisor is registered in the infrastructure as free without checking the actual license assignment in the console.

Three limits often disappear from the rough formula of four sockets versus forty VMs.

• Sockets protect VMware vSphere and Microsoft Hyper-V VMs. Physical servers, cloud VMs, and most other workload types require VUL.
• When socket and VUL keys are installed together, you cannot cover some VMware or Hyper-V VMs with sockets and the rest with instances in the same centrally managed environment. All such VMs use the socket component.
• The socket edition determines the feature and support level of the combined environment. Adding VUL does not automatically upgrade an older edition.

Veeam has ended new sales of perpetual CPU socket licenses. The purchasing question of buying four new sockets or forty VULs is therefore no longer valid. For an existing customer, the socket case is an already purchased asset with future support and possible migration costs.

One VUL usually covers one workload

VUL measures protected workloads rather than the hardware underneath them. For an ordinary VM, physical server, or cloud VM, a base estimate assigns one instance to one workload, but you must check the exact ratio for the data type and edition against the current Licensing Policy before ordering. Workstations, unstructured data, and some products can follow different rules, so do not add all of them as though they were servers.

Instances are portable. You can revoke a released VUL from one supported workload and assign it to another regardless of workload type. That matters when an application moves from a local VM to the cloud. A socket license stops covering the object when the VM leaves the licensed host, while VUL follows the protected workload.

The console treats workloads processed during the previous 31 days as protected. Removing a VM from a job does not always reduce reported consumption immediately. You can manually revoke the license if the workload has truly left protection, or wait until the product releases it under its normal rules. Protected VM templates also consume instances. A backup copy or writing an existing backup to tape does not consume a second instance for the same VM.

VUL is sold for a fixed term and support is included in the subscription. Veeam's official FAQ lists terms from one to five years and annual payment under a three-year contract. Minimum order quantities depend on the offer and are usually 5 or 10 licenses. When the subscription and grace period end, functionality stops. Expiration of support for a perpetual socket license does not disable the installed functionality, but it prevents installation of updates released after the support date. I do not recommend saving money by leaving a working backup system without updates. That moves cost out of the quote and into operational risk.

The calculation needs a workload calendar, not just 40 VMs

Consider an organization that already owns four perpetual socket licenses and maintains two dual-socket hosts. The starting point of 40 VMs is not enough, so we need a transparent three-year plan.

Assume that all local VMs fit on the same four occupied sockets throughout the period. A capacity plan must confirm that assumption instead of the finance department merely hoping it is true. Also assume that each listed server workload consumes one VUL, the contract allows the quantity to change annually, and orders are rounded up to packs of 10. A real partner quote may offer a fixed three-year quantity, phased deliveries, or a different order increment.

Use two replaceable rates excluding VAT for the monetary example:

• KZT 70,000 for one VUL for one year;
• KZT 350,000 for one year of support on one previously purchased socket license.

Storage, repository servers, cloud traffic, immutable object storage, implementation, and administrator labor are excluded. They belong in the full backup TCO, but they do not help compare two licensing units at the same layer. Both proposals must provide the same required feature set. Otherwise, a price comparison quietly turns into a product comparison.

A full move to VUL costs KZT 13.3 million

Under a full migration, every local VM, physical server, and cloud VM enters the instance counter. After rounding to tens, the organization buys 50 VULs in year one, 60 in year two, and 80 in year three.

Instance-year is a calculation unit here: one paid workload for one year. It is not a separate Veeam licensing term. The unit lets us add three annual invoices without confusing the current estate size with cumulative spending.

If the commercial proposal allows payment for the exact instance count with no rounding, the result is 42 × 70,000 + 57 × 70,000 + 72 × 70,000 = KZT 11,970,000. The KZT 1,330,000 difference comes only from the assumed package boundaries. The purchasing worksheet should therefore have a separate order increment row rather than a hidden rounding function.

The full VUL model buys more than the right to protect the current 40 VMs. It pays for portability across local hypervisors, physical servers, and supported cloud workloads. If the company plans to move applications frequently, that option has a financial value. The company does not have to retain an old cluster for its license or manage two separate pools of entitlements.

Sockets with VUL cost KZT 7 million

In the mixed model, the four existing sockets cover 40, then 50, then 60 VMware or Hyper-V VMs. VUL is needed only for physical servers and cloud VMs. Actual requirements are 2, 7, and 12 instances, while rounded orders are 10, 10, and 20.

The saving against the full VUL model is KZT 6,300,000 over three years. Without package rounding, the mixed model would cost 4,200,000 + (2 + 7 + 12) × 70,000 = KZT 5,670,000. Exact purchasing benefits both models, so rounding does not change the winner in this example.

Older socket licenses may include up to six built-in gift instances, depending on the socket count. I do not subtract them from the planned purchase. The Veeam Backup & Replication guide warns that, starting with version 12, those instances are disabled when perpetual license support expires. A small free balance also does not cover our increase to 12 external workloads. Treat the gift as temporary headroom, not as the basis of a three-year budget.

This mixed design is not technically valid for every package combination. Veeam publishes a merge matrix, and the socket component determines the edition and support level in a centrally managed environment. Before signing, the partner should confirm in writing that the exact SKUs are compatible, the license owner matches, and the resulting feature set is correct.

The break-even point is more useful than a price list

You can calculate the break-even point before receiving the final discount. Let S be annual support for one socket and V be the annual price of one VUL. With exact consumption and no package rounding, the full VUL model uses 171V over three years. The mixed model uses 12S + 21V: four sockets for three years and 21 instance-years for physical and cloud servers.

The mixed model costs less when:

12S + 21V < 171V
12S < 150V
S < 12.5V

With our rates, S/V equals 350,000 / 70,000 = 5. It is well below the 12.5 threshold, so retaining the socket licenses wins. If annual support for one socket rises above the price of 12.5 VULs after an edition or service-level change, a full migration becomes cheaper even before assigning any value to portability.

For package orders, calculate invoice rows instead of relying on one ratio. A spreadsheet needs four inputs: protected VM counts by year, other workload counts, occupied sockets, and both prices. The formulas for a pack size of 10 are:

VUL_ALL_y = CEILING((VM_y + OTHER_y) / 10) * 10
VUL_HYBRID_y = CEILING(OTHER_y / 10) * 10
COST_ALL = SUM(VUL_ALL_y * V_y)
COST_HYBRID = SUM(SOCKETS_y * S_y + VUL_HYBRID_y * V_y)

Do not enter a three-year VUL package price as V and then multiply it by three again. That is the most common arithmetic failure in these estimates. First normalize both quotes to the same unit, such as KZT per license per year excluding VAT. Alternatively, model the actual payment dates and discount the cash flow using the company's internal rate.

Host growth can reverse the result

Our KZT 6.3 million advantage depends on four sockets. Sixty VMs may fit on them, or they may require a third dual-socket node because of CPU, memory, resilience, or maintenance-window requirements. Licensing cannot be selected independently from the cluster capacity plan.

If the third host arrives in year two, an owner of four socket entitlements needs rights for two more occupied sockets. New perpetual socket licenses are no longer sold as a normal expansion. You cannot take our KZT 350,000 support rate and draw two more sockets into the model, because support does not create the missing entitlement. The partner must quote an allowed route for the existing contract, and that route may require migration of the entire socket pool to VUL.

The reverse effect is possible too. Replacing two old dual-socket hosts with two more powerful single-socket hosts can reduce the counter from four sockets to two if the architecture, performance, and hypervisor support rules permit it. License savings do not justify poor resilience or exhausted memory, but the server refresh and the licensing decision belong in the same model.

I separate scenarios by trigger instead of averaging an optimistic forecast.

1. In the dense scenario, the estate grows to 60 VMs on four sockets. The mixed model retains its calculated advantage.
2. In the expansion scenario, a new host is added. Request a migration quote for the entire pool and compare it with the full VUL model from the expansion date.
3. In the cloud scenario, some local VMs are not merely copied but actually removed from protection on the hypervisor and appear as cloud workloads. The total VUL count may barely change, while socket rights remain attached to the local hosts until the architecture is revised.

Plan for peak protected workloads, not the annual average. Veeam counts objects processed during the previous 31 days, so a brief overlap between an old and a replacement VM during migration can temporarily consume two instances. License headroom must cover the parallel protection period. Otherwise, the application move occurs at the same moment backup starts reporting an overage.

Physical servers and cloud make the model mixed

A socket license does not turn four CPU sockets into the right to back up any 40 objects. It covers VMs on licensed VMware and Hyper-V hosts. Two physical servers running Veeam Agent and eight cloud VMs in year three sit outside that boundary and require instance coverage under the current rules.

The distinction matters for branch offices too. A small physical server at a remote location does not join the central cluster's socket pool. A cloud VM also does not consume a local socket merely because its backup returns to an on-premises repository. Licensing follows the protected source, not the storage location of the copy.

VUL does not include every cloud cost. A Veeam subscription does not cancel the cloud provider's charges for compute, object storage, operations, and egress. A purchasing model needs two separate groups of rows: Veeam entitlements and cloud consumption. If they are combined into one backup cost per cloud VM, nobody will be able to explain the budget variance a year later.

A mixed license also does not let you select the cheaper counter for each VMware or Hyper-V VM. Veeam's policy assigns all such VMs to the socket component when it is present, while other supported workloads consume VUL. That avoids double counting, but you cannot cover a few VMs on an overfilled host with extra instances. The architect must decide what happens to the entire virtual pool in that environment.

If a project includes new physical servers, cloud workloads, or a hypervisor change, GSE.kz can bring the server configuration, backup plan, and software proposal into one specification as a system integrator. The useful outcome is not a discount on one row. It is a design in which the host count, workload types, and purchased entitlements do not contradict one another.

A three-year horizon needs matching contract terms

A three-year total only makes sense when the duration of entitlements, support, and payments matches. A prepaid three-year VUL quote cannot be compared directly with annual socket support renewals if the supplier may change the second and third year's price. Ask for two socket support variants: a fixed commitment for the full period and three separate renewals with the assumed indexation stated. For VUL, request both prepayment and annual payment under a three-year contract.

If the quote is in US dollars while the budget is approved in tenge, do not hide currency risk in an average license price. Keep the proposal currency, the conversion rate for each payment date, and the reserve required by company policy in separate fields. The purchasing committee can then see why a lower price with annual payment may produce a less predictable result in tenge. Add VAT only after comparing the base because suppliers sometimes present it differently.

Start dates should match the actual start of protection. A three-year subscription activated two months before the repository and jobs are ready loses paid time without producing protection. A gap in socket support can trigger separate reinstatement terms, so the price of an ordinary on-time renewal cannot automatically be used for expired support. Ask the supplier to state whether reinstatement, term alignment, and a migration SKU are included.

Track cash flows rather than only the total. For each payment, record the date, amount excluding VAT, tax, currency, and purpose: socket support, VUL subscription, or migration. Finance can discount the payments to present value using the company's approved rate. When the difference between models is small, deferring part of the payment can matter more than the nominal total. For the KZT 6.3 million gap in our example, discounting is unlikely to change the choice, although the exact result depends on the company's rate.

Do not include an assumed residual value for the perpetual socket license at the end of year three. Veeam's policy limits license transfers, and the right to keep running without later updates is not a freely saleable asset. Add year four as a control column instead: show the cost of continued support, the VUL count at the new estate size, and whether the planned host expansion has arrived. This exposes a decision that is cheap only until the next budget cycle.

The contract must also address a shrinking estate. VUL lets a customer adjust quantity at renewal, but a prepaid fixed quantity normally does not return money midway through the term. Support for four perpetual sockets does not shrink automatically when consolidation leaves only two in use. You must check whether the contract can change and what follows from that change. Put the dates on which quantities may be revised into the three-year model. They mark the boundary between technical consumption and a commercial obligation.

Check the quote by object and date

Export actual consumption from Veeam before comparing prices instead of copying the VM count from the hypervisor screen. The official PowerShell Reference documents Get-VBRSocketLicenseSummary, Get-VBRInstanceLicenseSummary, and Get-VBRLicensedInstanceWorkload. They report purchased, used, and remaining units, plus the objects consuming instances.

$license = Get-VBRInstalledLicense
Get-VBRSocketLicenseSummary -License $license |
  Select-Object LicensedSocketsNumber, UsedSocketsNumber, RemainingSocketsNumber

Get-VBRInstanceLicenseSummary -License $license |
  Select-Object LicensedInstancesNumber, UsedInstancesNumber, NewInstancesNumber

Get-VBRLicensedInstanceWorkload -License $license |
  Select-Object Name, Type, UsedInstancesNumber |
  Sort-Object Type, Name

The socket summary should contain LicensedSocketsNumber, UsedSocketsNumber, and RemainingSocketsNumber. The instance workload list has Name, Type, and UsedInstancesNumber. Save the output beside the quote with the export date. It will reveal protected templates, old agents, and transition workloads that are missing from the CMDB.

Then ask the supplier for a table of verifiable parameters rather than one total amount.

• Full SKU name, edition, license type, and unit count.
• Subscription or support start and end dates, payment schedule, and currency.
• Expansion rules, minimum order quantity, and whether the discount continues.
• Compatibility of the old socket licenses with the new VUL and the resulting edition's features.
• Terms for migrating the entire socket pool if a host is added or the platform changes.

Keep three totals in the financial worksheet: excluding VAT, including VAT, and present value when payment dates differ. Do not compare a three-year VUL prepayment with one year of socket support. Do not put the original purchase price of a long-owned perpetual license into future costs when that purchase is irreversible. It is a sunk cost. Migration, reinstatement of expired support, and edition alignment are future consequences of the current decision and must be included.

For the starting estate of 40 VMs on four already licensed sockets, I would retain socket coverage and add VUL for physical and cloud workloads. Our model produces KZT 7 million versus KZT 13.3 million over three years. For a new environment, I would not build the business case around a license that is unavailable in a normal new sale. If a third host appears in the approved capacity plan, recalculate the decision against a migration quote before ordering the hardware. One extra node can make today's saving unavailable at the exact point when the cluster grows.