Version entitlement under Micro Focus ALAs

The right to use a product and the right to use a particular release of that product are two different grants, and confusing them is a reliable source of audit exposure. Version entitlement under Micro Focus ALAs decides which releases your license covers, whether an upgrade extended or replaced your rights, and whether a deployed version sits inside the grant at all. An auditor who reads version entitlement narrowly can turn a routine upgrade into a shortfall.

This field note explains how version entitlement works in an Additional License Authorization, the moves auditors make around it, and how to defend the version you actually run. It pairs with our ALA and entitlement review track.

What version entitlement means

An ALA grants rights to a product at a version, or within a version range, defined by the agreement and the order form. Some grants are version specific. Others extend to later releases through upgrade or maintenance rights. The grant is not automatically open ended, and it is not automatically frozen. The governing language decides, and that language must be read alongside the maintenance terms that were in force when each version was deployed.

Where the auditor presses

The pressure points are predictable. A buyer who upgraded to a newer release may be told the new version requires a fresh entitlement that was never purchased. A buyer still running an older release may be told the older version fell outside support and therefore outside the grant. Both claims are interpretations of the version language, and both can be tested against the upgrade and maintenance rights the buyer holds.

Upgrade and migration rights carry the grant

Where maintenance or upgrade rights applied, moving to a newer version typically extends the existing entitlement rather than creating a new obligation. The buyer's job is to document the maintenance coverage in force at each upgrade and show the chain of entitlement from the original purchase to the running version. That chain is the answer to a finding that treats a newer release as unlicensed.

Older versions are not automatically uncovered

A running version that predates the audit is not a shortfall merely because it is old. The grant covers the versions the ALA describes, and lapsed support affects the right to updates and assistance, not necessarily the right to run a version already deployed under a valid grant. Separating the right to run from the right to support is essential, because auditors blend the two to manufacture exposure.

Building the version defense

The defense is documentary. We assemble the original grant, the order form, the maintenance and upgrade history, and the deployment record for each version in use. Read together, these establish which releases are entitled and close the gap a version based finding relies on. In a recent engagement, a finding that treated a current release as unpurchased collapsed once the upgrade rights active at deployment were documented, removing the basis for most of the claim.

Perpetual and subscription grants behave differently

Version entitlement depends in part on whether the grant is perpetual or subscription based. A perpetual grant typically secures the right to run the licensed version indefinitely, with upgrade rights flowing from active maintenance. A subscription grant ties use to a term, and version rights move with the subscription. An auditor who applies subscription logic to a perpetual grant, or treats a perpetual right as if it lapsed with support, misstates the entitlement. Establishing the nature of the grant for each product is therefore a prerequisite to any version argument, and it changes which questions are even relevant.

Downgrade and prior version rights

Many grants include the right to run a prior version of a product, not only the latest release. Buyers who standardise on an earlier, stable release are sometimes told the older version is uncovered, when the grant in fact permits running it. Reading the downgrade and prior version language alongside the upgrade rights gives a complete picture of which releases are entitled, and it frequently widens the buyer's covered range beyond what a finding assumed.

Documenting the version chain

The version defense lives or dies on records. We assemble the purchase, the maintenance and support history, the upgrade entitlements active at each transition, and the deployment record for every running version. Presented together, these establish an unbroken chain from the original grant to the version in production, and they answer a finding that treats any link in that chain as missing. Where the chain is complete, the version based shortfall has no foundation, and the number falls accordingly.

Support lapses and the right to run

A frequent version based finding rests on conflating support with the license itself. When maintenance lapses, the buyer loses the right to new releases and vendor assistance, but a perpetual grant to run an already deployed version is not automatically forfeited. An auditor who treats every version deployed after a support lapse as unlicensed is asserting a forfeiture the contract may never have provided. Reading the support clause separately from the use grant, and establishing exactly what each one says, prevents a support gap from being recast as a license shortfall.

Closing the version question in the forward agreement

Once a version dispute is resolved, the cleanest protection is to define version rights explicitly going forward: which releases are covered, how upgrades flow from maintenance, and whether prior versions remain permitted. Writing those rights into the forward agreement removes the ambiguity that produced the finding, so a future review starts from settled definitions. A version question answered once, and then documented, does not need to be answered again under audit pressure.

Why version questions reward early work

Version entitlement is one of the few audit questions a buyer can settle almost entirely from its own records, before any vendor measurement begins. The grant, the order form, the maintenance history, and the deployment dates are all in the buyer's possession, and assembling them into a clear chain takes effort but no negotiation. A buyer that has done that work arrives at the audit able to show which releases are entitled and why, rather than waiting to react to a claim that a current version was never purchased. The version chain, built early and kept current, is among the most reliable defenses in the entire ALA toolkit because it depends on facts the buyer controls.

For the wider method, read the complete OpenText audit defense playbook. For product specific version defense, see our ALA and entitlement review track, and if a version question drives your finding, open a case.