VMware to Nutanix: Who Migrates the File Shares?
SHIFT converts VMs. XCP moves NFS exports to NetApp. But cross-protocol transfers, S3 targets, and case collisions that silently destroy files? That's the migration nobody plans for.
TL;DR
Nutanix SHIFT converts VMs. NetApp XCP migrates NFS and SMB data — to NetApp only, same protocol only. Cross-protocol transfers, S3 targets, multi-vendor destinations, and pre-transfer hazard detection fall outside both tools. This post maps the gap.
Every VMware-to-Nutanix migration plan covers VMs, networking, and licensing. SHIFT handles VMDK-to-AHV conversion. ONTAP provides the storage layer. For the pure NetApp customer staying on NetApp, it’s a clean path.
Then someone asks about the file shares.
The Part Nobody Plans For
Behind every VMware environment sits unstructured data — approximately 80% of all enterprise data, according to IDC. Home drives, department shares, project archives, NFS exports, compliance-sensitive SMB shares with carefully configured ACLs.
This data doesn’t live inside VMs. It lives on NAS. And it’s almost always the largest data category.
| Category | Typical volume | Tool |
|---|---|---|
| VMs (VMDK) | 10-50 TB | SHIFT |
| NFS exports | 50-500 TB | XCP (partial) |
| SMB/CIFS shares | 50-500 TB | XCP (partial) |
| S3 object data | 10-200 TB | BlueXP (SaaS) |
The VM migration is 50 TB. The file shares are 500 TB. Nobody has a plan for them.
What XCP Covers — and Where It Stops
NetApp XCP is free, fast, and well-built for its scope: migrating NFS or SMB data to NetApp. It preserves POSIX permissions, NTFS ACLs, timestamps, xattrs, and alternate data streams. For same-protocol migrations onto ONTAP, it’s a solid choice.
But XCP is an ingestion tool. It moves data to NetApp. The moment a migration goes beyond that, gaps appear:
| Scenario | XCP |
|---|---|
| NFS → NFS (to NetApp) | Supported |
| SMB → SMB (to NetApp) | Supported |
| NFS → S3 | Not in supported configurations |
| S3 as source | Not in supported configurations |
| NFS ↔ SMB (cross-protocol) | Not supported — separate binaries, no protocol bridge |
| Non-NetApp destination | Not supported |
| Live SMB source (open files) | No VSS integration |
| Projected time-to-complete | Not available (File Analytics shows progress, not ETA) |
Note
These reflect XCP’s documented scope, not bugs. The XCP NFS binary (Linux) and SMB binary (Windows) are separate executables with no cross-protocol capability. NetApp positions BlueXP Copy & Sync for scenarios involving S3 or protocol translation — but BlueXP requires a SaaS control plane and cloud account.
This matters because real VMware-to-Nutanix projects rarely stay single-protocol on a single vendor.
Where It Gets Dangerous
Cross-protocol: silent data loss
Your VMware environment runs NFS for Linux, SMB for Windows. The Nutanix environment standardizes on SMB. That means NFS-to-SMB migration — and that’s not copying files. It’s translating filesystems:
- POSIX permissions → NTFS ACLs: uid/gid doesn’t map to SIDs
- Case sensitivity: NFS is case-sensitive, NTFS is not
- Illegal characters:
:*?"<>|are valid on NFS, forbidden on SMB - Symlinks and xattrs: no SMB equivalent
No tool in the NetApp ecosystem attempts this translation.
Case collisions destroy files
Report.pdf and report.pdf coexist on NFS. Copy both to SMB — one silently overwrites the other. You lose a file with zero warnings. The only defense is a pre-transfer scan that detects case collisions before the transfer starts.
S3: the gap nobody mentions
ONTAP supports S3 natively. Many organizations tier cold data to ONTAP S3 or MinIO. XCP can’t do NFS-to-S3 — it’s not in the supported configurations. BlueXP Copy & Sync can, but it’s SaaS: data broker deployment, cloud account, internet-dependent control plane. For on-prem customers, that’s often a non-starter.
Multi-vendor: the storage change
Not every Nutanix migration stays on NetApp. Some use the hypervisor transition to consolidate from Dell, HPE, or Hitachi onto a new platform — or move to Nutanix Files. XCP only targets NetApp destinations. If the storage vendor changes mid-project, XCP doesn’t cover the data.
What Actually Needs to Happen
1. Discovery scan before anything moves
The Veritas Global Databerg Report found that 52% of enterprise data is “dark data” (unknown value) and 33% is redundant, obsolete, or trivial. That’s 85% of data with questionable migration value.
A discovery scan reveals file counts, sizes, age distribution, ownership, and hazards — case collisions, illegal characters, path lengths exceeding 260 chars (NTFS limit). Moving 500 TB takes weeks. Moving the 80 TB that’s actually current takes days.
2. Pre-transfer hazard detection
Before starting transfers, check:
- Case collisions → files that will overwrite each other on case-insensitive targets
- Illegal characters → filenames that will fail on the destination protocol
- Path lengths → paths exceeding 260 chars (SMB/NTFS) or 1024 chars (S3)
- Orphaned ownership → UIDs/GIDs with no Active Directory mapping
These checks take minutes. Discovering the problems mid-transfer costs days.
3. Transfer with verification
- Parallel: multiple shares simultaneously, not sequentially
- Incremental: initial copy, then delta syncs while source data changes
- Verified: checksum comparison (not just file counts) after every transfer
- Auditable: full log of what moved, when, and whether it verified clean
The Tooling Landscape
| Tool | NFS→NFS | SMB→SMB | Cross-protocol | S3 | Multi-vendor | Discovery | Integrity |
|---|---|---|---|---|---|---|---|
| SHIFT | — | — | — | — | — | — | — |
| XCP | Yes | Yes | No | No | NetApp only | Basic | Yes |
| BlueXP | Yes | Yes | Limited | Yes | Yes | No | Partial |
| rsync | Yes | No | No | No | Yes | No | No |
| syncopio | Yes | Yes | Yes | Yes | Yes | Yes | Yes |
SHIFT converts VMs. XCP migrates files to NetApp. Neither covers cross-protocol, S3, or multi-vendor destinations. In a real VMware exit, that gap contains most of the data.
syncopio covers the gap
Cross-protocol transfers with permission mapping. S3 targets. Pre-transfer hazard detection — case collisions, illegal characters, path lengths. Full checksum verification with xxHash and BLAKE3. Discovery scan included, no cloud account required. See features or request a free PoC.
Checklist: Before You Start
- Inventory all unstructured data — not just VMs
- Identify cross-protocol requirements (NFS→SMB, NFS→S3)
- Run a discovery scan: case collisions, illegal characters, path lengths
- Map UID/GID ownership to Active Directory SIDs
- Classify by temperature — migrate only what’s current
- Plan cutover windows from actual data volumes, not estimates
- Choose tooling that covers all paths, not just NetApp-to-NetApp
- Verify integrity with checksums after every transfer
The VMware exit is about more than hypervisors. The data is the hard part.
Planning a VMware-to-Nutanix migration? Start with a free discovery scan — know what you’re moving before you move it.