Dual entitlements during an OpenPass migration.

Migration is the moment an estate is most exposed in an audit, because for a period the same workload runs in two places at once. OpenPass is built to handle this with dual entitlements, the right to operate the legacy deployment and its replacement in parallel without being counted twice. Used well, it removes the migration trap. Documented poorly, it becomes the next finding.

Every significant platform move, from on premise to cloud, from one data centre to another, or from an older product version to a current one, creates an overlap window. During that window the old system is still live for fallback and the new system is ramping up. A vendor measuring usage in the middle of this window sees two populations where the business only ever intends to run one. Dual entitlements exist so that overlap does not become a compliance shortfall.

The risk is not theoretical. Migrations slip, run longer than planned, and scale unevenly, and any measurement taken during that turbulence can present a temporary state as a permanent one. Because the deemed acquisition remedy prices a shortfall at list and stacks maintenance on top, a migration counted twice can produce a finding far larger than the actual cost of the move. The dual entitlement clause is the contractual answer to that risk, and it is worth treating with the same care as the price itself.

What dual entitlements actually grant

Dual entitlements are a contractual right to run a defined quantity of the source deployment and the target deployment simultaneously for a stated migration period. OpenPass, OpenText's enterprise licensing framework, includes this mechanism precisely because its single contract structure is designed to carry an estate through change. The grant typically fixes the overlap quantity, the products it covers, and the window during which the parallel run is permitted. Within those bounds, running both environments is licensed, not a breach.

The detail that matters is scope. A dual entitlement that names the wrong products, caps the overlap below real need, or sets a window shorter than the project plan will leave gaps the vendor can later count. Treating the dual entitlement clause as a throwaway formality is how a protected migration becomes an exposed one. The broader migration rights picture is covered in OpenPass migration rights and legacy entitlements.

Where the migration trap opens

The trap opens when the contract language and the project reality drift apart. A migration that runs longer than planned can outlast the dual entitlement window, at which point the parallel run becomes unlicensed overnight. A project that scales the new environment faster than expected can exceed the overlap quantity. And a measurement taken at peak overlap, rather than at steady state, can present the temporary double footprint as the permanent license requirement.

Sizing the overlap window with margin

The single most useful discipline in a migration clause is to size the overlap window to the project that will actually happen, not the project on the original plan. Delivery teams build schedules around the best case, and licensing windows built on the same optimism expire while the migration is still running. A window with several months of margin, and a clear mechanism to extend it if the project slips, converts a fragile protection into a robust one. The cost of asking for margin at negotiation is low. The cost of running out of window mid migration is a finding priced at list.

The overlap quantity deserves the same caution. A migration rarely moves in a single clean cutover; it moves in waves, and at the peak of those waves the combined footprint can briefly exceed the steady state of either environment alone. An overlap quantity sized only to the steady state will be breached at the peak. Sizing it to the realistic peak, with headroom, keeps the parallel run inside the licensed bound throughout. These are not exotic requests. They are the difference between a migration clause that protects the project and one that merely describes it. To scope a window and quantity that match your real plan, open a case before the move begins.

The defense is to ensure the overlap window, the overlap quantity, and the products in scope all match the real project plan with margin to spare. Migrations almost never finish exactly on schedule, so a window sized to the optimistic plan is a window sized to fail. The way usage is measured during migration is itself negotiable, and the clause that governs it is discussed in negotiating OpenPass measurement and reporting clauses.

Documenting the overlap so it cannot be counted

Dual entitlements protect you only if you can show that what was running fell within them. That means documenting the migration timeline, the cutover dates, the quantities in each environment, and the date the legacy system was retired. A clean record turns a potential finding into a non event, because the parallel run is demonstrably inside the licensed window. A missing record leaves the vendor free to treat both environments as separate, permanent populations. The reconstruction discipline that supports this is the same one used across every defense, and it is set out in building an OpenPass target baseline before negotiation.

In a recent engagement, an estate mid migration faced a finding that counted both the source and the target deployment at full quantity. Once the migration window and cutover dates were documented against the dual entitlement grant, the overlap was shown to be licensed and the duplicated count fell away. The number that remained reflected the steady state estate, not the temporary double footprint. The evidence did the work, which is why the documentation has to exist before the measurement, not after it.

Negotiating the dual entitlement at conversion

The best time to set dual entitlements is when a finding converts into an OpenPass agreement, because the migration is often part of the same forward plan. At that point you can size the overlap to the project, set a window with realistic margin, and tie the legacy retirement to a date you control. The conversion mechanics are described in how OpenPass converts a post audit finding forward, and the audit protections that should accompany the migration clause are in audit protections to negotiate into an OpenPass agreement.

It also helps to align the dual entitlement with the deployment rights you expect to need on the far side of the move. If the migration ends in a cloud or hybrid posture, the agreement should define the deployment rights for that end state as clearly as it defines the overlap. The interaction between deployment models and licensing is covered in OpenPass cloud and on premise deployment rights.

Treat migration as a licensing event, not just a technical one

Most migration plans are written by architects and run by delivery teams, and the licensing dimension is an afterthought. That is exactly why migrations generate findings. A migration is a licensing event as much as a technical one, and the dual entitlement clause is the instrument that keeps it clean. If you are planning a move and want the overlap protected before it starts, our OpenPass enterprise agreement negotiation track is built for it, and you can open a case to scope the dual entitlements your project actually needs.