ALA upgrade and migration rights explained

Buyers move versions and platforms constantly, and a finding that treats every move as a new acquisition can manufacture a shortfall out of ordinary operations. ALA upgrade and migration rights explained is about what your Additional License Authorization actually permits when you upgrade a product or migrate it to new hardware, and why a count that ignores those rights overstates the obligation. An entitlement you already hold cannot be charged for twice simply because the software now runs in a new place.

This field note explains how upgrade and migration rights work within an authorization, where findings overreach by ignoring them, and how to defend the position. It pairs with our ALA and entitlement review track.

What upgrade rights cover

An upgrade right concerns moving from one version of a licensed product to a newer one. Where the authorization grants the right to run the licensed product, that grant commonly carries the entitlement forward across versions for the same licensed quantity, subject to the conditions the authorization states. A buyer who upgrades within its entitlement has not acquired anything new; it has continued to use what it already holds. A finding that counts the new version as a fresh deployment, on top of the version it replaced, double counts a single entitlement.

What migration rights cover

Migration concerns moving a licensed product to new hardware, a new platform, or a new environment. The relevant question is whether the authorization ties the license to a specific machine or permits the licensed quantity to move with the workload. Where migration is permitted within the licensed quantity, running the product on the new platform is a continuation of the existing entitlement, not a new one. A finding that counts both the source and the target of a migration, as if the product were live in two places, overstates consumption during what is really a transition.

The transition period problem

Migrations are rarely instantaneous. For a period, the product may exist on both the old and the new platform while data is moved and the cutover is validated. An auditor who samples during that window can record both deployments as if they were permanent, parallel consumption. The defensible reading recognises a transition as a transition: the entitlement is in motion, not multiplied. Establishing the migration timeline, and showing that the source was decommissioned after cutover, removes a count that exists only because the measurement caught a move in progress.

Reading the rights against the version history

Upgrade and migration rights have to be read against the version that governed each purchase, because an authorization in force at the time of an order is what defines the right. This is the same version discipline that governs entitlement generally, examined in version entitlement under Micro Focus ALAs. A finding that applies a later authorization's narrower upgrade language to an earlier purchase, or that ignores the upgrade right the governing version granted, misreads the entitlement. Pairing each deployment with the authorization that governed its acquisition is what fixes the reading.

How we defend an upgrade or migration finding

The defense is documentary and chronological. We establish what was originally licensed, the upgrade and migration rights the governing authorization granted, and the timeline of the version change or platform move. Where a finding counts a replaced version or a migration source as continuing consumption, we produce the decommission evidence and the migration record that show the entitlement moved rather than multiplied. This is the Reconstruct and Rebut work in our method, and it routinely removes counts that exist only because a move was read as an addition. The pattern of correction is consistent with our E-01 case file, where disqualifying items the metric did not support moved a finding from $7.2M to $1.6M, a 78 percent reduction.

Decommissioning evidence is the keystone

The single most useful piece of evidence in an upgrade or migration dispute is proof that the superseded deployment was retired. A version that was upgraded away from, or a platform that was migrated off, should be decommissioned, and a record of that decommissioning converts a double count claim into a single entitlement that simply moved. Buyers who keep clean decommissioning records hold the keystone of this defense. Buyers who do not can often reconstruct it from change management logs, but the cleaner the record, the faster the count falls.

Why upgrade and migration rights are easy to overlook

These rights are easy to overlook precisely because they describe ordinary activity. Upgrading a product and moving it to new hardware feel like routine operations, not licensing events, so buyers rarely document them as carefully as a new purchase. Auditors, working from point in time discovery data, see two deployments and count two. The asymmetry between how routine the activity feels and how consequential it is to a finding is exactly why a buyer should treat every upgrade and migration as something to record at the time, not to reconstruct under audit pressure.

Closing upgrade and migration terms forward

Once an upgrade or migration finding is corrected, the forward agreement should state the upgrade and migration rights plainly: that the licensed quantity carries across versions and moves with the workload, and that transition periods are not treated as parallel consumption. Writing these rights clearly into the forward terms removes the ambiguity that let the audit double count, so the next version change or platform move does not reopen the question. Resolving the present finding and fixing the rights in the forward agreement are two halves of the same work, and completing both keeps ordinary operations from generating extraordinary findings.

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. If a version upgrade or a platform migration is driving your finding, open a case.