A migration that ignores the portability conditions turned a clean compliance position into audit exposure inside 90 days
Portability is real and it is conditional. The conditions are precise, they are not enforced at the point of migration, and nothing tells you at the time that you have left them behind.
Prepared by Redress Compliance · August 17, 2026 · IBM advisory.
Executive summary
A migration that ignores the conditions turns clean into exposed inside 90 days. Nothing blocks the move and nothing warns you, which is why the exposure is discovered at audit rather than at deployment.
IBM software is portable to AWS, Azure, Google Cloud, and IBM Cloud, under conditions that are precise rather than approximate. Portability is a permission with terms attached, not a property of the software.
Cloud Pak VPC conversions repriced workloads 20 to 40 percent above PVU baselines. Converting during a migration bundles two decisions that should be taken separately and priced separately.
Sub capacity survives the move only if the instrumentation does. ILMT coverage that lapses across a migration converts a held entitlement into a full capacity bill on the new platform.
Portability is conditional, and the conditions are precise
IBM software runs on AWS, Azure, Google Cloud, and IBM Cloud. It does so under terms, and the terms do not enforce themselves at deployment time.
| Dimension | What has to hold | How it fails silently |
|---|---|---|
| Eligible platform | The target cloud is covered by the applicable terms | A move to an uncovered platform deploys perfectly well |
| Sub capacity instrumentation | ILMT continues to cover the migrated workload | Coverage lapses in the cutover and nobody notices |
| Counting basis | The metric on the new platform is understood before the move | Virtual cores count differently than the source estate |
| Entitlement scope | The licence permits the deployment as configured | Nothing blocks a configuration the entitlement does not cover |
The absence of enforcement is the whole problem. Nothing in a cloud migration stops you deploying IBM software in a way the entitlement does not permit. The workload runs, the project closes, the team moves on, and the position is only tested when someone asks for evidence. Ninety days is roughly how long it takes for a migration to be complete enough that unwinding it is expensive and recent enough that nobody has yet checked.
Nothing warns you, which is why the timing is what it is
IBM software is portable to the major clouds under conditions that are precise, published, and entirely unenforced at the point of deployment. That combination is what produces the pattern: a migration that does not respect the conditions turns a clean compliance position into an audit exposure inside 90 days, and the ninety days is not a grace period. It is roughly how long it takes for the migration to become complete enough that reversing it is expensive, while remaining recent enough that nobody has yet had reason to check.
The sub capacity dimension is the one that most often breaks quietly. Sub capacity licensing is conditional on ILMT, and a migration is exactly the kind of event that interrupts instrumentation: new hosts, new network boundaries, new agents to deploy, and a project plan in which licensing measurement is nobody named deliverable. The entitlement has not changed and the right has not been lost, but the evidence that makes the right claimable has a gap in it, and a gap in the evidence prices as full capacity on the new platform.
The Cloud Pak conversion question then arrives at the worst possible moment. Migrations create a natural opening for a conversion conversation, because the estate is already moving and the bundle is presented as the modern way to run it. In our reviews, Cloud Pak VPC conversions repriced workloads 20 to 40 percent above PVU baselines. That may still be the right decision on its merits, but it is a separate decision from the migration and it should be priced separately. Bundling the two means the conversion is evaluated against migration urgency rather than against its own arithmetic.
The practical discipline is to treat licensing as a migration workstream with a named owner rather than as a compliance review afterwards. Establish the target platform terms before the architecture is fixed, carry ILMT coverage through the cutover as an explicit deliverable, confirm how the metric counts on the new platform, and decline to take the conversion decision inside the migration window. The sub capacity mechanics sit in sub capacity and ILMT, the conversion arithmetic in the middleware playbook, and the library in the IBM practice.
- Your agreements decoded into plain English before the auditor interprets them for you
- Entitlements verified against the target platform terms and counting basis
- A defensible position paper generated in minutes, not weeks
The controls that keep the position clean
- Establish target platform terms before the architecture is fixed, because portability is conditional and the conditions differ by cloud.
- Carry ILMT coverage through the cutover as a named deliverable, since a migration is precisely the event that interrupts instrumentation and a gap prices as full capacity.
- Confirm how the metric counts on the new platform, because virtual cores on a cloud host do not necessarily count as they did on the source estate.
- Take the Cloud Pak conversion decision outside the migration window, so it is evaluated on its own arithmetic rather than against project urgency.
- Give licensing a named owner in the migration plan, rather than treating it as a compliance review that happens afterwards.
- Check the position at 60 days, not 90, since the exposure window closes before anyone would normally look.
How the exposure forms
The mechanism is consistent across migrations that go wrong, and it is a governance sequencing failure rather than a technical one:
How quickly a migration that ignores the portability conditions converts a good compliance position into an audit exposure.
How far Cloud Pak VPC conversions repriced workloads above their PVU baselines when taken during a migration.
IBM software is portable to AWS, Azure, Google Cloud, and IBM Cloud under conditions that are precise. Nothing enforces them at deployment, so the workload runs, the project closes, and the position is tested only when evidence is requested.
Sub capacity survives a migration only if the instrumentation does. The entitlement is unchanged and the right is not lost, but a gap in ILMT coverage prices identically to not holding the right at all.
Your first five moves
- Read the portability terms for the specific target cloud before the architecture is agreed, since the conditions differ by platform.
- Put ILMT continuity in the migration plan as a named deliverable with an owner, not as a post migration task.
- Model how the metric counts on the target platform against how it counted on the source estate.
- Refuse to bundle the Cloud Pak conversion into the migration decision, and price it separately on its own arithmetic.
- Audit the position at 60 days post cutover, ahead of the window in which exposure normally forms. The IBM practice runs the check with you.
Frequently asked questions
Is IBM software portable to the major clouds?
Yes, to AWS, Azure, Google Cloud, and IBM Cloud, under conditions that are precise rather than approximate. Portability is a permission with terms attached rather than a property of the software itself.
Why does exposure form so quickly?
Because nothing enforces the conditions at deployment. The workload runs, the project closes, and the position is only tested when evidence is requested. Ninety days is roughly how long it takes for the migration to be expensive to unwind and still unchecked.
What breaks most often?
Sub capacity instrumentation. A migration is exactly the kind of event that interrupts ILMT coverage, and licensing measurement is rarely anybody named deliverable in a migration plan. The right is not lost, but the evidence that makes it claimable has a gap.
What does an ILMT gap cost?
It prices identically to not holding the sub capacity right at all, meaning full capacity on the new platform. The entitlement is unchanged; only the evidence is missing, and the contract does not distinguish between the two.
Should we convert to Cloud Pak during a migration?
Not as part of the same decision. Cloud Pak VPC conversions repriced workloads 20 to 40 percent above PVU baselines in our reviews, and taking the decision inside a migration window means evaluating it against project urgency rather than its own arithmetic.
Why is the conversion conversation raised during migrations?
Because the estate is already moving and the bundle is presented as the modern way to run it. That framing is reasonable and it is not a pricing argument, which is why the two decisions should be separated in time.
Do virtual cores count the same on cloud?
Not necessarily. The counting basis on the target platform has to be confirmed before the move rather than assumed from the source estate, because a metric that behaved one way on premises can behave differently on a cloud host.
Who should own licensing in a migration?
A named person inside the migration plan. Treating it as a compliance review that happens afterwards guarantees that instrumentation gaps and counting changes are discovered after the architecture is fixed and the project has closed.
When should we audit the position?
At 60 days post cutover rather than 90. The exposure window closes before anyone would normally look, so the check has to be scheduled deliberately and earlier than instinct suggests.
Does a clean pre migration position protect us?
Only if it survives the move. That is the finding: estates with genuinely clean compliance positions became exposed inside a quarter, not through any decision to cut corners, but because nothing in the migration tested whether the conditions still held.
The IBM Audit Is the Sales Call: Timing and ILMT Hygiene Decide It
Sub capacity entitlement is conditional on evidence, not on deployment. A missing metric report converts a sub capacity estate into a full capacity bill, and it arrives on the vendor's calendar.
