--- title: vSAN Migration Guide url: https://www.vmware.com/docs/vmw-troubleshooting-vsan-performance --- # vSAN Migration Guide Recommendations for vSAN in VMware Cloud Foundation 9.1 September 30, 2026 ## Table of Contents - Introduction - Scope of Topics - Scope of Migration - Concurrent vMotion Operations - Network Limitations - Capacity - Small versus Large Migration Efforts - Migration Options - Migration Types - Hot Migrations - Cold Migrations - Common Preparation Steps - Preparing for Migrations - Migrating across Management Boundaries - Migrating from vSAN to vSAN - Migrating from existing vSAN OSA to ESA - Migrating from VMFS/NFS to vSAN - Migrating RDMs to vSAN - Refreshing an Existing vSAN Cluster with New Servers - Migrating Physical Machines to vSAN - Summary - Additional Resources - About the Author ## Introduction Migration of data from other storage systems to vSAN is relatively easy. This guide will provide an outline and recommendations on what migration options may work best depending on the conditions. These recommendations will apply to vSAN clusters in both VMware Cloud Foundation (VCF) environments and non-VCF environments. The considerations and recommendations will apply to aggregated vSAN HCI clusters as well as disaggregated vSAN storage clusters. Additional recommendations can be found on the blog post: “Migrate to VMware Cloud Foundation 9.0 Storage.” In vSAN for VCF 9.1, improvements with mounting remote datastores between OSA and ESA clusters, as well as multi-source replication capabilities offer new ways of migrating your data. ## Scope of Topics This document provides details on how to migrate workloads and data from various storage systems to vSAN. The information in this guide will provide a general overview of migration strategies and is not intended to be a step-by-step guide. The concepts discussed in this document generally apply to a standalone vSAN environment, as well as a VCF environment. For VCF environments, please refer to the Administration Guide for VMware Cloud Foundation for guidance on specific migration steps as they relate to VCF. ## Scope of Migration Assessing the overall scope of a migration will help determine the best tool to use, as well as other planning logistics. Understanding limitations in the physical infrastructure and software will help determine the best path forward for your migration efforts. ## Concurrent vMotion Operations vMotion will manage the “batching” of VMs that will be transferred. This helps with an orderly transfer, and end-state if for some reason the task stops or is cancelled. The number of concurrent vMotion operations will be dictated by the version of vSphere and vCenter server used. For more information, see: “vCenter Server Limits on Simultaneous Migrations.” ## Network Limitations Network throughput and latency will impact the rate that data can be transferred. When thinking about migrations, the effective bandwidth from the source to the destination will be important for speedy transfers of large data payloads. ## Capacity Any migration of data from a source location to a destination location assumes sufficient free capacity at the destination. Since earlier versions of vSAN (prior to vSAN in VCF 9.1) presents storage capacity differently than traditional storage arrays, one should factor in the additional space that may be needed for the prescribed levels of resilience applied using storage policies. For more information, see the post: “Demystifying Capacity Reporting in vSAN.” The new “Auto-RAID” and “Effective Capacity” view in vSAN for VCF 9.1 will make this effort much easier, as it takes care of the resilience and overhead considerations for you. ## Small versus Large Migration Efforts While the procedures for large migration efforts reflect that of small migration efforts, there are additional considerations that may impact plans to migrate vast numbers of workloads in a consistent, reliable and repeatable manner. With large numbers of VMs, additional factors may need to be considered, including: - Transmission bandwidth capabilities - Available storage capacity at the target - Decisions on resilience levels for the VMs migrated to vSAN. - Orchestration of large numbers of VMs phased in a manner that reflects business or organizational requirements. - Minimizing performance impacts of VMs during the migration processes. - Testing of a subset of migrated VMs for verification. These elements may also apply to smaller migration efforts but tend to amplify in their impact with large migrations. Large migration efforts may benefit from steps that can be easily repeated for consistency at a large scale. This may impact the tools that are used for the migration activities, such as using PowerCLI, etc. **Recommendation:** Perform a ‘pilot migration’ to test and validate your larger scale migration plan. This will help sort out any outstanding issues prior to larger migration effort. ## Migration Options In a vSphere or vSAN powered infrastructure, the most common methods of migration include but are not limited to: - VMware vSphere vMotion - VMware HCX - VMware Site Recovery - Third party backup and restore processes The most common and easiest method of migrating workloads to vSAN is using vMotion. Migration of workloads and data can be achieved through incremental steps of compute vMotion, Storage vMotion, or a combined shared-nothing vMotion. This migration guidance can even be used when more than one vCenter Server is used for managing the source location and the destination location. Cross-vCenter vMotion may have additional requirements and limitations. While third-party options and solutions, such as backup, recovery, and replication are valid options; those items are out of scope for this document due to the differences in solutions, extra cost and resources involved to deploy, configure and implement. ## Migration Types Virtual Machines and their data typically are migrated in one of two ways: Hot migrations, and cold migrations. The two options are discussed in more detail below. ### Hot Migrations Hot migrations, or live migrations represent conditions where data may change during the migration. An example would be VMs that are powered on, with applications and the data they serve fully available. This is commonly achieved through vMotion, but could also be done using HCX, since it uses vSphere Replication for the transport method. ### Cold Migrations Cold migrations represent conditions where data will not change during the migration. An example would be VMs that are powered off . This can be performed manually, or with a scheduled task. This is also commonly achieved through vMotion, but it is not the only option available. Note that vMotion has improved dramatically over the past several years, with improvements in performance and reduced stun times. With these improvements come changes in vMotion behavior, potential affecting how the data is transferred, and what networks it is using for the transfer depending on if it is a hot migration or a cold migration. For more information on networking characteristics and requirements of vMotion, see KB article ID: 342209 – Understand vMotion Networking Requirements. ## Common Preparation Steps ### Preparing for Migrations Migrations from one cluster to another will require some basic prerequisites that will generally be applicable to all migration scenarios. This would include: - Licensing is applied to both the source and the destination clusters. - Synchronized time (using NTP) across all hosts that participate in the two environments. - Proper physical and logical network connectivity between source and destination clusters. - All appropriate VM port groups and VMkernel configurations used on the source cluster on destination cluster. - The appropriate Enhance vMotion Compatibility (EVC) setting on both clusters so that vMotion can take place. - Any advanced functionality such as DRS affinity rules are in place on the destination environment, to maintain consistent behavior. - Proper credentials and authentication if using more than one vCenter Server with more than one SSO domain. - Identify any VMs currently using iSCSI guest attached volumes and/or RDMs for any associated VMDKs with the VM, and determine the course of action for these VMs. - For the target vSAN cluster, verify that all vSAN health checks are in a passing, and that the cluster has undergone some of the basic testing suggested in “Performance Recommendations for vSAN ESA” and the vSAN PoC guides. If the workloads are migrated to a destination cluster that is newer version than the source cluster, one may need to update the VMTools and virtual hardware for those VMs when it is appropriate to do so. ### Migrating across Management Boundaries As the primary control plane for vSphere and vSAN clusters, a vCenter Server provides an authentication mechanism for logging into it as a resource. This component is known as a single sign-on (SSO) server. An SSO domain can contain one or more vCenter servers and is the element that determines if you are authenticated across a management boundary beyond a single vCenter server. When migrating data across SSO domains, additional prerequisites or configuration steps may be necessary. For more information, see: “Requirements for vMotion Between vCenter Server Instances.” ### Migrating from vSAN to vSAN **Migrating from existing vSAN cluster to a new vSAN cluster** The migration of data from an existing vSAN cluster to a new vSAN cluster is a relatively simple task. Assuming the basic preparation steps are taken, migration will consist of little more than a vMotion and storage vMotion. **Recommendation:** When transitioning to ESA, choose a destination storage policy that can store data in the most space efficient and resilient way. In ESA, this will be FTT= 2 using RAID-6 when it is a single site vSAN cluster. The new “Auto-RAID” capability in vSAN for VCF 9.1 will ensure that the optimal level of resilience is used based on the conditions of the cluster. Note that an existing vSAN cluster may have objects that are not readily or easily migrated because they are not seen by vCenter that is an entity that can be migrated in the same way that a VM is migrated. This would include objects that represent: - File shares courtesy of vSAN File Shares. - Block volumes courtesy of vSAN iSCSI services. - Block volumes courtesy of persistent volumes for containers. In these cases, other methods for migrating may need to be employed for these data types. ### Migrating from existing vSAN OSA to ESA vSAN does not provide a formal in-place “upgrade” that transitions an existing cluster from vSAN OSA to vSAN ESA. There are however strategies that can be used to migrate your existing workloads running on vSAN OSA clusters to vSAN ESA. The post: “Migrating to the Express Storage Architecture in vSAN 8” details two scenarios with multiple migration options that will help environments begin to transition away from vSAN OSA over to vSAN ESA. vSAN in VCF 9.1 introduces new flexibility in mounting datastores between OSA and ESA-based vSAN clusters. This significantly simplifies the migration efforts for many customers who have legacy vSAN OSA clusters, and would like to transition to vSAN ESA. For more information, see the post: “Greater Flexibility and Security with VMware vSAN Storage Clusters in VCF 9.1.” ### Migrating from VMFS/NFS to vSAN Migrating VMs from a VMFS or NFS datastore residing on a traditional storage array, or direct-attached-storage to a vSAN cluster will in most cases be a simple operation. Assuming the basic preparation steps are taken, migration will consist of little more than a vMotion and Storage vMotion. If the migration is from a traditional storage array to an aggregated vSAN HCI cluster, then both vMotion and Storage vMotion will need to occur. If the migration is from a traditional storage array to a disaggregated vSAN storage cluster, then a Storage vMotion is the only step that needs to occur, as shown on the illustration below. When using storage vMotion, there may be limitations in the number of concurrent sessions that can be established from the hosts on the source cluster to the destination vSAN cluster. This is a guardrail of storage vMotion, and not a limitation of vSAN. **Recommendation:** When transitioning to ESA, choose a destination storage policy that can store data in the most space efficient and resilient way. In ESA, this will be FTT= 2 using RAID-6 when it is a single site vSAN cluster. The new “Auto-RAID” capability in vSAN for VCF 9.1 will ensure that the optimal level of resilience is used based on the conditions of the cluster. In some cases you may have VMs that were using in-guest iSCSI attached volumes, or RDMs. In most cases, these are legacy configurations that are no longer needed. You will want to identify and address these VMs on a case-by-case basis. The vSAN Protection and Recovery (previously known as “vSAN Data Protection”) capabilities in vSAN for VCF 9.1 now supports multi-source replication. This can serve as a migration option when vMotion is not a viable option. The replication capabilities are provided through the Site Recovery add-on license, or the VMware Advanced Cyber Recovery (ACC) add-on license. ### Migrating RDMs to vSAN Historically, RDMs existed in virtual environments for a few reasons: - The perception that RDMs provide better performance than VMDKs on VMFS datastores. - Work around previous limitations of the maximum supported VMDK size. - Use as a shared-disk between two VMs to help determine quorum in clustered applications like Oracle, WSFC, etc. The first two reasons are no longer relevant. There is no performance advantage of RDMs versus VMFS, or RDMs versus vSAN. vSAN also supports VMDKs as large as 62TB, so there is no advantage there either. vSAN supports SCSI3-PR which can be a great alternative to RDMs for applications such as Windows Server Failover Clusters (WSFC) using a native VMDK. RDMs are considered a legacy technology and an artifact of previous infrastructures. Therefore, the use of RDMs is generally discouraged unless it is the only option available for a specific application. For application clustering with virtualized applications (such as WSFC and Oracle RAC) that require a quorum disk, it is highly recommended to use native VMDKs instead of iSCSI volumes. Oracle RAC can use native VMDKs using the multiwriter flag, and WSFC can use a native VMDK using SCSI3 persistent reservations. In vSAN for VCF 9.1, these shared VMDKs can be expanded without any application downtime through a new “hot-extend” capability. For more information, see the post: “Expand Shared VMDKs with Clustered Applications in VMware vSAN for VCF 9.1.” ### Refreshing an Existing vSAN Cluster with New Servers This type of migration provides a way for customers to refresh an existing cluster while preserving the existing cluster to maintain configurations or data services. For a detailed understanding of this migration method, see the post: “Refreshing and Existing vSAN Cluster with New Servers.” ### Migrating Physical Machines to vSAN VMware Converter supports the migration of physical Windows and Linux hosts, as well as VMs to a new virtual environment with minimal downtime to support shutdown and destination startup, as such this is an out-of-hours migration procedure. This support has been extended to vSAN and enables organizations to migrate their existing physical hosts direct to vSAN with no interim steps required. When using VMware Converter, choose the vSAN datastore as the target location for the converted machine. This will migrate to the datastore with the default vSAN storage policy. ## Summary The process of migrating data and workloads to vSAN can be achieved easily using tools that you are already familiar with. Proper planning will ensure that the consumers of the workloads in your environment will not be disrupted by any of the migration efforts. ## Additional Resources The following are a collection of useful links that relate to migration to vSAN HCI clusters and vSAN storage clusters: - Migrate to VMware Cloud Foundation 9.0 Storage. This blog post addresses considerations when migrating data from non-vSAN storage to vSAN. - vSAN Quick Questions – How do I Migrate VMs to a vSAN Cluster?. This video discusses many of the options in this document. - Performance Recommendations for vSAN ESA. This is a collection of recommendations to help achieve the highest levels of performance in a vSAN ESA cluster. Many of these same recommendations apply to vSAN storage clusters. - vSAN Proof of Concept (PoC) Performance Testing. This is a collection of recommendations that will guide users to test the performance of a vSAN cluster. While it is currently written for the OSA, many of the testing methods used are also applicable to the ESA. - Design and Sizing for vSAN ESA clusters. This post offers some nice guidance on using the vSAN Sizer for the ESA that summarizes some key points that can be found in the VMware vSAN Design Guide. - vSAN Network Design Guide. This network design guide applies to environments running vSAN 8 and later. - vSAN technical blogs. Stay up to date on the most recently published technical information about vSAN. These posts are created by the vSAN Technical Marketing team. - VMware Resource Center. The location for design guides, operations guides and other technical white papers on vSAN. These assets are created by the vSAN Technical Marketing and Product Enablement teams. - Official vSAN documentation. The location for all “how to” documentation on vSAN. ## About the Author Pete Koehler is a Product Marketing Engineer in the VCF division at Broadcom. With a primary focus on vSAN, Pete covers topics such as design and sizing, operations, performance, troubleshooting, and integration with other products and platforms.