Microsoft's October 19, 2026 announcement makes Large OS Disk Encryption generally available for Azure Confidential VM migration scenarios. It extends confidential OS-disk encryption to migrating workloads with operating-system disks larger than 127 GB. Microsoft announcement.
For a migration team, this removes one eligibility obstacle. The useful next review is whether the exact source machine, target configuration, and key-management plan form a supported migration path.
Read the Large-Disk Key Requirement
Azure Migrate's current guidance states that confidential OS-disk encryption for disks larger than 127 GB requires customer-managed keys. It also says encryption can increase initial target creation time during hydration. The same section treats data-disk protection separately; it does not extend confidential encryption to data disks. Azure Migrate encryption requirements.
My migration record would give the key dependency its own owner and acceptance criteria. Identify who controls the approved key configuration and who can diagnose a failure involving that dependency.
Keep the chosen encryption settings alongside the target VM definition. A label such as confidential migration is too broad to document which disk protections were actually selected.
Check the Exact Operating-System Version
The support page lists Windows Server 2019 and 2022, Ubuntu 20.04, 22.04, and 24.04 LTS, and RHEL and Rocky Linux 9.4, 9.5, and 9.6 for migration to Confidential VMs. Confirm the live support matrix before planning a move. Supported operating systems.
I would retain the source inventory used for the decision and record when it was collected. Recheck any machine that receives a significant configuration change after assessment.
Track exceptions individually. One compatible test server should not become approval for every machine carrying the same application name.
Have the application owner review the proposed test target. That catches differences between an easy-to-migrate specimen and the configuration that actually supports the business service.
Rehearse With a Representative Disposable Copy
My proposed pilot would use a disposable copy containing synthetic or otherwise approved test data, with a disk layout representative of the intended source.
Define application acceptance before starting the move. Include a known transaction, an expected result, and the external dependencies needed to produce it.
Record the major elapsed stages separately so the team can distinguish target creation from application readiness. Use the observed rehearsal evidence when planning the change window rather than borrowing a duration from another migration.
Preserve failed attempts in the report. A later successful run is more useful when reviewers can see what changed and why it addressed the earlier failure.
Test Recovery Ownership Alongside Startup
I would ask the team to rehearse its approved response to a failed migration before changing a production machine. Name the person who decides whether to continue, investigate, or recover the original service.
Keep the source and destination state explicit in the runbook. Responders should know which system is authoritative at each stage and which action would create an inconsistent business result.
Test the application's required operational tooling on the representative target. Monitoring, maintenance, and recovery procedures deserve their own evidence rather than inheriting a pass from the first successful boot.
Make any unverified recovery step visible in the approval record. That gives the service owner an accurate account of the remaining work.
Validate the Business Result After the Move
My acceptance review would compare known input records with the target application's output. Select cases that exercise the important business paths and preserve the expected results before testing.
Include the operators who will support the service after cutover. Have them use the proposed diagnostics to explain one deliberately failed test case.
Retain the final source assessment, target settings, key dependency, and application checks together. This creates a repeatable decision record for the next eligible workload.
Practical Cloud Engineer Takeaway
Check the large-OS-disk customer-managed-key requirement.
Match exact OS versions to the current support matrix.
Rehearse a representative disk layout and application task.
Record timing, failed attempts, and recovery ownership.
Verify operational readiness and business results separately.
Who Should Care?
Azure migration engineers, Confidential Computing architects, and application owners moving established workloads with larger OS disks.
Bottom Line
The GA update expands the migration option. The adoption decision still depends on a supported source, the required key configuration, and an application that passes the team's agreed checks.
No source machine was assessed, key permission changed, disk encrypted, VM migrated, or recovery test performed for this article.
Sources
Stay radical, stay curious, and keep pushing the boundaries of what is possible in the cloud.
Chriz
Beyond Cloud with Chriz
Comments