Virtual machine migration is the process of moving a running or powered-off virtual machine from one host, cluster, or storage location to another. It is used in virtualised infrastructure for maintenance, load balancing, fault recovery, and hardware refresh, while preserving the guest operating system, its memory state, and attached virtual devices as required.
What Virtual Machine Migration Means in Practice
virtual machine migration is the controlled relocation of a VM between compute or storage locations while preserving its runtime state and service continuity. In practice, it is a core virtualisation capability for maintenance, scaling, resilience, and hardware lifecycle work.
Its significance is architectural, not just operational: migration changes where trust, availability, and performance are anchored, even when the guest operating system remains unchanged. That makes it a routine admin function with security consequences for isolation, access paths, and monitoring.
Where Migration Fits in Virtualised Infrastructure
Migration can be live, with the VM continuing to run during transfer, or cold, with the VM powered off before movement. It may involve moving only execution state, or also moving storage dependencies and network placement, depending on the platform and the maintenance goal.
Because the VM is a packaged workload rather than a physical server, migration is often used to rebalance capacity, evacuate a host for patching, recover from hardware failure, or reposition a workload closer to the resources it needs. The process therefore sits at the intersection of orchestration, storage, networking, and hypervisor control.
For a broader view of the surrounding control plane, the Hypervisor and Virtualisation Security Guide explains the isolation, management-plane, and detection concerns that shape migration security.
Why Migration Creates Security and Resilience Dependencies
Migration is only as trustworthy as the control plane that performs it. If an attacker can reach the management plane, alter orchestration, or observe migration traffic, they may gain a path to workload exposure, tampering, or denial of service, especially where live migration or shared storage is involved.
It also creates dependency risk: the process may rely on privileged administrative access, compatible hypervisor versions, synchronized storage, and stable network paths. When those assumptions fail, migration can stall, corrupt availability expectations, or leave workloads stranded in an unexpected state.
For encrypted or confidential VM designs, migration also depends on how memory, keys, and attestation are handled during transfer. The Confidential Computing Guide is useful when migration must preserve protection for memory-resident data across trust boundaries.
Operational Controls and Review Points
Migration should be planned as a change to both the workload and the surrounding trust boundary. That means validating who is allowed to initiate it, what networks carry it, how it is logged, and whether the destination host or cluster matches the workload’s policy and isolation requirements.
After migration, teams should confirm that the VM landed where intended, that identity- and policy-based access still reflect the new placement, and that any snapshots, temporary routes, or stale host registrations were cleaned up. These are common places where drift accumulates even when the migration itself succeeds.
For recovery and operational continuity scenarios, the ESXi Ransomware Playbook is relevant because it shows how host movement, recovery routing, and management-plane containment interact during infrastructure disruption.
If the migration is part of a broader admin workflow or remote execution chain, the T1651 Cloud Administration Command Defensive Guide helps frame the detection problem around delegated control paths rather than just the VM itself.
Common Failure Modes to Watch For
Migration can fail in ways that are operationally subtle but security-relevant: partial transfers, stale attachments, mismatched network segmentation, unexpected exposure on the destination host, or incomplete cleanup of source-side state. In large estates, these issues are often amplified by automation, where a broken assumption can affect many VMs at once.
Another frequent issue is false confidence after the move. A VM can appear healthy while inherited permissions, monitoring coverage, backup placement, or segmentation no longer match the new environment. That is why migration is best treated as a control boundary change, not simply a movement event.
Where migration is used during recovery, maintenance, or incident containment, the destination state should be verified as carefully as the source state was decommissioned.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 sets the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | CM-3 — Configuration Change Control | VM migration is a controlled infrastructure change that must be authorised and tracked. |
| AC-6 — Least Privilege | Migration depends on privileged admin access that should be tightly limited. | |
| SC-7 — Boundary Protection | Migration traffic and destination placement affect the workload's trust boundary. | |
| Recommendation — Authorise and record migration changes before moving production VMs. Restrict migration privileges to the smallest admin set needed. Segment migration paths and protect the networks carrying VM transfer traffic. | ||
| ISO/IEC 27001:2022 | A.8.9 — Configuration management | Migration changes the runtime configuration and placement of virtual assets. |
| Recommendation — Control and review virtualisation configuration changes before and after migration. | ||
Related resources from NHI Mgmt Group
- Why do machine identities matter in PQC migration planning?
- How do teams know a machine-identity migration is actually working?
- How should organisations build a partner-led approach to post-quantum cryptography migration across cloud, AI, and machine identities?
- What breaks when virtual machine backup is too dependent on agents inside the workload?