Home  ›  Articles  ›  ALA & Entitlement

ALA development versus production rights

ALA & EntitlementField noteUpdated May 2026

Software is rarely deployed only where it earns revenue. It runs in development sandboxes, test environments, staging tiers, and training instances, and whether any of those non production deployments consume a license depends entirely on the grant. ALA development versus production rights is the distinction between use that the Additional License Authorization counts toward the entitlement and use the authorization carves out or treats differently, and a finding that ignores that distinction, counting every running instance as if it were production, can inflate the obligation by a wide margin across an estate that maintains the customary parallel environments.

This field note explains how an ALA separates development from production use, where a finding collapses the two, and how the defensible reading holds the count to the deployments the grant actually charges for. It pairs with our ALA and entitlement review track.

What the grant says about non production use

Many Micro Focus authorizations distinguish between production and non production use, and the treatment varies by product and by grant. Some authorizations include a number of non production instances within the production entitlement, some license them separately at a different rate, and some require that they be counted the same as production. The decisive question is not what is customary in the industry but what the specific authorization governing the purchase states, which is why establishing the grant terms precisely, as described in what is an Additional License Authorization, comes before any argument about a particular environment.

The principle

Non production use is not automatically free and not automatically chargeable. The authorization decides, and a finding that assumes either default without reading the grant is asserting terms the contract may not contain.

Where a finding collapses the two

The common overreach is a scan that detects every installed and running instance and counts them uniformly against the production entitlement, regardless of the role each environment actually plays. A development server, a test instance, a disaster recovery standby, and a training environment all appear in the scan as deployments, and a finding that does not separate them charges the buyer for each as though it were live production. Where the authorization grants non production rights, that uniform count overstates the obligation, and the correction is to classify each environment by its actual function and apply the grant terms that match. This classification work overlaps with the standby and recovery treatment examined in ALA disaster recovery and standby rights.

Classifying environments by function

Defending the distinction requires evidence of what each environment actually does, not merely what it is named. A server labelled production may run only test workloads, and a development instance may have been promoted to live use without relabelling. The defensible position rests on the operational reality: what data the environment processes, who uses it, and whether it serves end users or supports the work of building and testing the software. Establishing that record for each detected instance is what allows the non production deployments to be set apart and the grant applied accurately, and it draws on the same use restriction discipline covered in ALA territory and use restrictions.

Virtual and ephemeral environments

Development and test environments are increasingly virtual, containerized, or spun up and torn down on demand, and a scan that counts every instance it ever observed can charge for environments that existed only briefly or never ran a production workload. The grant terms for how instances are counted, and whether transient non production environments fall inside or outside the entitlement, interact directly with the partitioning rules that govern virtual deployment generally, examined in ALA virtualization and partitioning rules. A finding that applies a physical instance count to an elastic development estate frequently overstates what was ever simultaneously in use.

How the distinction reduces the number

In a recent engagement, a finding counted a buyer's full set of detected instances against a single production entitlement, when the authorization granted a defined allotment of non production environments within that entitlement. Classifying the development, test, and training instances and applying the non production allowance removed those deployments from the chargeable count, leaving only the genuine production footprint to be measured. This is the ordinary mechanism: each environment correctly reclassified as non production, where the grant allows it, subtracts from the finding. Applied across an estate, this discipline contributes to the 68 percent average reduction we have achieved across more than 200 defended audits, by holding the count to the use the authorization actually charges for.

The capacity question follows the use question

Once an environment is correctly classified, the next question is often how much capacity it consumes under the grant, because non production environments may be licensed by a different capacity rule than production. Settling whether a deployment is production or non production therefore precedes, and shapes, the capacity measurement, and getting the sequence right prevents a finding from charging full production capacity for an environment the grant treats more leniently. This is why the use classification and the capacity definition are handled together, as set out in capacity definitions in Micro Focus ALAs.

Fixing the distinction forward

After the present finding is corrected, the forward agreement should state plainly how non production use is treated for each product, so a future review cannot reopen the count by collapsing development into production again. A clean forward arrangement records the non production allowance, defines how environments are classified, and removes the ambiguity that let the audit charge test and development instances at production rates. Resolving the finding and fixing the use distinction forward are two halves of the same work. If a finding has counted your development, test, or training environments as production, open a case and we will hold the count to the use the authorization actually grants.

For the full method, read the complete OpenText audit defense playbook, and for entitlement defense across the Micro Focus estate see our ALA and entitlement review track.

Development counted as production?

We classify every detected environment by its actual function and apply the non production rights the authorization grants, so test, training, and development instances are not charged at production rates. Open a case.

Open A Case →
When an OpenText or Micro Focus audit notice arrives, the first seven days carry more weight than any week that follows. OpenText Audit Defense is an independent, buyer side firm founded in 2020 by former vendor compliance leadership. We have defended more than 200 audits, reduced the average finding by 68 percent, and mitigated more than $90M in claims. We do not resell OpenText software, and we are not affiliated with OpenText Corporation. To open a case, use the contact form on this site.