Migrating data to ONTAP

Migration is an identity-and-metadata project wrapped around a copy. Choose the transfer engine from the source type and outage budget, rehearse deltas and rollback, then prove permissions and application behavior—not just byte counts.

Choose the transfer engine

Source/scenario	Method	Use it when
ONTAP to ONTAP	SnapMirror	Efficient baseline plus updates and a controlled final cutover; validate peering, compatibility, licenses, and relationship type.
NFS/SMB server or foreign array NAS	NetApp XCP	High-volume file migration, assessment, copy/sync, and verification. XCP NFS and SMB workflows, licensing, host requirements, and metadata behavior differ—check the current XCP release.
Generic NAS	rsync / robocopy	Portable host copy where protocol-native tools can preserve the required Unix metadata or Windows ACLs. Test exact switches.
Tape/backup workflow	NDMP	Backup-application-mediated dump/restore; it is not a universal direct array migration. See backup and restore.
SAN LUN	Host/application copy or `lun copy start`	Host copy supports foreign arrays. ONTAP `lun copy start` copies an existing ONTAP LUN into another LUN; it is not a foreign-array import.
S3/object	S3 client, batch or replication tooling	Copy objects into ONTAP S3 while explicitly mapping metadata, versions, retention, multipart state, and credentials. AzCopy is Azure-oriented, not a generic ONTAP command; confirm endpoint compatibility. See ONTAP S3.
7-Mode	Legacy transition tooling	7-Mode Transition Tool and copy-based/replication workflows are legacy. Use archived, source-version-specific procedures and current support guidance; do not assume modern ONTAP commands apply.

For EMC, Pure, HPE, or another foreign block array, plan a host-, hypervisor-, database-, or application-level copy unless a currently supported migration product explicitly covers both endpoints.

dst::> snapmirror create -source-path src_svm:data01 \
  -destination-path dst_svm:data01 -type XDP -policy MirrorAllSnapshots
Operation succeeded: snapmirror create ...

dst::> snapmirror initialize -destination-path dst_svm:data01
Operation is queued: snapmirror initialize ...
dst::> snapmirror show -destination-path dst_svm:data01
Source Path       Destination Path  Status Transferring
src_svm:data01    dst_svm:data01    Idle   42%

Assess, map, and design

Inventory logical bytes, file/object count, churn, largest files, sparse files, hard links, junctions, LUNs, shares/exports, quotas, snapshots, and applications.
Capture Unix IDs/modes/ACLs and Windows SIDs, ACLs, alternate data streams, owners, and inheritance. Resolve identity services at the destination before copying.
Design the target SVM, namespace, LIFs, DNS names, protocol, security style, and capacity. Use the protocol guide and map quotas separately from file data.
Measure baseline throughput and daily change rate. Size the staging window and final delta; document rollback and the point of no return.

src::> volume show -vserver src_svm -fields volume,size,used,files,files-used
vserver volume size used  files    files-used
src_svm data01 8TB  5.6TB 311296000 12844021

dst::> vserver export-policy rule show -vserver dst_svm -policyname data
Policy Name Rule Index Client Match   RO Rule RW Rule
data        1          192.0.2.0/24   sys     sys

Baseline, delta, freeze, final delta

Run a full copy while clients remain online, repeat incremental syncs, then enter the approved outage: stop writers, flush applications, take the final snapshot/delta, make the destination writable if required, redirect clients, and validate. SnapMirror commands below are destructive at break/resync boundaries; rehearse with disposable data and check your relationship type/version.

dst::> snapmirror update -destination-path dst_svm:data01
Operation is queued: snapmirror update ...
dst::> snapmirror show -destination-path dst_svm:data01 -fields lag-time,last-transfer-end-timestamp
destination-path lag-time last-transfer-end-timestamp
dst_svm:data01   00:00:18 8/27/2026 20:51:44

dst::> snapmirror quiesce -destination-path dst_svm:data01
Operation succeeded: snapmirror quiesce ...
dst::> snapmirror break -destination-path dst_svm:data01
Operation succeeded: snapmirror break ...

dst::> lun copy start -vserver dst_svm -source-path /vol/stage/db.lun \
  -destination-path /vol/prod/db.lun
The LUN copy operation was started.
dst::> lun copy show -vserver dst_svm
Source Path             Destination Path       State   Complete
/vol/stage/db.lun       /vol/prod/db.lun       copying 37%

Prove the migration

Compare file/object counts and logical byte totals, accounting for excluded paths and live churn.
Checksum a representative risk-based sample or the full data set when feasible. Application-level validation outranks a simple mount test.
Test owners, groups, mode bits, ACL inheritance, SMB alternate streams, hard links, sparse allocation, timestamps, and quota behavior from real client identities.
Verify exports, shares, DNS, certificates, firewall paths, mount options, drive mappings, LUN serial/UUID effects, multipathing, and application discovery.

dst::> vserver security file-directory show -vserver dst_svm \
  -path /data/finance/q4.xlsx
Vserver: dst_svm
File Path: /data/finance/q4.xlsx
Security Style: ntfs
Effective Style: ntfs

dst::> volume show -vserver dst_svm -volume data01 -fields state,junction-path,used,percent-used
vserver volume state  junction-path used  percent-used
dst_svm data01 online /data         5.6TB 70%

Failure modes to design out

Metadata drift

The wrong copy mode can flatten ACLs, translate ownership, expand sparse files, break hardlinks, or change timestamps. Test before scale.

Moving source

In-flight writes after the final delta create divergence. Enforce the freeze and monitor both endpoints for unexpected writers.

Identity changes

New export paths, SMB UNC names, DNS addresses, LUN serials/UUIDs, object endpoints, and certificates can strand clients even when bytes match.

Keep the source read-only through the agreed rollback window. Preserve logs and verification evidence. Decommission only after business acceptance, backup coverage, and retention obligations are satisfied; follow the decommissioning guide.