ONTAP Volume Move Guide: Storage Mobility, Cutover & NVE Migration

Why volume move matters: Storage mobility

Storage mobility is a cornerstone feature of clustered Data ONTAP. By decoupling volumes from physical aggregates, administrators can rebalance performance and capacity across an entire cluster non-disruptively during standard business hours:

• Load balancing: Relieve over-utilized aggregates or controller nodes by moving hot volumes to less utilized controllers.
• Tiering & technology refresh: Migrate workloads from legacy SAS/SATA hybrid aggregates to all-flash (AFF) NVMe storage, or between capacity tiers.
• Hardware lifecycle: Evacuate controller pairs or disk shelves scheduled for maintenance, replacement, or cluster expansion.
• Security compliance: Apply NetApp Volume Encryption (NVE) or NetApp Aggregate Encryption (NAE) to unencrypted volumes on the fly.

How volume move works under the hood

The volume move operation uses an internal, high-speed point-to-point SnapMirror replication engine built directly into the WAFL filesystem layer:

1. Initialization & Baseline Transfer: A temporary destination volume is created on the target aggregate. ONTAP initiates a baseline transfer of all active data and Snapshot copies from source to destination. Normal client read/write operations continue against the source volume.
2. Incremental Catch-Up Syncs: Because clients continue writing during baseline transfer, ONTAP runs multiple fast delta sync passes, incrementally copying newly modified blocks until the lag between source and destination shrinks below the configured cutover window.
3. Cutover Phase: ONTAP briefly holds incoming client I/O (typically for 1–3 seconds), transfers the final delta blocks, swaps the cluster routing table pointers to the destination volume, resumes client I/O, and subsequently cleans up the source volume.

To client applications, the cutover appears as a brief latency spike rather than a transport disconnect, maintaining full POSIX, SMB lease, and SCSI-3 Persistent Reservation integrity.

Pre-move validation checks

Always validate capacity and cluster readiness before initiating large volume moves. ONTAP provides a dry-run flag to confirm feasibility without allocating disk space or scheduling jobs.

::> volume move start -vserver vs1 -volume vol_finance -destination-aggregate aggr2_nvme -perform-validation-only true
Validation succeeded.

Common validation blockers caught by the dry-run check:

• Aggregate capacity: The destination aggregate must have sufficient available space to hold the volume's current allocated size plus snapshot footprint (minimum 105% of volume footprint recommended).
• Volume limits: Destination node must not exceed maximum volume count per node for its hardware tier.
• NDMP/Backup operations: Ongoing active tape backup or volume dump sessions may temporarily lock the volume metadata.
• FlexGroup constituents: For FlexGroups, individual constituents must be moved independently or using FlexGroup rebalance tooling.

Step-by-step CLI runbook

1. Identify target volume and available aggregates

::> volume show -vserver vs1 -volume vol_finance -fields aggregate,size,used,percent-used
vserver volume      aggregate      size  used    percent-used
------- ----------- -------------- ----- ------- ------------
vs1     vol_finance aggr1_sas_node1 2TB   1.45TB  72%

::> storage aggregate show -fields size,availize,percent-used
aggregate       size   availize percent-used
--------------- ------ -------- ------------
aggr2_nvme_node2 18.5TB 8.2TB    55%

2. Start the move operation

::> volume move start -vserver vs1 -volume vol_finance -destination-aggregate aggr2_nvme_node2
[Job 1482] Job is queued: Move "vol_finance" in Vserver "vs1" to aggregate "aggr2_nvme_node2".
Use the "volume move show -vserver vs1 -volume vol_finance" command to view the status of this operation.

3. Monitor progress and transfer phases

::> volume move show -vserver vs1 -volume vol_finance
Vserver   Volume     State    Move Phase  Percent-Complete Estimated-Completion-Time
--------- ---------- -------- ----------- ---------------- --------------------------
vs1       vol_finance healthy replicating 42%              08/27 12:45:10

::> volume move show -instance -vserver vs1 -volume vol_finance
                        Vserver Name: vs1
                         Volume Name: vol_finance
                   Current Aggregate: aggr1_sas_node1
               Destination Aggregate: aggr2_nvme_node2
                           Move Phase: replicating
                   Percent Complete: 42%
            Estimated Completion Time: Thu Aug 27 12:45:10 2026
                      Cutover Action: retry_on_failure
                      Cutover Window: 30
           Cutover Attempts Remaining: 3
                   Job ID: 1482

4. Aborting a running move (if required)

If aggregate performance requires canceling the operation during peak hours, you can safely abort without data loss or corruption on the source volume:

::> volume move abort -vserver vs1 -volume vol_finance -clean-up-destination true
[Job 1482] Move operation aborted successfully. Cleaning up temporary destination volume.

Cutover parameters and failure actions

The cutover phase is governed by two parameters: -cutover-window (seconds to hold I/O during final sync) and -cutover-action (policy if initial cutover fails).

To manually trigger cutover for a job configured in wait or defer_on_failure mode:

::> volume move trigger-cutover -vserver vs1 -volume vol_finance -force false

In-flight encryption conversions (NVE & NAE)

Volume move is the primary method to encrypt existing unencrypted volumes with NetApp Volume Encryption (NVE) or NetApp Aggregate Encryption (NAE), or to rotate encryption keys.

Convert plaintext volume to NetApp Volume Encryption (NVE)

::> volume move start -vserver vs1 -volume vol_db -destination-aggregate aggr2_nvme -encrypt-destination true -generate-destination-key true

Convert to NetApp Aggregate Encryption (NAE)

When moving onto an NAE-enabled aggregate, volume move inherits the aggregate encryption key automatically or via explicit flag:

::> volume move start -vserver vs1 -volume vol_db -destination-aggregate aggr_nae_01 -encrypt-with-aggr-key true

FabricPool cloud tiering optimization

When moving volumes between FabricPool-attached aggregates, ONTAP provides intelligent block transfer options:

• Capacity tier optimized move (-is-capacity-tier-optimized true): Copies only the active performance-tier data locally between SSDs; cold blocks residing in S3/StorageGRID/Blob object storage remain untouched and re-linked to the destination volume, reducing network transfer and egress costs by up to 90%.
• Tiering policy adjustment: Change tiering policies in-flight during the move using -tiering-policy [none|snapshot-only|auto|all].

::> volume move start -vserver vs1 -volume vol_archive -destination-aggregate aggr_fp_02 -is-capacity-tier-optimized true -tiering-policy auto

SAN & multipathing considerations

For SAN workloads (iSCSI, FC, NVMe-oF), volume move between nodes updates SCSI ALUA target port group states:

• Selective LUN Map (SLM): Ensure reporting-nodes includes the destination node before moving across nodes (lun mapping add-reporting-nodes) to prevent path loss.
• Host Multipathing: Confirm host pathing is Active/Optimized on the source node and Active/Non-Optimized on the target node prior to move. Post-move, ALUA asymmetric access states seamlessly flip.

Troubleshooting & diagnostic matrix

Frequently asked questions

Does volume move disrupt client connections?

No. NFS mounts, SMB sessions, and iSCSI/FC LUN connections remain online throughout baseline replication and cutover. Cutover introduces a brief 1–3 second I/O pause, which is completely handled by standard OS transport timeouts.

Can I move a volume across different ONTAP SVMs?

No. volume move operates within a single SVM. To move volumes between different SVMs, use volume rehost instead.

What happens to SnapMirror relationships on the volume?

SnapMirror relationships automatically recognize the volume's new aggregate location upon completion. The SnapMirror relationship state remains unchanged and subsequent sync schedules proceed as configured.