Storage Admin HubConfiguration · Protection · Recovery
All guides/Cloud Migration
Cloud Migration · ONTAP 9

Migrate ONTAP volumes to Azure NetApp Files

Azure NetApp Files migration assistant, peering, replication, dry run, cutover and finalization.

Scenario

Example: on-prem ONTAP cluster OnPrem1, SVM svm_prod, volume vol_projects moves to an Azure NetApp Files volume in account anf-prod. This uses Microsoft’s migration assistant and its ONTAP replication path. Azure NetApp Files differs from Azure Files and has different network and feature requirements.

Before you change production

Commands and screens can differ by release and platform. Replace example names and documentation IP addresses. Check prerequisites, impact, current health and rollback with your change owner.

1. Check current migration-assistant requirements

  1. Confirm the source runs ONTAP 9.10.0 or later, has the required SnapMirror entitlement, and meets Microsoft’s current migration-assistant support requirements. Verify supported source volume type; Microsoft currently excludes on-premises FlexGroup to Azure NetApp Files large-volume migration. Snapshot locking must be off for volumes in this workflow, so resolve that requirement with the protection owner first.
  2. Inventory volume logical size, snapshot count, SMB/NFS protocol, share paths, junctions, ACLs, AD/LDAP, export policies and workload consistency needs. The migration assistant transfers files, metadata, ACLs and snapshots, but share-level SMB permissions are not migrated and need recreation. For volumes with multiple SMB shares, only the primary share may be created automatically.
  3. Choose an Azure region, Azure NetApp Files capacity pool and volume protocol. Plan source logical usage and at least 20% additional target volume quota as Microsoft recommends for migration sizing.
Read-only source checks 
version
volume show -vserver svm_prod -volume vol_projects
volume show-space -vserver svm_prod -volume vol_projects
vserver cifs share show -vserver svm_prod
network interface show -role intercluster
Verify

All support limits, source identities and missing SVM-level settings are recorded.

2. Prepare network, identity and target pool

  1. Set up Azure NetApp Files account, capacity pool, delegated subnet and Standard networking features as required by the migration assistant. Microsoft requires at least seven free IP addresses in the delegated subnet for the migration endpoint and data access, with more space for later volumes.
  2. Connect on-premises ONTAP to Azure via ExpressRoute or VPN and allow bidirectional ICMP, HTTPS and TCP 11104/11105 between all source intercluster LIFs and Azure NetApp Files intercluster endpoints. Check firewalls and routing before peering.
  3. Configure the Azure NetApp Files volume’s AD or LDAP integration for the future client access path. Plan NFS export policies or SMB domain and shares to recreate as needed; a replicated ACL cannot grant useful access if its identity cannot resolve.
Verify

Target networking is ready and the future application client can reach the planned Azure volume network.

3. Create a migration volume in Azure portal

  1. Open Azure NetApp Files account > Migration assistant > New migration. In Source, enter actual cluster, SVM, source volume and size; choose a replication schedule. Complete protocol-specific Azure NetApp Files volume settings, export path or SMB configuration, capacity pool, network features and delegated subnet. Review and create.
  2. In the migration volume’s Migration tab, select Configure Peering. Enter each on-premises intercluster LIF address. Azure presents the peering command and passphrase; execute the exact generated command on the source ONTAP cluster and accept within the documented 60-minute window. Do not paste a generic passphrase or CLI example from another migration.
  3. Collect and run the SVM peering command Azure supplies. Verify the source cluster and SVM peer states. When peering completes, the baseline starts automatically; monitor migration details, transfer progress, lag and error state.
Read-only source validation 
cluster peer show
vserver peer show
snapmirror show -fields health,lag-time,last-transfer-error
Verify

Source and Azure peers healthy; baseline transfer is progressing for the correct volume.

4. Replicate incrementally and rehearse

  1. Let baseline complete. Use the chosen schedule and Sync now to reduce lag before cutover. Record logical transferred data, last successful sync and observed duration. Maintain the source as the only production-writable copy during this phase.
  2. Use the migration assistant Dry run to pause and make the target temporarily writable for an isolated application test. Microsoft states that Resume erases data written to the target during the pause; use disposable test data only and never make the dry-run target authoritative.
  3. Review SMB share-level permission recreation, all additional shares, NFS export behavior, DNS, AD/LDAP lookup and application dependencies. Create a cutover checklist per volume rather than assuming an SVM-wide switch.
Verify

Dry-run application test works and its disposable writes can safely be discarded on Resume.

5. Execute cutover and finalize

  1. Schedule maintenance and stop source writers. Perform Sync now for the final transfer and verify the result and lag. In Migration assistant select Cut over for the intended volume and confirm the target becomes the sole writable production copy. Update client DNS/UNC paths/NFS mounts and start applications in dependency order.
  2. Test content, file ACLs, share-level access, ownership and application operations from actual Azure clients. After acceptance, use Finalize migration to remove the external replication relationship and convert the target to a regular Azure NetApp Files volume. Microsoft states finalizing can remove peering information when this is the last migration using it; coordinate cleanup with other volume migrations.
  3. Configure Azure NetApp Files snapshots/backup and observability only after the migration state and feature support permit it. Document new recovery objectives, capacity pool use and cost.
Verify

One authoritative Azure volume; application acceptance complete; peering cleanup does not disrupt other migrations.

6. Diagnose failures and roll back safely

  1. If peering fails, verify supported network features, delegated subnet free IPs, route/firewall reachability among all intercluster LIFs and the 60-minute accept window. Clear stale peering requests according to Microsoft guidance before retrying. If baseline fails, check version compatibility, SnapMirror entitlement, snapshot locking, target quota and last transfer error.
  2. Before target production writes, reverting clients to the untouched source is possible. After writes begin, preserve both datasets, stop writes and reconcile authoritative changes through a reviewed reverse-migration plan. Do not use Resume after a dry run when test writes must be kept: the assistant discards those writes.
Verify

The incident record states which copy is authoritative and what client writes occurred after cutover.

NetApp references