Fortify migration to OpenText cloud and entitlements

Moving Fortify from a self managed deployment toward an OpenText cloud or hosted model is rarely a clean swap of one license for another. Entitlements that were written for perpetual on premise use do not always map cleanly onto a subscription or hosted arrangement, and the migration window is exactly when usage data is most ambiguous. A finding that treats the transition state as if it were a steady state, or that counts both the legacy deployment and the cloud deployment as fully licensed at the same time, overstates exposure. Understanding how Fortify migration to OpenText cloud and entitlements interact is what keeps the move from becoming an audit liability.

This article explains how entitlements shift during a migration, where the dual running period creates counting traps, and how a buyer protects its position. It supports our Fortify and AppSec audit defense practice and links up to the complete OpenText audit defense playbook for 2026.

Why migration changes the entitlement question

A perpetual on premise Fortify entitlement and a hosted subscription are different instruments. One grants a right to run the software you hold; the other grants access for a defined term under defined limits. When an organization migrates, it often runs both for a period: the legacy environment continues while the cloud environment is stood up, validated, and cut over. During that window the same teams and the same projects exist in two places at once. A measurement that counts each place independently will appear to show twice the usage, when in reality it is one population mid transition. The distinction between perpetual and term positions is set out in Fortify perpetual versus term license positions.

Where the dual running period inflates a finding

The migration window produces several recurring overcounts:

• Counting legacy and cloud seats together. The same developers appear in both environments during cutover, but they are one population, not two.
• Counting validation and parallel run scans as production volume. Migration requires test scans to confirm parity, and these should not enter the sustained measurement.
• Treating dual entitlements as separate purchases. Migration frameworks frequently grant a right to run both old and new during transition, a structure that mirrors the dual entitlement logic of OpenPass migration agreements.
• Carrying decommissioned legacy components forward. Once cutover completes, the legacy deployment is retired and should drop out of the count, as discussed in decommissioned Fortify projects still on the audit.

Reading the migration entitlement correctly

The defensible approach is to read the migration terms and apply them as written. Where the agreement grants dual entitlements for a transition period, running both environments at once is contemplated and does not create an overage. Where the cloud subscription defines its own metric, that metric governs the cloud usage and the legacy metric governs whatever legacy use remains. The error is to apply both metrics to the same population as if each were independent. The cloud side has its own counting model, examined in Fortify on Demand subscription audit considerations.

Protecting the position during the move

The practical defense is to document the migration timeline before any vendor script runs. A buyer records when the cloud environment was stood up, when validation ran, when cutover occurred, and when the legacy deployment was retired. With that timeline in hand, the dual running period is visible as a bounded transition rather than a permanent state, and the parallel run scans separate cleanly from production volume. This reconstruction is part of reconciling Fortify entitlements before an audit, and it is far easier to assemble while the migration is fresh than to recover after a finding lands.

Evidencing the real picture

The buyer reconstructs the position from its own records: deployment dates, user provisioning logs, scan histories in both environments, and the decommissioning record for the legacy system. From these it shows that the developer population is a single set of people, that the parallel scans were validation rather than production, and that the dual running period falls within whatever transition window the agreement allows. The reconstruction converts a doubled count into a single, time bounded position, and the corrected figure is materially smaller.

A representative outcome

In a recent engagement, a finding counted a Fortify population in both a legacy environment and a new hosted environment, effectively doubling the seat count for a team that was mid migration. By producing the migration timeline, showing the cutover and decommissioning dates, and demonstrating that the parallel scans were validation runs, we collapsed the doubled count back to the single population the organization actually operated. The migration related portion of the finding settled well below its opening figure, consistent with the reductions we see across Fortify matters and with the path our E-02 case file followed, where a technology company reduced a developer seat overclaim by 80 percent.

Carrying the protection into the new agreement

The migration is also an opportunity to fix the metric going forward. A clean cloud entitlement with a defined unit, a defined term, and explicit transition provisions removes the ambiguity that produced the finding in the first place. That is the resolve stage of our method, and it connects directly to how OpenText measures Fortify usage in an audit. To plan a migration that does not expose you, you can open a case with our team.

How the four Rs apply to a migration

Our method maps cleanly onto a migration under audit pressure. In the respond stage, across the first seven days, we take over the channel and freeze the narrative so the audit team is not handed an undifferentiated export of two environments at once. In the reconstruct stage, over the following weeks, we build the migration timeline and the single developer population independently, before any vendor measurement script runs. In the rebut stage we challenge every line that counts legacy and cloud usage together, and in the resolve stage we convert forward into a clean entitlement with defined transition provisions so the same ambiguity cannot recur. The timing of each stage is set out in our broader method, and the migration is exactly the moment to apply it.

Questions buyers ask during cutover

Buyers in the middle of a cutover ask the same practical questions. Do we have to stop using the legacy environment to avoid a doubled count? Usually not, where the agreement contemplates a transition period. Does every validation scan count against the new subscription metric? Not where it is documented as parity testing rather than production use. What happens to the legacy licenses once cutover completes? They are retired, and the decommissioning record removes them from the sustained count. The answers all turn on documentation assembled while the migration is fresh, which is why the reconstruction belongs at the start of the move rather than after a finding arrives.

For the underlying seat methodology, read the Fortify seat counting white paper.