Audit risk after a failed IBM cloud migration.
When a cloud migration stalls or reverses, the software rarely comes back to a clean state. Instances run in two places, ILMT coverage breaks across the move, and the entitlement still reflects the plan rather than the reality. That gap between intended and actual is exactly what an audit prices.
Migrations fail in the middle, not at the edges
A migration that completes cleanly is easy to license. The problem is the one that halts halfway, gets paused for a budget cycle, or is rolled back after a production issue. In each case the software ends up running in both the source and the target for a period, and sometimes indefinitely. The entitlement was sized for one footprint, the deployment now spans two, and the difference sits unlicensed until someone reconciles it.
This is a capacity problem first. Processor value units count cores wherever the software runs, so a product live in the old data center and the new cloud target at once is consuming against two sets of cores. If the project plan assumed the source would be decommissioned on a date that slipped, the licensed position quietly fell behind the day that date passed.
Where the exposure hides
- Double running. Source and target both live during an extended cutover, doubling the licensable cores for that window.
- Broken ILMT coverage. Agents that tracked the on premises hosts may not have followed the workload to the cloud target, voiding sub capacity for the migrated instances.
- Ineligible target technology. A cloud or hypervisor environment that does not meet IBM's sub capacity eligibility defaults the target to full capacity.
- Orphaned instances. Rolled back workloads that were never fully removed keep consuming entitlement no one is watching.
- Stale entitlement records. The license position still describes the intended end state, not the half migrated reality an auditor will measure.
Reconcile the reality, not the plan
The defensible move after a failed migration is to license the estate as it actually exists, not as the project intended it to look. That means mapping every live instance in both environments, confirming ILMT is reporting on the cloud target and not just the origin, checking that the target technology is sub capacity eligible, and removing instances that were supposed to be gone. Only then can the position be reconciled against entitlement with confidence. A migration that is documented as incomplete and licensed honestly is far easier to defend than one that is presented as finished when the source is still running.
IBM does not audit your migration plan. It audits the cores that are actually running, in both the place you were leaving and the place you were moving to. A stalled or reversed migration usually means double footprint and broken ILMT coverage, which reads as full capacity exposure. Reconcile the real estate, restore agent coverage across the move, and the half finished project stops being a finding.
Migration stalled with software running in two places?
Our Audit Defense engagement maps the real estate across both environments, restores the ILMT trail, and builds a licensed position that matches reality. We mobilize within 48 hours of an audit notice.
See Audit Defense →The IBM Audit Brief
Audit triggers, ILMT pitfalls, and settlement tactics for IBM software buyers.
Independent, buyer side IBM software audit defense and negotiation. Not affiliated with IBM Corporation.