OpenPass development versus production scope

One of the quietest sources of inflation in an OpenText or Micro Focus finding is the failure to separate production use from everything that supports it. Development sandboxes, test environments, staging copies, training instances, and disaster recovery standbys all consume software, but they do not all consume it in the same way or at the same value. When an OpenPass agreement is silent on the difference, the vendor is free to count every instance as if it were production. Getting OpenPass development versus production scope right means defining non production use precisely in the contract, so that the environments that keep production running never become the reason the next finding is large.

This is a definitional problem before it is a pricing problem. The amount a buyer pays for a development estate is set less by the number of environments than by how the agreement classifies them, and that classification has to be written down before a measurement is ever taken.

Why non production use gets counted as production

A measurement script does not know intent. It sees an installation, a user account, a configured capacity, and it records each one against whatever metric governs the product. Unless the agreement says otherwise, a developer's local instance, a nightly test rig, and a live production cluster can all be tallied the same way. The vendor's opening finding then prices the whole count at production value. The gap between what is genuinely production and what merely supports it is frequently the largest single line in the finding, and it exists because the contract never drew the boundary. The broader pattern of challenging a finding line by line, including on non production use, runs through how to challenge OpenPass metric definitions.

What development and test scope should cover

A well drafted OpenPass agreement names the categories of non production use explicitly and states how each is licensed. The categories that commonly need their own treatment include development and unit test environments, integration and staging environments, training and demonstration instances, and disaster recovery or high availability standbys that carry no live workload. For each, the agreement should state whether it is included at no additional charge, licensed at a reduced rate, or counted against the production entitlement, and on what metric. Leaving any category undefined hands the vendor the right to choose the most expensive interpretation at audit time. The discipline of fixing every such definition before signing is the same one set out in defined metrics in an OpenPass enterprise agreement.

Disaster recovery and the cold standby trap

Disaster recovery deserves particular attention because it sits on the boundary between production and non production. A standby that is genuinely cold, holding no live data and serving no users until a failover event, is not consuming software in the way a live node does, yet it is routinely counted as a second production instance in an opening finding. The agreement should define the failover scenario, the permitted period of active use during a genuine disaster, and the licensing treatment of the standby in its normal cold state. Without that language the buyer pays twice for resilience it is required by its own risk policies to maintain.

How scope interacts with deployment rights

Development and production scope cannot be separated from where the software runs. The same instance counted differently across cloud, on premise, and virtualised infrastructure compounds the classification problem, because a test environment spun up in the cloud may be measured under a different rule than the same environment on premise. The agreement should keep the non production definitions consistent across every deployment model. The way deployment rights are written across environments is examined in OpenPass cloud and on premise deployment rights, and the way virtualised and partitioned infrastructure is counted is covered in OpenPass virtualization and partitioning terms. Non production scope is only as durable as its consistency across all of these.

How this works in practice

In a recent engagement, a buyer faced a finding in which the development and test estate had been counted at full production value across several product lines, more than doubling the headline number. The defense reconstructed the estate, separated the environments by genuine function, and demonstrated which instances carried no live workload. With the categories defined and evidenced, the non production portion of the finding was reclassified at its real value rather than production value, and the agreement was then redrafted so that the same environments could never be recounted at production rates in a future review. The reduction came almost entirely from drawing a boundary the original contract had left blank. The reconstruction method behind that result is described in the complete OpenText audit defense playbook, and similar outcomes appear across our engagements.

Drawing the boundary before the measurement

OpenPass development versus production scope is won by definition, not by argument after the fact. Name every category of non production use, state how each is licensed and on what metric, give disaster recovery its own treatment, and keep the definitions consistent across cloud and on premise deployment. When the boundary is written into the agreement, the environments that support production stop being a source of exposure. This work sits inside our OpenPass enterprise agreement negotiation track and pairs with the audit protections covered in audit protections to negotiate into an OpenPass agreement. If your development and test estate is undefined in your current agreement, open a case before the next measurement counts it as production.