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

Migrate ONTAP NAS to Amazon FSx for ONTAP

SnapMirror migration from on-premises ONTAP to AWS with peering, incremental sync, cutover and rollback.

Scenario

Example: on-prem cluster OnPrem1, SVM svm_prod and volume vol_projects are moving to FSx for ONTAP SVM fsx_prod, volume vol_projects_dr. Client protocols are SMB and NFS. Replace names, IPs, schedules and paths with your approved inventory. This runbook uses volume SnapMirror, not a file-by-file copy.

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. Inventory the NAS workload and define success

  1. Record each source volume, junction, SMB share, NFS export policy, qtree, security style, snapshot policy, client DNS alias, AD/LDAP dependency, file count, logical used space, change rate, ACLs and application owner. Map every volume to a destination and choose a cutover window. A volume replica does not automatically reproduce every SVM-level configuration, share permission, DNS alias or client mount.
  2. Agree a maximum downtime, an acceptable final-transfer lag and a measurable acceptance test: for example, a named SMB user opens and writes a test file, a Linux client mounts and writes on NFS, an application transaction succeeds, and access control remains restricted. Keep the source and destination from accepting simultaneous production writes.
  3. Check source SnapMirror entitlement, supported ONTAP version pairing, target capacity, FSx SSD and capacity-pool sizing, backup/retention needs and AWS pricing. AWS recommends monitoring SSD utilization so it remains below 80% during migration.
Read-only source inventory 
cluster show
vserver show
volume show -vserver svm_prod
volume show-space -vserver svm_prod
vserver cifs share show -vserver svm_prod
vserver export-policy rule show -vserver svm_prod
Verify

A signed mapping lists every share/export, identity dependency, target path and acceptance owner.

2. Build the AWS destination and network

  1. In the AWS FSx console, create an FSx for ONTAP file system in the selected VPC, deployment type and subnets. Set storage capacity, SSD throughput and backup settings appropriate for the workload. Create or select destination SVM fsx_prod and configure SMB AD integration or NFS service as required. Record file-system management, SVM data and intercluster endpoint addresses.
  2. Connect on-premises to the VPC using AWS Direct Connect or Site-to-Site VPN and approved routing. Every source intercluster LIF must reach every FSx intercluster LIF, and vice versa. Check routing, network ACLs and security groups. AWS lists ICMP and TCP 443, 10000, 11104 and 11105 among required intercluster security-group permissions for this procedure; validate against the current AWS guide.
  3. Also prove that future clients can reach the SVM data endpoint, resolve AD/DNS and access the intended port for SMB or NFS. Intercluster peering reachability alone is insufficient for client cutover.
Read-only source network checks 
network interface show -role intercluster
cluster peer show
network route show
Verify

Replication endpoints communicate in both directions and one disposable AWS test client can reach the target SVM service.

3. Create the destination DP volume and peer clusters

  1. Create the destination as a data-protection volume with enough logical capacity on fsx_prod. Do not place production data in it before replication. Use the FSx console or supported ONTAP CLI; note the actual storage tier and policy. For example, on the FSx CLI after checking the available aggregate: volume create -vserver fsx_prod -volume vol_projects_dr -aggregate aggr1 -size 2TB -type DP. Replace aggr1 and 2TB from the actual file system and source capacity.
  2. Obtain all source and FSx intercluster LIF addresses. Establish cluster peering with the AWS documented sequence and shared passphrase: create the request on one side and accept it on the other. The precise cluster-peer arguments depend on connectivity and ONTAP release, so use the AWS step-by-step procedure linked below.
  3. Peer fsx_prod with svm_prod for snapmirror. Record the local alias of svm_prod as seen on the destination (source_local in the example below); AWS uses that alias in the source path of SnapMirror commands. Check both peers show peered and the snapmirror application. If a peer stays unavailable, isolate routes, firewall, LIF state and version compatibility before building the relationship.
Read-only peer and volume validation 
cluster peer show
vserver peer show
network interface show -role intercluster
volume show -vserver fsx_prod -volume vol_projects_dr
Verify

The DP target exists, both cluster peers and SVM peers show healthy, and the intended intercluster addresses are recorded.

4. Initialize and keep the destination current

  1. On the FSx destination, create a SnapMirror relationship from source_local:vol_projects to fsx_prod:vol_projects_dr using an approved XDP policy and schedule. If a pre-existing destination volume, policy or path differs, adapt the command to the actual inventory and verify it before execution.
  2. Initialize the baseline. Monitor transferred bytes, last transfer error, status and lag. Run scheduled or manual updates until the destination is near current. For an active dataset, schedule repeated increments, measure how long they take, and reserve at least that time in the final downtime window.
Example destination ONTAP commands · confirm policy and schedule exist 
snapmirror create -source-path source_local:vol_projects -destination-path fsx_prod:vol_projects_dr -type XDP -policy MirrorLatest -schedule hourly
snapmirror initialize -destination-path fsx_prod:vol_projects_dr
snapmirror show -destination-path fsx_prod:vol_projects_dr
snapmirror show -fields health,lag-time,last-transfer-error
Verify

Baseline complete; relationship healthy; current lag and projected final-transfer time meet the cutover plan.

5. Prepare protocol and client cutover

  1. On the destination SVM, plan volume junction, NFS export rules, SMB share definitions and share permissions. Validate AD join, DNS, LDAP/name mapping and security style. Replicated file ACLs still need their identities to resolve correctly. Use an isolated client path to test read-only data before the final cutover where feasible.
  2. Lower DNS TTL ahead of the window if switching a client alias. Inventory static client mounts, UNC references, application configs, scheduled jobs and scripts that will need the new endpoint. Record an explicit source write freeze method, a new target name or alias, client remount sequence and failback decision owner.
Verify

A test identity on the destination has intended rights and the migration team knows every client pointer to change.

6. Cut over with a controlled final update

  1. Stop applications or disconnect clients that can write to the source; verify no source writers remain. On the destination, run the last SnapMirror update and wait until status is Idle with the expected last-transfer timestamp and no error. Keep a timestamped record of the last recovery point.
  2. Quiesce further scheduled transfers, then break the relationship to make the destination writable. Mount the volume at its approved junction if needed; create or confirm destination shares and exports. Shift DNS and client configurations to the FSx SVM data endpoint and start applications in dependency order. Do not return source clients to writable service while the FSx destination is authoritative.
Destination change commands · execute only in the approved window 
snapmirror update -destination-path fsx_prod:vol_projects_dr
snapmirror show -destination-path fsx_prod:vol_projects_dr
snapmirror quiesce -destination-path fsx_prod:vol_projects_dr
snapmirror break -destination-path fsx_prod:vol_projects_dr
volume mount -vserver fsx_prod -volume vol_projects_dr -junction-path /projects
Verify

Destination volume online and writable, last transfer completed, clients use only the FSx endpoint.

7. Validate and handle rollback

  1. Compare source and target volume and snapshot inventories; test SMB share ACL and NFS export matches with named users. Verify representative file counts, sizes, checksums for sampled files, timestamps and application behavior. Watch latency, FSx CloudWatch capacity, ONTAP alerts and transfer errors. Record exceptions such as open files or applications that require their own consistency process.
  2. Before any target writes, rollback can point clients back to the unchanged source if the target is rejected. After target writes start, source is stale: freeze target writes, decide the authoritative copy and plan a supported reverse replication or data reconciliation. Do not simply flip DNS back and silently discard new writes.
  3. Close the change only after backup, monitoring, snapshots, DR policy and billing alerts are set for the new FSx workload.
Verify

Application owner signs off; exactly one production-writable copy; recovery and cost monitoring are active.

NetApp references