Skip to main content

NetApp

ONTAP Volume Move Cutover and iSCSI LIF Migration Runbook

NetApp guide — Storage KnowHow

Where This Runbook Fits

This runbook is for a planned ONTAP storage change where a FlexVol volume needs to move to another aggregate and the related host access path needs to be checked during cutover. It is based on the kind of work that shows up in real maintenance plans: move the data, control the cutover window, verify client access, and leave enough evidence for the change record.

There is one important distinction before any commands are run:

NetApp’s command reference lists the volume move command set, including volume move start, volume move show, volume move trigger-cutover, and volume move abort: Commands for moving volumes in ONTAP. NetApp’s LIF documentation covers both migrating a LIF and moving a SAN LIF.

Pre-Change Checklist

Do not start with the move command. Start by proving that the volume, destination, client path, and rollback decision are understood.

Check CLI Evidence Why It Matters
Cluster health system health status show Avoid starting a mobility operation during a cluster issue
Aggregate capacity storage aggregate show Confirm the target aggregate can absorb the volume footprint
Volume state volume show -vserver -volume Confirm the source volume, SVM, type, and current aggregate
Volume space volume show-space -vserver -volume Catch snapshot or metadata growth before the move
LUN mapping lun show -vserver Identify the host-facing objects if this is SAN-backed
LIF location network interface show -vserver Confirm current node, current port, home node, and home port
Host multipath Host MPIO command Make sure hosts have redundant healthy paths before SAN work
Snapshot or backup Backup platform evidence Avoid making rollback depend only on the move operation

Record the change variables before the work starts:

Pre-check:
- Cluster health:
- Source volume:
- Source aggregate:
- Target aggregate:
- Host multipath:
- Related LIFs:

Execution:
- Volume move start time:
- Cutover trigger time:
- Cutover result:
- LIF changes:

Validation:
- Volume final aggregate:
- LIF final placement:
- iSCSI sessions:
- Host multipath:
- Application owner confirmation:

Backout used:
- No / Yes, with details:

CLI Process: Volume Move

First, capture the current location and status:

Pre-check:
- Cluster health:
- Source volume:
- Source aggregate:
- Target aggregate:
- Host multipath:
- Related LIFs:

Execution:
- Volume move start time:
- Cutover trigger time:
- Cutover result:
- LIF changes:

Validation:
- Volume final aggregate:
- LIF final placement:
- iSCSI sessions:
- Host multipath:
- Application owner confirmation:

Backout used:
- No / Yes, with details:

If the destination aggregate is valid, start the move. The -cutover-action wait pattern is useful in change windows because ONTAP can copy data in the background and wait for an explicit cutover command.

Pre-check:
- Cluster health:
- Source volume:
- Source aggregate:
- Target aggregate:
- Host multipath:
- Related LIFs:

Execution:
- Volume move start time:
- Cutover trigger time:
- Cutover result:
- LIF changes:

Validation:
- Volume final aggregate:
- LIF final placement:
- iSCSI sessions:
- Host multipath:
- Application owner confirmation:

Backout used:
- No / Yes, with details:

Monitor the move:

Pre-check:
- Cluster health:
- Source volume:
- Source aggregate:
- Target aggregate:
- Host multipath:
- Related LIFs:

Execution:
- Volume move start time:
- Cutover trigger time:
- Cutover result:
- LIF changes:

Validation:
- Volume final aggregate:
- LIF final placement:
- iSCSI sessions:
- Host multipath:
- Application owner confirmation:

Backout used:
- No / Yes, with details:

When ONTAP reports that the move is waiting for cutover, validate the host path before triggering cutover:

Pre-check:
- Cluster health:
- Source volume:
- Source aggregate:
- Target aggregate:
- Host multipath:
- Related LIFs:

Execution:
- Volume move start time:
- Cutover trigger time:
- Cutover result:
- LIF changes:

Validation:
- Volume final aggregate:
- LIF final placement:
- iSCSI sessions:
- Host multipath:
- Application owner confirmation:

Backout used:
- No / Yes, with details:

Trigger the cutover:

Pre-check:
- Cluster health:
- Source volume:
- Source aggregate:
- Target aggregate:
- Host multipath:
- Related LIFs:

Execution:
- Volume move start time:
- Cutover trigger time:
- Cutover result:
- LIF changes:

Validation:
- Volume final aggregate:
- LIF final placement:
- iSCSI sessions:
- Host multipath:
- Application owner confirmation:

Backout used:
- No / Yes, with details:

Then verify the final aggregate and volume state:

Pre-check:
- Cluster health:
- Source volume:
- Source aggregate:
- Target aggregate:
- Host multipath:
- Related LIFs:

Execution:
- Volume move start time:
- Cutover trigger time:
- Cutover result:
- LIF changes:

Validation:
- Volume final aggregate:
- LIF final placement:
- iSCSI sessions:
- Host multipath:
- Application owner confirmation:

Backout used:
- No / Yes, with details:

If the move must be stopped before cutover, use the abort command and document the reason:

Pre-check:
- Cluster health:
- Source volume:
- Source aggregate:
- Target aggregate:
- Host multipath:
- Related LIFs:

Execution:
- Volume move start time:
- Cutover trigger time:
- Cutover result:
- LIF changes:

Validation:
- Volume final aggregate:
- LIF final placement:
- iSCSI sessions:
- Host multipath:
- Application owner confirmation:

Backout used:
- No / Yes, with details:

CLI Process: NAS LIF Migration

For NAS data LIFs, a manual LIF migration is a normal tool during maintenance. NetApp describes network interface migrate as a best-effort operation that can move a logical interface to a destination node and port when the destination is operational.

Check the current LIF placement:

Pre-check:
- Cluster health:
- Source volume:
- Source aggregate:
- Target aggregate:
- Host multipath:
- Related LIFs:

Execution:
- Volume move start time:
- Cutover trigger time:
- Cutover result:
- LIF changes:

Validation:
- Volume final aggregate:
- LIF final placement:
- iSCSI sessions:
- Host multipath:
- Application owner confirmation:

Backout used:
- No / Yes, with details:

Migrate a NAS LIF:

Pre-check:
- Cluster health:
- Source volume:
- Source aggregate:
- Target aggregate:
- Host multipath:
- Related LIFs:

Execution:
- Volume move start time:
- Cutover trigger time:
- Cutover result:
- LIF changes:

Validation:
- Volume final aggregate:
- LIF final placement:
- iSCSI sessions:
- Host multipath:
- Application owner confirmation:

Backout used:
- No / Yes, with details:

Verify the current node and port:

Pre-check:
- Cluster health:
- Source volume:
- Source aggregate:
- Target aggregate:
- Host multipath:
- Related LIFs:

Execution:
- Volume move start time:
- Cutover trigger time:
- Cutover result:
- LIF changes:

Validation:
- Volume final aggregate:
- LIF final placement:
- iSCSI sessions:
- Host multipath:
- Application owner confirmation:

Backout used:
- No / Yes, with details:

After maintenance, revert the LIF if that is the intended design:

Pre-check:
- Cluster health:
- Source volume:
- Source aggregate:
- Target aggregate:
- Host multipath:
- Related LIFs:

Execution:
- Volume move start time:
- Cutover trigger time:
- Cutover result:
- LIF changes:

Validation:
- Volume final aggregate:
- LIF final placement:
- iSCSI sessions:
- Host multipath:
- Application owner confirmation:

Backout used:
- No / Yes, with details:

CLI Process: iSCSI LIF Movement

Treat iSCSI LIF changes as SAN path work, not as a simple NAS cutover. Before touching a SAN LIF, confirm host multipath health and make sure each host has surviving paths through other target LIFs.

Check the iSCSI LIFs:

Pre-check:
- Cluster health:
- Source volume:
- Source aggregate:
- Target aggregate:
- Host multipath:
- Related LIFs:

Execution:
- Volume move start time:
- Cutover trigger time:
- Cutover result:
- LIF changes:

Validation:
- Volume final aggregate:
- LIF final placement:
- iSCSI sessions:
- Host multipath:
- Application owner confirmation:

Backout used:
- No / Yes, with details:

Check portsets if they are used. NetApp notes that some iSCSI or FCP LIF properties, such as home node and home port, cannot be modified while the LIF is in a portset.

Pre-check:
- Cluster health:
- Source volume:
- Source aggregate:
- Target aggregate:
- Host multipath:
- Related LIFs:

Execution:
- Volume move start time:
- Cutover trigger time:
- Cutover result:
- LIF changes:

Validation:
- Volume final aggregate:
- LIF final placement:
- iSCSI sessions:
- Host multipath:
- Application owner confirmation:

Backout used:
- No / Yes, with details:

Move the SAN LIF by taking it offline, modifying the home location, and bringing it online:

Pre-check:
- Cluster health:
- Source volume:
- Source aggregate:
- Target aggregate:
- Host multipath:
- Related LIFs:

Execution:
- Volume move start time:
- Cutover trigger time:
- Cutover result:
- LIF changes:

Validation:
- Volume final aggregate:
- LIF final placement:
- iSCSI sessions:
- Host multipath:
- Application owner confirmation:

Backout used:
- No / Yes, with details:

Validate from ONTAP:

Pre-check:
- Cluster health:
- Source volume:
- Source aggregate:
- Target aggregate:
- Host multipath:
- Related LIFs:

Execution:
- Volume move start time:
- Cutover trigger time:
- Cutover result:
- LIF changes:

Validation:
- Volume final aggregate:
- LIF final placement:
- iSCSI sessions:
- Host multipath:
- Application owner confirmation:

Backout used:
- No / Yes, with details:

Validate from the host as well. For Linux hosts, that usually means checking multipath, iSCSI sessions, and application I/O:

Pre-check:
- Cluster health:
- Source volume:
- Source aggregate:
- Target aggregate:
- Host multipath:
- Related LIFs:

Execution:
- Volume move start time:
- Cutover trigger time:
- Cutover result:
- LIF changes:

Validation:
- Volume final aggregate:
- LIF final placement:
- iSCSI sessions:
- Host multipath:
- Application owner confirmation:

Backout used:
- No / Yes, with details:

REST API Process: Discover the Volume and LIFs

For REST API workflows, start by discovering the UUIDs. The ONTAP REST API uses UUIDs for most object-specific PATCH operations.

Get the target volume:

Pre-check:
- Cluster health:
- Source volume:
- Source aggregate:
- Target aggregate:
- Host multipath:
- Related LIFs:

Execution:
- Volume move start time:
- Cutover trigger time:
- Cutover result:
- LIF changes:

Validation:
- Volume final aggregate:
- LIF final placement:
- iSCSI sessions:
- Host multipath:
- Application owner confirmation:

Backout used:
- No / Yes, with details:

Get the related IP interfaces:

Pre-check:
- Cluster health:
- Source volume:
- Source aggregate:
- Target aggregate:
- Host multipath:
- Related LIFs:

Execution:
- Volume move start time:
- Cutover trigger time:
- Cutover result:
- LIF changes:

Validation:
- Volume final aggregate:
- LIF final placement:
- iSCSI sessions:
- Host multipath:
- Application owner confirmation:

Backout used:
- No / Yes, with details:

NetApp’s REST API documentation states that a volume move can be started by PATCHing the volume endpoint with the movement object. It also maps volume move fields such as destination aggregate and cutover window to REST attributes: ONTAP volume REST mapping and storage volume PATCH documentation.

REST API Process: Start and Monitor Volume Move

Use validate_only=true first when you want ONTAP to validate the request without performing the operation:

Pre-check:
- Cluster health:
- Source volume:
- Source aggregate:
- Target aggregate:
- Host multipath:
- Related LIFs:

Execution:
- Volume move start time:
- Cutover trigger time:
- Cutover result:
- LIF changes:

Validation:
- Volume final aggregate:
- LIF final placement:
- iSCSI sessions:
- Host multipath:
- Application owner confirmation:

Backout used:
- No / Yes, with details:

Start the move:

Pre-check:
- Cluster health:
- Source volume:
- Source aggregate:
- Target aggregate:
- Host multipath:
- Related LIFs:

Execution:
- Volume move start time:
- Cutover trigger time:
- Cutover result:
- LIF changes:

Validation:
- Volume final aggregate:
- LIF final placement:
- iSCSI sessions:
- Host multipath:
- Application owner confirmation:

Backout used:
- No / Yes, with details:

Monitor movement state and percent complete:

Pre-check:
- Cluster health:
- Source volume:
- Source aggregate:
- Target aggregate:
- Host multipath:
- Related LIFs:

Execution:
- Volume move start time:
- Cutover trigger time:
- Cutover result:
- LIF changes:

Validation:
- Volume final aggregate:
- LIF final placement:
- iSCSI sessions:
- Host multipath:
- Application owner confirmation:

Backout used:
- No / Yes, with details:

Trigger cutover when the change window is ready:

Pre-check:
- Cluster health:
- Source volume:
- Source aggregate:
- Target aggregate:
- Host multipath:
- Related LIFs:

Execution:
- Volume move start time:
- Cutover trigger time:
- Cutover result:
- LIF changes:

Validation:
- Volume final aggregate:
- LIF final placement:
- iSCSI sessions:
- Host multipath:
- Application owner confirmation:

Backout used:
- No / Yes, with details:

Abort an in-progress move if the change must be backed out before completion:

Pre-check:
- Cluster health:
- Source volume:
- Source aggregate:
- Target aggregate:
- Host multipath:
- Related LIFs:

Execution:
- Volume move start time:
- Cutover trigger time:
- Cutover result:
- LIF changes:

Validation:
- Volume final aggregate:
- LIF final placement:
- iSCSI sessions:
- Host multipath:
- Application owner confirmation:

Backout used:
- No / Yes, with details:

REST API Process: LIF Updates

For IP interfaces, the REST equivalent is a PATCH to the interface object. NetApp’s REST API documentation for updating IP interfaces lists PATCH /network/ip/interfaces/{uuid} and relates it to network interface migrate: Update an IP interface.

Before changing an iSCSI LIF, identify whether the desired operation is a supported migration, a SAN LIF move, or a new LIF build. Do not blindly copy the NAS LIF process into SAN.

Disable the LIF:

Pre-check:
- Cluster health:
- Source volume:
- Source aggregate:
- Target aggregate:
- Host multipath:
- Related LIFs:

Execution:
- Volume move start time:
- Cutover trigger time:
- Cutover result:
- LIF changes:

Validation:
- Volume final aggregate:
- LIF final placement:
- iSCSI sessions:
- Host multipath:
- Application owner confirmation:

Backout used:
- No / Yes, with details:

Change the home location:

Pre-check:
- Cluster health:
- Source volume:
- Source aggregate:
- Target aggregate:
- Host multipath:
- Related LIFs:

Execution:
- Volume move start time:
- Cutover trigger time:
- Cutover result:
- LIF changes:

Validation:
- Volume final aggregate:
- LIF final placement:
- iSCSI sessions:
- Host multipath:
- Application owner confirmation:

Backout used:
- No / Yes, with details:

Enable the LIF:

Pre-check:
- Cluster health:
- Source volume:
- Source aggregate:
- Target aggregate:
- Host multipath:
- Related LIFs:

Execution:
- Volume move start time:
- Cutover trigger time:
- Cutover result:
- LIF changes:

Validation:
- Volume final aggregate:
- LIF final placement:
- iSCSI sessions:
- Host multipath:
- Application owner confirmation:

Backout used:
- No / Yes, with details:

Then confirm placement and operational state:

Pre-check:
- Cluster health:
- Source volume:
- Source aggregate:
- Target aggregate:
- Host multipath:
- Related LIFs:

Execution:
- Volume move start time:
- Cutover trigger time:
- Cutover result:
- LIF changes:

Validation:
- Volume final aggregate:
- LIF final placement:
- iSCSI sessions:
- Host multipath:
- Application owner confirmation:

Backout used:
- No / Yes, with details:

Backout Plan

The backout path depends on where the change failed.

Failure Point Backout
Volume move validation fails Do not start the move; fix aggregate, volume, or policy issue
Volume move running but not cut over Abort the move with volume move abort or PATCH movement.state to aborted
Volume moved but host path degraded Restore the intended LIF layout, validate MPIO, and involve host owner before further movement
SAN LIF disabled and host impact is visible Bring the LIF back online on its original home port if still valid
Application validation fails after cutover Decide whether to move the volume back or continue remediation based on host path and ONTAP health

Do not call a completed volume move a rollback by itself. If the cutover has completed and hosts are writing to the volume, moving it back is another controlled change.

Post-Change Evidence

Capture enough evidence that another engineer can understand the final state without joining a bridge call.

Pre-check:
- Cluster health:
- Source volume:
- Source aggregate:
- Target aggregate:
- Host multipath:
- Related LIFs:

Execution:
- Volume move start time:
- Cutover trigger time:
- Cutover result:
- LIF changes:

Validation:
- Volume final aggregate:
- LIF final placement:
- iSCSI sessions:
- Host multipath:
- Application owner confirmation:

Backout used:
- No / Yes, with details:

For REST API-driven changes, save the final GET responses for the volume and affected interfaces:

Pre-check:
- Cluster health:
- Source volume:
- Source aggregate:
- Target aggregate:
- Host multipath:
- Related LIFs:

Execution:
- Volume move start time:
- Cutover trigger time:
- Cutover result:
- LIF changes:

Validation:
- Volume final aggregate:
- LIF final placement:
- iSCSI sessions:
- Host multipath:
- Application owner confirmation:

Backout used:
- No / Yes, with details:

Practical Change Record Template

Use this compact evidence block in the change ticket:

Pre-check:
- Cluster health:
- Source volume:
- Source aggregate:
- Target aggregate:
- Host multipath:
- Related LIFs:

Execution:
- Volume move start time:
- Cutover trigger time:
- Cutover result:
- LIF changes:

Validation:
- Volume final aggregate:
- LIF final placement:
- iSCSI sessions:
- Host multipath:
- Application owner confirmation:

Backout used:
- No / Yes, with details:

Common Mistakes

The operational goal is not just to make ONTAP report success. The goal is to prove that data moved, host access remained healthy, and the final path design is the one the team intended.

Comments