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

This is Part 11 of an architect’s read of VCF 9.1, and the second of four vendor-specific migration guides. Part 10 covered NetApp. This one is for customers running Pure Storage FlashArray and FlashBlade-backed estates.

Pure customers are often deeply invested in VMware integration. Pure was the first storage vendor to certify VASA 5 and VASA 6 the API generations underpinning modern vVols and made vVols a core part of its VMware story for years. The vSphere Client Plugin gives Pure customers in-vCenter operations for provisioning, monitoring, and migration. ActiveCluster delivers synchronous active-active replication. ActiveDR handles asynchronous DR. CloudSnap provides cloud-tier backup. Stretched vVols was a Pure differentiator.

The migration to VCF 9.1 lands in mixed territory for Pure customers: the Management Domain on VMFS-FC works natively (a big win), but the vVols deprecation is particularly disruptive, and Pure’s public commitment to “next-generation vVols” in VCF 9 has met a moving target as the deprecation timeline crystallised. This piece is the architect’s read on it.

Source state: what Pure + vSphere customers run today

The typical source state:

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

• Pure Storage FlashArray (//X, //XL, //C, //E lines) running Purity OS

• Datastores across VMFS on FC, VMFS on iSCSI, NVMe/FC, NVMe/RoCE, NVMe/TCP, and/or vVols

• Pure Storage vSphere Client Plugin for in-vCenter operations (provisioning, monitoring, migration, per-VM telemetry)

• ActiveCluster for synchronous active-active replication between two arrays (stretched cluster)

• ActiveDR for asynchronous DR replication

• Stretched vVols with ActiveCluster for customers who took the deepest integration path

• CloudSnap for backup to public cloud object storage

• Pure Cloud Block Store for cloud bursting and DR target

• Aria Operations with the Pure Storage Management Pack for monitoring

• VKS or upstream Kubernetes consuming Pure storage via vSphere CSI or third-party CSI

• FlashBlade for NFS-heavy unstructured workloads (analytics, AI training data, file repositories)

What VCF 9.1 changes for Pure customers

VMFS on FC is supported as primary storage for the Management Domain. VCF 9.x removed the vSAN-only requirement for the Management Domain. For Pure customers, this is the most significant architectural change. A new VCF 9.1 instance can be deployed natively with the Management Domain landing on a Pure FlashArray FC LUN no vSAN required, no intermediate steps. The Greenfield deployment path becomes much friendlier to Pure-centric shops.

vVols are deprecated and being retired. vVols deprecation begins in VCF 9.x and full removal is expected in a later 9.x release. Pure customers with significant vVols footprints and Pure’s historical positioning made this a common pattern need a migration plan. Pure’s own communications acknowledge the situation: vVols remain supported through VCF 9.0 / vSphere 8.0, support tapers between 2027–2028, and customers are advised to plan migration to VMFS or NFS well before end-of-life. Migration targets on Pure: VMFS on FC, NVMe/FC, NVMe/RoCE, NVMe/TCP, or NFS via FlashBlade.

NVMe-over-Fabrics is a strong forward path. Pure has invested heavily in NVMe-oF NVMe/FC, NVMe/RoCE, and NVMe/TCP. For Pure customers migrating off vVols, NVMe/FC in particular offers vVols-like per-VM performance characteristics on traditional VMFS-style datastores. For high-performance and latency-sensitive workloads, NVMe-oF is the natural successor to vVols on Pure.

vSphere Client Plugin continues to deliver value. The Pure Storage vSphere Client Plugin streamlines VMFS, vVols, and NFS datastore operations directly in the vCenter UI provisioning, per-VM monitoring (latency, IOPS, bandwidth), migration. The plugin continues to work with VCF 9.x; ensure the plugin version is compatible with vSphere 9.x before migration.

ActiveCluster pattern is preserved. ActiveCluster as the synchronous metro replication mechanism works under VCF 9.x for VMFS-on-FC and NVMe-oF datastores. The stretched vVols variant of ActiveCluster needs to be re-platformed during vVols migration to ActiveCluster on VMFS-FC or NVMe/FC. The active-active operational model survives; the underlying datastore type changes.

Migration paths for Pure customers

Path A: Convergence with VMFS-FC. If the source estate uses primarily VMFS on FC datastores on Pure FlashArray (and no significant vVols), the convergence path from Part 8 works cleanly. vCenter and ESXi upgrade to v9, convergence brings vCenter into the VCF Instance Management Domain, datastores remain mounted. vSphere Client Plugin continues to provide operational features. ActiveCluster and ActiveDR replication relationships preserved.

Path B: Brownfield Import with NVMe-oF or iSCSI. If the source uses NVMe/FC, NVMe/RoCE, NVMe/TCP, or iSCSI VMFS, the Brownfield Import path is the cleaner mechanism. Deploy a new VCF 9.1 instance with a Management Domain on FC or vSAN, then import the existing Pure-backed vCenter as a workload domain. The Pure protocol design is preserved; the VCF mechanics layer on top.

Path C: Side-by-side with vVols migration. For Pure customers with substantial vVols + ActiveCluster footprint, the side-by-side path is often the right call. Build VCF 9.1 fresh on FC VMFS or NVMe/FC. Provision new Pure datastores in the migration target protocol. Migrate workloads via Storage vMotion (Change storage only) from vVols to the new datastore type. Re-establish ActiveCluster relationships on the new datastores. Decommission the vVols-backed configuration when migrations complete.

The vVols problem for Pure customers

Pure customers tend to be among the most heavily affected by vVols deprecation because Pure invested deeply in making vVols work well and many customers responded by going all-in on vVols-backed VM storage. The migration considerations:

• Inventory: list all vVols datastores, the VMs on them, the workload classes, and the storage policy mappings

• Choose target: NVMe/FC offers the closest per-VM performance experience to vVols on Pure, VMFS-FC is the traditional safe target, NFS via FlashBlade if you have FlashBlade

• Migration mechanism: Storage vMotion (Change storage only) from the vCenter UI, or via the Pure vSphere Client Plugin’s migration features

• Per-VM observability: Pure’s vSphere Client Plugin provides per-VM telemetry on NFS datastores natively. On VMFS, the per-VM granularity is reduced but Active Findings + Real-Time Metrics (Part 9) help close the gap

• Storage policies: VMFS and NVMe datastores use SPBM differently than vVols. Recreate policies on the target datastore type before migration

• Snapshot and replication: vVols snapshots are per-VM array-side; VMFS snapshots are LUN-side. Re-architect any per-VM-array-snapshot workflows (e.g. application-aware snapshot/restore tooling) for the new pattern

• Stretched vVols: needs to become ActiveCluster on VMFS-FC or NVMe/FC during migration. The active-active operational behaviour is preserved; the datastore mechanics underneath change

Pure has publicly stated commitment to next-generation vVols when VMware makes it available. Until that’s firmer, treat vVols as deprecated and plan migration to non-vVols datastore types.

The vSphere Client Plugin transition

Pure’s vSphere Client Plugin is one of the friendlier storage management surfaces in the VMware ecosystem in-vCenter provisioning, per-VM telemetry on NFS, migration workflows. For the VCF 9.1 transition:

• Validate plugin compatibility with vSphere 9 / VCF 9.1 before migration

• Upgrade the plugin to the version that supports VCF 9.x before starting the migration

• Multi-vCenter VCF deployments need the plugin registered to each vCenter

• Plugin functionality coexists cleanly with VCF Operations use the plugin for storage-side operations, VCF Operations for fleet-side observability and lifecycle

ActiveCluster and ActiveDR under VCF 9.x

Pure’s replication portfolio under VCF 9.x:

ActiveCluster (synchronous active-active). Continues to work cleanly on VMFS on FC and NVMe/FC. The transparent failover between two arrays for stretched clusters is preserved. For HLD: ensure the round-trip latency, mediation, and array-to-array link requirements are met. Validate against VCF’s own stretched cluster requirements.

ActiveDR (asynchronous). Continues to provide async DR replication with continuous data protection. Useful for site-level DR pairs where the latency budget excludes synchronous replication. VCF’s VMware Live Site Recovery (renamed from SRM) or vSAN Protection (Part 6) sit alongside, not in place of, ActiveDR.

CloudSnap (backup to object storage). Pure’s capability to snapshot to S3-compatible object storage continues to be valuable, especially with VCF 9.1’s Native S3 Object Storage as a tech preview destination. Confirm CloudSnap compatibility with the new object storage target where applicable.

Pure Cloud Block Store. Pure’s cloud-deployed FlashArray for hybrid cloud DR and bursting continues to fit the VCF + Pure story. Useful as a DR target when on-prem-to-cloud failover is part of the resilience design.

VKS / Kubernetes for Pure customers

Pure offers Portworx as its enterprise data services platform for Kubernetes, with native CSI integration to Pure storage:

vSphere CSI on VKS. Native VCF integration persistent volumes visible in VCF Operations, integrated lifecycle, single observability plane. Best when you need VCF-ecosystem integration depth and your storage requirements don’t demand Portworx-specific features.

Portworx CSI on VKS. Full Pure-aware Kubernetes data services application-aware snapshots, replication, DR, security. Best for high-feature K8s data services or where you already have Portworx investment.

Many Pure shops run a hybrid: vSphere CSI for general-purpose stateful workloads, Portworx for applications that need its features. The HLD should be explicit about which CSI for which class.

HLD design patterns for Pure + VCF 9.1

Pattern 1: All-FC with ActiveCluster. Management Domain on VMFS-FC (deployed natively via VCF Installer). All workload domains on VMFS-FC. ActiveCluster between two arrays for synchronous active-active. Classic Pure architecture, lifted cleanly to VCF 9.1.

Pattern 2: All-NVMe/FC for modern performance. Management Domain on the protocol of preference. Workload domains on NVMe/FC for high-performance, low-latency. ActiveCluster on NVMe/FC for stretched. Migration target for vVols workloads. The architectural direction Pure is investing in.

Pattern 3: FlashArray + FlashBlade mixed. FlashArray on FC or NVMe/FC for VM block storage. FlashBlade providing NFS for file-protocol workloads (analytics, AI training data, file shares). VCF 9.x supports NFS v3 natively for the Management Domain, so FlashBlade can be the principal store if file is the architectural preference. AI customers benefit from FlashBlade’s NFS performance for training data pipelines.

Pattern 4: Hybrid cloud with Cloud Block Store. On-prem VCF 9.1 + FlashArray. Cloud Block Store in AWS or Azure as DR target via ActiveDR. CloudSnap to object storage for backup. Full hybrid resilience story.

Pattern 5: vVols migration window (transition). Existing vVols datastores still in use while migration proceeds. New VMFS-FC or NVMe/FC datastores provisioned alongside. Workloads migrate via Storage vMotion incrementally. The design accepts the hybrid during migration; the steady-state target is vVols-free.

Common HLD/LLD anti-patterns

Waiting for next-gen vVols. Pure has signalled commitment, but the VMware-side timeline is uncertain. Don’t architect on the assumption that vVols will return in 9.x. Plan migration off vVols regardless.

Skipping the vSphere Client Plugin upgrade. The plugin is one of the friendliest operational surfaces in the Pure + VMware stack. Make sure it’s on a VCF 9.x-compatible version before the migration. Don’t leave it as a Day-2 problem.

Treating NVMe/FC as a like-for-like vVols replacement. NVMe/FC gives you per-VM performance characteristics close to vVols, but the storage policy and snapshot model differs. Validate the SPBM and snapshot workflow on NVMe/FC before committing.

Forgetting ActiveCluster’s validation requirements. ActiveCluster has specific mediation, link, and round-trip latency requirements. VCF’s own stretched cluster has its own. Validate both sets of constraints in the LLD.

Mixing vSphere CSI and Portworx without governance. Both can coexist, but mixing them on the same workload class creates operational complexity. Pick which for which workload class.

Ignoring CloudSnap continuity. If CloudSnap-based backup workflows are in production, validate them on the new datastore type and confirm cloud-side compatibility.

Underestimating the per-VM observability change. Pure’s per-VM metrics on NFS are excellent. On VMFS-FC, per-VM granularity at the array level reduces. Plan for VCF’s Real-Time Metrics + Active Findings (Part 9) to close some of that gap, and accept that the operational model changes slightly.

Decision framework: Pure customer paths

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

• Source uses NVMe-oF or iSCSI VMFS, no significant vVols → Brownfield Import (Path B)

• Source has substantial vVols (including stretched vVols) → Side-by-side (Path C) with parallel vVols migration to NVMe/FC or VMFS-FC

• Source has ActiveCluster on VMFS-FC preserved through any path

• Source has stretched vVols on ActiveCluster re-platform to ActiveCluster on VMFS-FC or NVMe/FC during migration

• FlashBlade in scope for NFS workloads VCF 9.x supports NFS Management Domain natively

• Heavy CloudSnap or Cloud Block Store dependency validate hybrid cloud workflow on the target VCF 9.1 environment

• Kubernetes workloads with Portworx plan Portworx-on-VKS pattern up front

Closing

Pure + VCF 9.1 is an architecturally clean combination once the vVols migration is dealt with. Pure’s FC heritage, NVMe-oF investment, ActiveCluster/ActiveDR replication portfolio, vSphere Client Plugin, and Cloud Block Store all integrate cleanly into the VCF 9.1 operating model. The architectural decisions sit in the vVols migration target, the stretched-cluster topology, the CSI choice for Kubernetes, and the hybrid cloud DR mapping.

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

• What’s the source protocol mix VMFS-FC, NVMe-oF, iSCSI, vVols, NFS?

• Is there a significant vVols footprint? Stretched vVols? What’s the migration target NVMe/FC or VMFS-FC?

• Is ActiveCluster in use, and does it need re-platforming during vVols migration?

• Is the vSphere Client Plugin on a VCF 9.x-compatible version?

• vSphere CSI vs Portworx for which Kubernetes workload classes?

• Is FlashBlade in scope NFS Management Domain or supplemental?

• CloudSnap and Cloud Block Store compatibility verified with VCF 9.1?

• Aria Operations Pure Management Pack VCF Operations 9.x-compatible version available?

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

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

Sources

• Considerations for VMware Cloud Foundation with FlashArray (Pure Storage)

• Using VMware Cloud Foundation with FlashArray (Pure Storage)

• Pure Storage Will Support Next-Generation VMware vSphere Virtual Volumes with VCF 9 (Pure)

• How to Simplify Storage Administration with the Pure Storage vSphere Client Plugin

• vVols VMware: vSphere Virtual Volumes on the FlashArray (Pure Storage)

• How to Supercharge Your VMware Environment with Pure Storage (Pure)

• Part 3: Using Pure Storage with VMware Cloud Foundation (Pure Technical Services)

• How To: Using VCF with vVols as Supplemental Storage (Pure Technical Services)