Storage Admin Hub
All guides/Cloud Migration
Cloud Migration · Migration procedure

Migrate NetApp NFS data to Azure Files NFS

NFSv4.1 compatibility, private networking, file copy, metadata checks and Linux client cutover.

By Hrishikesh Naik5 min read
Scope

Educational ONTAP 9 example. Confirm platform, protocol and release compatibility in the linked documentation.

Scenario

Example: NetApp NFS export svm-nfs:/projects is moving to an Azure Files NFSv4.1 share called projects. This file-level copy procedure uses a Linux migration VM with both source and target mounted; it is not SnapMirror and does not preserve NetApp snapshots. Check the selected Azure Files resource provider against Microsoft’s version-specific migration guide.

About the command and output examples

Names, addresses and results are illustrative. Commands have not been executed against a live storage system or SAN switch for this publication. Confirm syntax and compatibility for your release, then rehearse in an approved lab. Existing-data recovery and destructive changes need an environment-specific plan. Read the editorial standards.

01Confirm Azure Files NFS meets the workload

  1. Inventory current NFSv3/v4 clients, UID/GID ownership, export rules, ACLs, symlinks, hard links, file counts and sizes, application locks and latency requirements. Azure Files NFS supports NFSv4.1 and UNIX-style permissions but does not support NFS ACLs, Kerberos identity-based authentication, Windows NFS clients, or simultaneous SMB access to the same NFS share. An NFSv3-only client or ACL-dependent workload needs redesign or a different target.
  2. Choose SSD NFS share sizing, IOPS and throughput and supported redundancy, and review Azure region and resource provider. Decide how NetApp export-policy client restrictions translate to Azure network security controls and root-squash behavior; there is no one-to-one export-policy copy.
Read-only source inventory 
vserver nfs show -vserver svm_prod
vserver export-policy rule show -vserver svm_prod
volume show -vserver svm_prod -fields junction-path,security-style
Acceptance check

A pilot workload passes protocol, identity, permissions and latency tests before the full migration.

02Create secure Azure NFS network and share

  1. Create an Azure Files NFS share using the chosen supported resource provider and region. Configure VNet access and preferably a private endpoint with private DNS. For on-premises clients, establish VPN or ExpressRoute to the Azure VNet; check name resolution and route to the private endpoint. Azure Files NFS relies on network access controls and UNIX permissions rather than per-user Kerberos authentication.
  2. Mount from an Azure Linux VM using Microsoft’s portal-generated Linux mount command for that exact share. Ensure your NFSv4.1 client version and encryption-in-transit setting are compatible. Avoid writing a guessed export URL: the mount target differs by Azure resource model.
Acceptance check

A Linux test VM can mount the target and create/read/remove a disposable file; unauthorized networks cannot mount it.

03Mount both ends and pilot a copy

  1. Mount the NetApp source with the intended NFS version at /mnt/source and the Azure target with the generated Azure command at /mnt/target. Where supported by the client and Azure share, use nconnect for parallel connections after a pilot proves stability. Ensure the copy host can read all source data and set the intended target ownership.
  2. Copy a test directory with rsync preserving ownership, groups, permissions, timestamps and links where supported. Dry-run with --itemize-changes, then run a real pilot. Review numeric UID/GID identity mapping, root squash, special files and unsupported ACLs. Applications using database files may require application-native migration rather than an uncoordinated file copy.
Linux pilot example · inspect before copying 
rsync -aHn --numeric-ids --itemize-changes /mnt/source/Pilot/ /mnt/target/Pilot/
rsync -aH --numeric-ids --info=stats2 /mnt/source/Pilot/ /mnt/target/Pilot/
Acceptance check

Representative files, links, owner IDs and permissions have the intended semantics at the target.

04Seed the dataset and measure delta

  1. Start the bulk copy while applications continue writing to the source. Use rsync for moderate datasets; for large namespaces consider Microsoft’s Storage Mover or fpsync guidance for the selected classic NFS share. Choose parallelism after measuring source/target IOPS and network load.
  2. Run repeated rsync passes and compare transfer statistics, itemized changes, errors and elapsed time. Microsoft documents Storage Mover for on-prem NFS sources; its Azure endpoint support and resource provider scope must be checked before adopting it. Preserve a manifest of skipped files and decide how each will be handled.
Example bulk and dry-run delta commands 
rsync -aH --numeric-ids --info=stats2 --log-file=/var/log/projects-seed.log /mnt/source/ /mnt/target/
rsync -aHn --numeric-ids --itemize-changes /mnt/source/ /mnt/target/
Acceptance check

The dry-run change list shrinks enough for the approved maintenance window.

05Final pass, switch clients and validate

  1. Stop all source writers and verify the export is stable. Run one final rsync pass. If deletions must be mirrored, first inspect a dry run with --delete and confirm the exact root path, then execute it only on an approved dedicated destination; --delete can remove destination-only data.
  2. Compare file counts, byte totals and selected checksums; test UID/GID ownership and application operations from an Azure client. Update /etc/fstab or application mount definitions with the Azure Files NFSv4.1 target and mount options recommended for that resource type; restart workloads in order. Keep the NetApp source protected from new writes.
Final delta · --delete removes target-only files 
rsync -aHn --numeric-ids --delete --itemize-changes /mnt/source/ /mnt/target/
rsync -aH --numeric-ids --delete --info=stats2 --log-file=/var/log/projects-final.log /mnt/source/ /mnt/target/
Acceptance check

One writable target serves the application; file metadata, authorization and latency match acceptance criteria.

06Rollback and operational handover

  1. If the target fails before it receives production writes, restore original client mounts to the unchanged NetApp export. After target writes begin, stop those writes and use a reviewed reverse-copy/reconciliation plan before reverting; a DNS or fstab reversal alone loses changes.
  2. Configure supported Azure Files NFS snapshots and monitoring; note that Azure File Sync and Azure file-share backup support differ for NFS. Document private endpoint DNS, VPN/ExpressRoute, mount options, storage performance limits and access governance.
Acceptance check

Application owner confirms recovery, monitoring, data protection and one authoritative copy.

Continue learning

Use the section links to revisit a step, or follow a related guide below.

Official references and further reading

Choose the matching release in the vendor documentation before using a command or design. References open on the publisher’s website; linked material remains with its publisher.