What is OpenPass and how does it work?

OpenPass is OpenText's enterprise licensing framework: a single contract, a defined term, and dual entitlements that support migration. For a buyer coming out of an audit, it is the vehicle that turns a corrected position into a forward agreement. Understanding how it works is the first step to converting on your own terms rather than the vendor's.

OpenText sells across one of the widest software estates in the market, spanning its own ECM line and the security, DevOps, COBOL, and analytics products that arrived with the Micro Focus acquisition. Historically each of those products carried its own contract, its own metric, and its own renewal. OpenPass is the framework designed to bring them under one roof. Where it changes the buyer's position, for better and for worse, is worth understanding clause by clause.

It is also worth being clear about what OpenPass is not. It is not a discount programme, it is not a guarantee against audits, and it is not a neutral administrative convenience. It is a commercial structure that the vendor offers because consolidation serves the vendor as well as the buyer. Whether it serves the buyer well depends entirely on the terms negotiated inside it, which is why understanding the mechanics comes before deciding whether to sign.

The single contract

The defining feature of OpenPass is consolidation into a single contract. Instead of a patchwork of product schedules with different terms and dates, the estate sits under one agreement with one set of governing terms. This has real advantages: consistent definitions, one renewal to manage, and a single place to negotiate protections. It also carries a risk, because a single contract concentrates exposure. A weak clause in a single contract affects everything, where a weak clause in one schedule was once contained. The trade off between the two structures is examined in OpenPass single contract versus product schedules.

The defined term

OpenPass runs for a defined term rather than as a perpetual grant. A defined term gives both sides certainty over the period, fixes pricing across it if you negotiate that, and sets a clear point at which the agreement is revisited. The same defined term also creates a renewal event, and renewal is where pricing pressure and audit risk often return together. Managing that exposure is the subject of OpenPass defined term and renewal exposure. How the term model compares to owning licenses outright is covered in OpenPass versus traditional perpetual licensing.

How OpenPass sits across the OpenText and Micro Focus estate

One reason OpenPass matters is the sheer breadth of the estate it can cover. OpenText's own ECM line, including Documentum, Extended ECM, Content Suite, eDOCS, and InfoArchive, predates the Micro Focus acquisition and is governed by the OpenText end user license agreement. The security, DevOps, COBOL, and analytics products that arrived with that acquisition are mostly governed by the Additional License Authorizations. OpenPass is the framework that can bring both worlds under one contract, which is precisely why it is powerful and why it has to be read carefully. The terms that suit an ECM deployment are not always the terms that suit a security or DevOps estate.

This breadth also explains why metric definitions matter so much in an OpenPass agreement. A single contract that spans products as different as a content repository and a load testing tool has to define a wide range of metrics, from named users to capacity to volume. Each product family carries its own audit traps, and a consolidated agreement that defines metrics consistently across them removes a great deal of future ambiguity in one move.

What the framework cannot replace

OpenPass organises the commercial relationship, but it does not run it for you. The buyer still has to track what is deployed, reconcile it against entitlements, and prepare for the periodic reviews the audit clause permits. A strong agreement makes that work easier, because the metrics are defined and the protections are in place, but it does not remove the work. An estate that signs an OpenPass agreement and then stops paying attention to its own position will still drift into exposure over the term. The framework rewards the buyer who pairs it with internal discipline and offers far less to the buyer who treats it as a problem solved. To set up both the agreement and the discipline that supports it, open a case.

Dual entitlements for migration

The third pillar of OpenPass is dual entitlements: the right to run a legacy deployment and its replacement in parallel during a migration without being counted twice. Because OpenText expects estates to move, between deployment models, between versions, and into the cloud, the framework builds in the overlap that migration requires. Used correctly, this removes one of the most common audit traps. Used carelessly, the overlap window expires mid project and the parallel run becomes a finding. The detail is in dual entitlements during an OpenPass migration.

How OpenPass relates to an audit

For most buyers, OpenPass enters the picture at the end of an audit rather than the start. The vendor opens with a compliance finding, priced at list with back maintenance and audit cost recovery stacked on top. Once that finding is reduced through reconstruction and rebuttal, OpenPass becomes the framework for settling forward. The corrected counts become the baseline, the metrics can be defined in the contract, and audit protections can be written in. The end to end sequence is in the complete OpenText audit defense playbook, and the conversion step specifically in how OpenPass converts a post audit finding forward.

This is why the framework cannot be assessed in isolation from the audit that usually precedes it. An OpenPass agreement signed on top of an uncorrected finding inherits the finding's inflation as its baseline. The same agreement signed on top of a reconstructed position locks in the corrected number instead. The framework is identical in both cases. The difference is entirely in the work done before the signature.

What to watch before you sign

Reading the agreement the way the vendor reads it

The most useful posture when an OpenPass agreement arrives is to read every clause as the vendor will read it at audit time, not as it reads in a calm boardroom. A metric that seems clear enough in the abstract becomes the hinge of a seven figure dispute when the vendor applies its broadest interpretation. A measurement clause that looks like boilerplate becomes the licence to count a momentary peak as a permanent requirement. Reading the draft adversarially, asking of each clause how it could be turned against you, surfaces the weaknesses while there is still time to fix them.

This is the perspective an independent, buyer side practice brings to the document. The questions are not academic. They are the exact questions the vendor's compliance team will ask once the agreement is signed and a review begins. Anticipating them at negotiation, when the buyer has leverage, is far cheaper than answering them at audit, when the buyer has none. To have an OpenPass draft read this way before you sign it, open a case.

OpenPass is neither a trap nor a gift. It is a structure, and its value to the buyer depends entirely on how the metrics are defined, how the audit clause is written, and how the renewal is protected. Signed without scrutiny, it can lock an inflated baseline and a vendor friendly audit clause into a single contract for a fixed term. Negotiated carefully, it can deliver defined metrics, a held price, and limits on future measurement across the whole estate. The work of getting it right is our OpenPass enterprise agreement negotiation track. If an OpenPass agreement is in front of you, open a case before you treat the vendor's draft as the only version.