OpenPass cloud and on premise deployment rights

Where software runs has become as important as how much of it runs. An estate that moves a workload from a data centre to a cloud platform, or that operates the same application across both at once, is doing something the business treats as routine. The contract does not always agree. OpenPass cloud and on premise deployment rights decide whether that flexibility is built in or whether each move creates a fresh opportunity for a finding. A deployment right that is silent on the cloud, or that counts the same workload twice when it spans two environments, turns an ordinary infrastructure decision into a compliance exposure.

The buyer's interest is portability: the right to run a licensed workload wherever the business needs it, on premise, in the cloud, or across both during a transition, without the count changing simply because the location did. The vendor's default tends toward the narrowest reading, treating each environment as a separate deployment unless the agreement says otherwise. Closing that gap is a negotiation, not an assumption.

Why location becomes a metric

Many product metrics were written for a world of fixed on premise deployments, and they translate awkwardly to elastic cloud infrastructure. A metric tied to cores or to physical capacity behaves very differently when the underlying hardware is virtual and scales on demand. A workload that occupies a modest footprint on premise may appear, through the lens of a cloud measurement, to consume far more, simply because the elastic platform provisions capacity differently. Where the agreement does not address this translation, the vendor's measurement can read ordinary cloud operation as overuse. The way capacity is defined and metered across environments is closely tied to OpenPass virtualization and partitioning terms, and the two should be read together whenever a workload touches virtual infrastructure.

The double count across two environments

The most common deployment finding is the double count. A workload that runs on premise and in the cloud at the same time, whether during a migration, for disaster recovery, or to serve different regions, can be measured as two deployments of the same licensed software. Without a deployment right that recognises a single workload spanning two environments, the buyer pays twice for running once. This is the same artefact that arises during migrations, where a legacy system and its replacement run in parallel, and the protection is similar: the agreement must see one workload, not two. The migration case is set out in OpenPass migration rights and legacy entitlements, and the deployment right is the broader version of the same principle, covering not just migrations but any legitimate reason a workload spans environments.

Production, non production, and where they live

Deployment rights also intersect with the line between production and non production use. A development, test, or disaster recovery environment may be spun up in the cloud precisely because cloud infrastructure makes it cheap and fast to provision. If the agreement counts those non production environments the same way it counts production, the buyer is charged for capacity that exists only to support the production workload, not to serve it. The agreement should grant clear non production deployment rights that travel across environments, so that a test environment in the cloud is treated as non production whether it sits on premise or off. This distinction is examined in OpenPass development versus production scope, and it matters most when cloud makes non production environments easy to multiply.

How deployment rights change an audit

When OpenText's compliance team measures an estate, deployment location is one of the first things the measurement captures, and an estate that has moved to the cloud without securing the matching rights is exposed in exactly the place the measurement looks. With clear cloud and on premise deployment rights written into the agreement, a workload that spans environments is simply portable operation, not a finding. Without them, the same activity is deemed additional deployment, priced at then current list price with back maintenance and audit cost stacked on top. Securing portability in the agreement is therefore a direct way to cap future exposure, which is the broader subject of can OpenPass cap future audit exposure. The deployment right is, in effect, pre negotiated permission to run the estate the way the business actually runs it.

How this works in practice

In a recent engagement, an estate that had moved a major workload to a cloud platform, while retaining an on premise instance for resilience, faced a finding that counted both as separate production deployments. The measurement read the elastic cloud capacity through a metric written for fixed hardware, inflating the apparent footprint, and then added the on premise instance on top as a second deployment. The defense reconstructed the workload as a single licensed application operating across two environments, demonstrated that the cloud footprint reflected elastic provisioning rather than genuine additional consumption, and negotiated forward deployment rights that recognised portability across cloud and on premise without a double count. The reconstruction method behind that result is described in the complete OpenText audit defense playbook, and comparable outcomes appear across our engagements.

Negotiating the right to run anywhere

Cloud and on premise deployment rights are about preserving the flexibility the business depends on without paying a penalty for it. Secure portability so a licensed workload can run wherever it is needed, ensure the agreement sees a single workload across environments rather than counting it twice, translate capacity metrics sensibly for elastic infrastructure, and carry non production rights across environments as well. Done well, the estate moves freely between cloud and on premise without a finding. Done poorly, every infrastructure decision becomes a compliance question. This work is part of our OpenPass enterprise agreement negotiation track and rests on the independent baseline set out in building an OpenPass target baseline before negotiation. If your estate is moving to the cloud or operating across both worlds, open a case before the deployment becomes a finding.