A disk conversion can finish successfully and still leave you with a guest asking for a BitLocker recovery key. That's why the vTPM needs to show up in the migration checks.
01 / Why it matters
The TPM state doesn't move with the disks.
BitLocker, measured boot or an application may depend on the source vTPM. Copying the VMDKs doesn't copy that device's state. A new vTPM on the destination won't have the old keys or satisfy the same attestation checks just because the disks are there.
02 / What changed
A warning on the affected VM.
Inventory records whether a source VM has a vTPM. Preflight then shows a warning against that VM, so you can see which guest needs attention.
V2K Migrate does not copy source vTPM state, certificates, sealed objects or key material. If a destination integration provisions a vTPM, it is a new, empty device.
This is a warning, not an automatic block. Having a vTPM doesn't necessarily mean the guest needs it to boot. That still needs checking inside the guest.
03 / Before cutover
What to check.
- 01Is the guest using it?
Check BitLocker, measured boot and any application keys tied to the TPM.
- 02Are the recovery keys available?
Verify the BitLocker recovery keys and your recovery procedure before shutting down the source.
- 03What does the destination need?
Plan for a new vTPM where needed, including re-enrolment or re-protection of the guest.
- 04Does the migrated guest work?
Check boot, access to protected volumes and the security controls you expect to use.
04 / What's included
Detection, not TPM migration.
Discovery and the preflight warning are implemented. Automatic recovery of TPM-protected workloads is not part of this change.