Upgrading to VCF 9.1 from vSphere + Aria + NetApp ONTAP: The Storage-Specific Migration Guide

This is Part 10 of an architect’s read of VCF 9.1, and the first of four vendor-specific migration guides. Part 8 covered the general vSphere + Aria → VCF 9.1 migration journey. This one is for customers running NetApp ONTAP-backed estates AFF, ASA, FAS, and ONTAP Select who need the storage-specific overlay on top of the general migration.

NetApp customers tend to be among the deepest VMware integrators. Years of ONTAP Tools (formerly Virtual Storage Console), SnapCenter for application-consistent backup, vVols for fine-grain VM storage policy, SnapMirror replication, MetroCluster for active-active stretched clusters, and Trident CSI for Kubernetes all of this represents real architectural investment. The migration to VCF 9.1 needs to preserve it where possible, plan for changes where required, and address the vVols deprecation that hits NetApp customers particularly hard.

Source state: what NetApp + vSphere customers run today

The typical source state:

• vSphere 7.x / 8.x with vCenter, ESXi hosts, vSphere Lifecycle Manager

• NetApp ONTAP storage AFF (All-Flash FAS), ASA (All-SAN Array), FAS, or ONTAP Select

• ONTAP Tools for VMware vSphere (OTV, formerly Virtual Storage Console) for storage integration

• Datastores across NFS v3/v4.1, iSCSI VMFS, FC VMFS, NVMe/FC, NVMe/TCP, and/or vVols

• SnapCenter Plugin for VMware vSphere for application-consistent VM backups

• SnapMirror for replication SnapMirror Active Sync (synchronous, zero RPO), SnapMirror DR (asynchronous), or SnapMirror Cloud

• MetroCluster (FC or IP) for active-active stretched clusters across data centres

• Aria Operations for monitoring, often with the NetApp Management Pack

• Trident CSI for any Kubernetes workloads consuming ONTAP storage

• BlueXP NetApp’s SaaS-based hybrid cloud control plane (Backup and Recovery, DRaaS, Connector)

What VCF 9.1 changes for NetApp customers

The headline architectural points that NetApp customers need to internalise:

VCF 9 supports VMFS on FC and NFS v3 as primary datastores natively. In earlier VCF versions, the Management Domain required vSAN as principal storage. In VCF 9, you can deploy the Management Domain on VMFS on FC or NFS v3 no vSAN required. For NetApp customers, this is significant: an ONTAP-backed Management Domain is now a supported, natively-installable configuration.

Other protocols require the existing-vCenter path. If your design needs iSCSI VMFS, NVMe/FC, NVMe/TCP, or vVols on ONTAP, you don’t deploy them from scratch through the VCF Installer. Instead: deploy vCenter 9 and vSphere 9 first, install ONTAP Tools, provision the datastores, then run the VCF Installer with the existing-vCenter option to bring it into VCF management. The Installer detects the pre-configured environment and brings it under VCF.

vVols are deprecated and being retired. This is the big one for NetApp customers. vVols deprecation begins in VCF 9.x with full removal coming in a later 9.x release (industry signals point to VCF 9.3 as the formal termination release). NetApp customers running Oracle, SAP, or SQL Server on vVols-backed datastores typically with SnapCenter for application-consistent snapshots and SnapMirror for DR need a migration plan to VMFS, NFS, or NVMe/FC equivalents before that release lands.

Storage policy model still works. ONTAP Tools provides Storage Capability Profiles that VCF and vSphere Supervisor consume via Storage Policy Based Management (SPBM). Datastores provisioned by ONTAP Tools (NFS, VMFS, NVMe) can be consumed by Supervisor and VKS, including datastores protected by SnapMirror Active Sync. The SPBM model survives the migration.

Stretched cluster design is preserved with protocol limits. MetroCluster is supported as the stretched-cluster solution for NFS v3 deployments. SnapMirror Active Sync is supported for VMFS on FC. For VCF 9.x stretched topologies, this is the supported NetApp-side architecture. Customers running MetroCluster today can preserve the design through the migration; customers running stretched vVols need to re-platform.

Migration paths for NetApp customers

The three migration paths from Part 8 (Convergence, Brownfield Import, Side-by-side) apply, but the path choice for NetApp customers is shaped by the storage protocol mix and the vVols footprint:

Path A: Convergence with VMFS-FC or NFSv3 only. If the source estate uses only VMFS on FC or NFS v3 datastores on ONTAP, the convergence path from Part 8 works cleanly. vCenter and ESXi hosts upgrade to v9, then convergence brings vCenter into the VCF Instance Management Domain. Datastores remain mounted. ONTAP Tools continues to manage the ONTAP integration. SnapCenter Plugin for VMware vSphere continues to handle backup workflows.

Path B: Brownfield Import for non-vSAN, non-FC/NFSv3 protocols. If the source uses iSCSI VMFS, NVMe/FC, NVMe/TCP, or any non-standard protocol, the Brownfield Import path is cleaner. Deploy a new VCF 9.1 instance with its own Management Domain (on vSAN, NFS, or FC). Stand up the existing ONTAP-backed workload domain via Brownfield Import. ONTAP Tools and SnapCenter continue managing the storage. The Management Domain runs on its own substrate; tenant workloads stay on ONTAP.

Path C: Side-by-side with vVols migration. If the source estate is heavily invested in vVols typically NetApp customers with Oracle / SAP / SQL on AFF or ASA arrays using SnapCenter for application-consistent backup the side-by-side path is often the right choice. Build VCF 9.1 fresh on a chosen primary datastore type (FC VMFS or NFS), provision new ONTAP datastores in the supported protocols, and migrate workloads via Storage vMotion or HCX. vVols workloads either move to VMFS/NFS or stay on the source estate until natural workload refresh retires them.

The vVols problem in detail and how NetApp customers should handle it

vVols deprecation hits NetApp customers harder than most because of how deeply integrated ONTAP’s vVols implementation is with SnapCenter and array-based services. The migration considerations:

• Inventory all vVols datastores and the workloads on them

• For each workload, identify the dependency: which features rely on vVols-specific behaviour? Per-VM array snapshots? Per-VM array replication? Storage Policy Based Management at the VM level?

• Plan migration target: VMFS on FC (block, traditional), NFS v3 / v4.1 (file, fast migration), or NVMe/FC (block, modern)

• Migrate via Storage vMotion (Change storage only) from vVols to target datastore type

• Replicate SnapCenter backup policies for the new datastore type SnapCenter supports NFS, VMFS, and NVMe datastores, but the backup mechanics differ between datastore types

• If Oracle / SAP / SQL on vVols: SnapCenter integration with the new datastore type needs validation application-consistent snapshots and clones work differently between vVols and traditional datastores

• If SnapMirror Active Sync was running on a vVols datastore: re-architect to SnapMirror Active Sync on VMFS-FC, which is supported under VCF 9.x for stretched clusters

Treat vVols migration as a parallel workstream, not part of the core VCF migration. The application-consistent backup, snapshot, and clone workflows that SnapCenter delivers are valuable and need careful validation on the new datastore type before the source vVols-backed workloads are decommissioned.

The ONTAP Tools transition

ONTAP Tools for VMware vSphere (OTV) is the management plane for ONTAP storage integration into vSphere and VCF. NetApp evolved OTV from the 9.x release line into the 10.x line:

• OTV 9.12D1, 9.13D2, 9.13P2 are the migration source versions

• OTV 10.x is the current line, with full vSphere 9 / VCF 9 support

• Customers on OTV 9.xx without vVols datastores: simple uninstall of OTV 9 + deploy OTV 10

• Customers with vVols datastores: dedicated migration procedure for the VASA Provider and SRA

• OTV 10.x supports multi-vCenter registration important for VCF deployments with multiple workload domains

For HLD: plan OTV upgrade as a discrete step before VCF migration. The OTV upgrade itself is well-documented; the value is doing it before VCF migration so the storage integration plane is stable when the VCF mechanics start running.

VKS / Kubernetes considerations for NetApp customers

Customers running Kubernetes workloads on NetApp today typically use Trident CSI NetApp’s open-source CSI driver. In VCF 9.x with VKS, there are two paths:

Trident CSI on VKS. Continue using Trident for full NetApp feature parity ONTAP-native snapshots, clones, dynamic provisioning, NVMe support, replication awareness, and Trident Protect for application-consistent backup. Best when you need the full Trident feature set or already have Trident-based application catalogues.

vSphere CSI on VKS. Use VCF’s native vSphere CSI for tighter integration with VCF Operations persistent volume details surface in the VCF Operations UI, integrated lifecycle, single observability plane. Loses some NetApp-specific features but gains the VCF ecosystem integration.

Many customers run a mix: Trident for applications that need its features, vSphere CSI for general-purpose stateful workloads. The HLD should be explicit about which workloads use which CSI.

Backup and recovery transition

NetApp customers typically have SnapCenter for backup and BlueXP DRaaS or VMware Live Site Recovery for DR. In VCF 9.x:

• SnapCenter Plugin for VMware vSphere continues to work application-consistent backups, restores, clones, validation

• BlueXP Backup and Recovery extends protection to both VMs and Kubernetes resources via array-native features

• BlueXP Disaster Recovery as a Service handles cross-site DR for VMs

• VMware Live Site Recovery (the renamed Site Recovery Manager) is an alternative for site-level DR orchestration

• VCF 9.1’s vSAN Protection and Recovery (Part 6) can complement NetApp backup for management-domain VMs

• Cyber Recovery (Part 1) ACC + IRE sits alongside NetApp’s data protection rather than replacing it

For HLD: BlueXP and SnapCenter remain the primary data protection plane for NetApp-backed workloads. VCF’s native protection extends to vSAN-backed workloads and the management plane. Don’t architect a single tool for everything; layer them by what they do well.

HLD design patterns for NetApp + VCF 9.1

Pattern 1: All-NFS with MetroCluster. Management Domain on NFS v3 (deployed natively via VCF Installer). All workload domains on NFS. MetroCluster for active-active stretched cluster between sites. ONTAP Tools managing the storage. Trident CSI or vSphere CSI for VKS. Familiar operations model for NetApp shops with strong NFS roots.

Pattern 2: All-FC with SnapMirror Active Sync. Management Domain on VMFS on FC (deployed natively via VCF Installer). Workload domains on VMFS-FC. SnapMirror Active Sync between sites for synchronous replication and active-active operation. AFF or ASA arrays. Suitable for customers with mature FC fabrics and SAN-centric operating models.

Pattern 3: Mixed FC + NFS. Management Domain on the protocol of preference. VMFS-FC for performance-sensitive workloads (databases, virtual desktops at scale). NFS for file-friendly workloads (general-purpose VMs, dev/test). ONTAP’s multi-protocol nature is a real strength here same array, different protocols, different workload classes.

Pattern 4: NVMe-over-Fabrics for high-performance. NVMe/FC or NVMe/TCP datastores for the highest-performance workloads. Deployed via the existing-vCenter path (OTV configures the datastores; VCF picks up the configured vCenter). Suitable for AI training data pipelines, large databases, and other latency-sensitive workloads.

Pattern 5: Migration-period hybrid (NetApp + vSAN). vSAN-based Management Domain for the new VCF 9.1 instance. NetApp-backed workload domains added via Brownfield Import. Migration of vVols-backed workloads happens incrementally to NetApp NFS or VMFS-FC datastores. Eventually the design lands on a stable NetApp-only or NetApp + vSAN topology, but the migration period itself accepts the hybrid.

Common HLD/LLD anti-patterns

Trying to bring vVols datastores through unchanged. The deprecation is real and the timeline is finite. Plan vVols migration as part of the VCF migration, not after.

Skipping the OTV upgrade. OTV 9.xx is the source; OTV 10.x is the target. Doing the OTV upgrade before VCF migration stabilises the storage management plane.

Forgetting SnapCenter validation on the new datastore type. Application-consistent backup mechanics differ between vVols, VMFS, NFS, and NVMe. Validate SnapCenter behaviour on the target datastore type before cutting over production workloads.

Mixing Trident and vSphere CSI without a plan. Both can coexist, but mixing them on the same workload class creates operational complexity. Pick which CSI for which workload class and stick to it.

Treating BlueXP DRaaS and VMware Live Site Recovery as interchangeable. They’re different products with different feature sets. BlueXP DRaaS is NetApp-centric and SaaS-delivered; Live Site Recovery is VMware-centric and on-prem-orchestrated. Choose deliberately.

Ignoring the multi-vCenter OTV requirement. If the VCF design has multiple workload domains (multiple vCenters), OTV needs to be registered to each. Plan this from the HLD.

Underestimating MetroCluster’s configuration constraints. MetroCluster has specific latency, link, and configuration requirements that interact with VCF’s own stretched cluster requirements. Validate both sets of constraints in the LLD.

Not using NetApp’s feature differentiation post-migration. Once on VCF 9.1, NetApp’s features storage efficiency, FlexClone, multi-protocol, advanced replication, BlueXP integration still differentiate vs vSAN. Architect for them, don’t commoditise the storage layer.

Decision framework: NetApp customer paths

• Source uses only VMFS-FC or NFSv3, no vVols, single vCenter → Convergence (Path A)

• Source uses iSCSI, NVMe/FC, NVMe/TCP, no significant vVols → Brownfield Import (Path B)

• Source has substantial vVols + SnapCenter workflows → Side-by-side (Path C), with parallel vVols migration

• Source has MetroCluster active-active stretched NFSv3 path preserved; vVols stretched re-platformed

• Source has Oracle/SAP on vVols with SnapCenter highest scrutiny; pilot SnapCenter on VMFS-FC or NFS first

• VKS workloads with Trident dependencies plan Trident-on-VKS pattern up front

• BlueXP-centric data protection confirm BlueXP version compatibility with VCF Operations 9.x

Closing

NetApp + VCF 9.1 is a well-supported combination. ONTAP’s multi-protocol breadth, BlueXP’s SaaS-delivered data services, and SnapCenter’s application-consistent protection all translate cleanly into the new platform with the explicit exception of vVols, which needs a migration plan. The architecture decisions sit in the protocol mix, the stretched-cluster topology, the CSI choice, and the data-protection plane integration.

For my own design reviews with NetApp customers, the questions I work through every time:

• Is the source protocol mix VMFS-FC + NFSv3 only, or does it include vVols, iSCSI, or NVMe variants?

• If vVols are in use, what’s the migration target VMFS-FC or NFS and what’s the SnapCenter validation plan?

• What stretched-cluster topology is in use MetroCluster NFSv3 or SnapMirror Active Sync VMFS-FC?

• OTV upgrade plan from 9.xx to 10.x before or during VCF migration?

• Trident CSI vs vSphere CSI for which workload classes?

• BlueXP and SnapCenter compatibility with VCF Operations 9.x?

• SnapMirror replication scope does the VCF 9.1 management plane affect any replication relationships?

• Cyber Recovery layering NetApp protection + VCF ACC/IRE complementary, not competing?

Get those answered and the NetApp + VCF 9.1 HLD writes itself.

That closes Part 10 the NetApp-specific overlay on the VCF 9.1 migration journey. Parts 11, 12, and 13 cover the same migration journey for Pure Storage, Dell, and HPE customers respectively.

Sources

• VCF 9 Storage Options (NetApp Community)

• Simplify Hybrid Cloud Experience with VMware Cloud Foundation and ONTAP (NetApp)

• Configure NFS vVols Storage in a VCF VI Workload Domain Using ONTAP Tools (NetApp)

• Configure iSCSI vVols Storage in a VCF VI Workload Domain Using ONTAP Tools (NetApp)

• Configure NVMe/TCP vVols Storage in a VCF VI Workload Domain (NetApp)

• vVols as Supplemental Storage for Workload Domains (NetApp)

• Migrate from ONTAP Tools for VMware vSphere 9.xx to 10.5 (NetApp)

• Migrate Virtual Machines with NFS and VMFS Datastores to vVols Datastores (NetApp)

• Oracle SI Deployment and Protection in VCF with vVols (NetApp TR-4996)