Step-by-step Procedure for Cutover of Windows Disks

Step-by-step Procedure for Migration and Cutover of Windows Physical Disks

Note: This procedure is for migration of Windows server physical disks visible in Computer Managers’ Disk Manager. These disks are NOT managed using Storage Pools managed by Server Manager’s File and Storage Services Tool. For migration of Storage Pool disks, consult KB HOWTO: Cirrus Migrate Cloud - Migrate Windows Storage Pool

Create a Migration Session after selecting one or multiple source disk (not the boot disk) and pairing each with a new destination disk. Both the source disk and the destination disk should be listed in the Disk Manager as a physical disks. The picture below shows source Disk 1 and Disk 2 being migrated to destination Disk 3 and Disk 4 respectively. Keeping Disk 3 and Disk 4 offline is best practice, as it helps to prevent accidental usage before migration is done.

When the initial sync of the disk is complete (100%), the status becomes "Tracking Changes". It is ready for the next step for cutover. At this point, the Source Disks are not yet masked, and the Destination Disks are masked, indicated by an “Unallocated” Partition Type shown above

The “Tracking Changes” state can be maintained indefinitely until there is an application downtime window to complete the cutover. For cluster disks, the downtime can be avoided using the Cluster Cutover Procedure HOWTO: Migrate a Microsoft Windows Cluster Workload without Downtime. For non-cluster applications, wait for available downtime window for the next steps.

When downtime is available for final cutover, at CMC Project->Migration Session page, use the red "SESSION ACTIONS" button to "Trigger cMotion". Application I/O at the source is now redirected to the Destination Disks. At this point, the destination disk is being updated while the source is no longer. This can be reverted using the “SESSION ACTIONS” button to select “Revert cMotion” if there is a reason to undo the cMotion. After cMotion, both the Source and Destination Disk are masked, but source continues to be accessible through redirection to the destination. Other than for cutover of cluster disks, proceed immediately to the next step to complete the cutover.

Use "SESSION ACTIONS" button to trigger "Finalize Cutover". This will unmask (descramble) the Destination Disks. The Destination Disks at this point are still offline but are actually being updated by the Redirection process of CMC. The source disk is still redirected to the destination disk, making the Source disk accessible logically but the underlying physical disk is no longer updated when cMotion was triggered back in step 3 above. Proceed to Step 6. It is worth noting that it is perfectly normal to stay at this state for extended period of time while waiting for Application downtime in order to perform step 6 and beyond. This allows the new disk, presumably faster and more reliable, to be put into production use prior to having downtime. In this state the source disk is completely bypassed due to redirection to the Destination. At this point, a reboot of the system, intentional or not, will result in the source disk being inaccessible (due to masking) and the destination disk being accessible and assigned the same drive letter once the system boots up. If a reboot should happen, the redirection will no longer be active when the system boots up. Clean up by deleting the migration session and skip to step 8 below if this should happen.

In the case were the host is left in this state for prolonged period of time, it is important that the Source disk, although being bypassed, remains connected to the host. For some tested environments, the Source disk can be detached and removed (for cost savings and other benefits) from the host without causing any outage. Currently no Windows environment nor VMware environment can support this capability. It is mandated that you test the specific environment and disk type to verify no storage is encountered before using this feature.

Offline the application, and offline the source disks using Disk Manager.

Note: If the disk has a Page File, it is not possible to offline the disk. For these disks, the only way to cutover is to reboot after application is offline/stopped. After the reboot, all the disks in the migration session are transitioned to the final state of: Source disks are masked and Destination disks are unmasked and online with the appropriate drive letter. The migration session is no longer active after the reboot and is in the "Completed" state.

Use "SESSION ACTIONS" button to trigger [Complete Session]. This stops the redirection without having to reboot.

If the source disks were externally attached disks, remove/detach them.

Rescan the disks at Disk Manager level. The source disks will disappear, while the destination disks will appear to have valid partition information.

Online the destination disks if not automatically done so. The appropriate drive letters will be automatically associated with each migrated disk.

Note: After the above migration and cutover procedure, the Source Disks are masked and no longer appear to have a partition (became "Unknown"). The data is still on the disk. If you wish to access the disks, see article How to Unmask a Disk that is Masked by CMC Migration.

Updated on: 19/12/2022

Was this article helpful?

Share your feedback


Thank you!