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

Migrate NetApp SMB shares to Azure Files

Azure Files SMB destination, AD identity, Robocopy seed, delta sync, cutover and validation.

Scenario

Example: NetApp share \\svm-files\projects is moving to an Azure Files SMB share named projects under storage account stprojects01. A Windows Server migration VM reads the old share and writes to the new share. Azure Files is a different service from Azure NetApp Files and does not receive an ONTAP SnapMirror volume directly.

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 protocol and file fidelity before choosing the target

  1. Inventory the NetApp SMB shares, folder tree, item count, size, change rate, longest paths, AD groups, share ACL, NTFS ACL, owners, timestamps, alternate data streams, hard links and workload behavior. Azure Files cannot store every on-premises metadata feature; Microsoft notes alternative data streams are not stored in a direct Azure file share. Test a representative application before committing to the target.
  2. Choose Azure Files performance tier, provisioned capacity/throughput, redundancy, region and backup policy. Plan one or more target shares, because several source shares may have distinct share-level access and cutover names. Compare total-cost and transaction estimates with expected workload.
  3. Decide cloud-only direct access versus a long-term Windows Server cache using Azure File Sync. This procedure uses direct Azure Files access; Azure File Sync has a separate migration path.
Read-only source inventory 
vserver cifs share show -vserver svm_prod
vserver cifs share access-control show -vserver svm_prod
volume show -vserver svm_prod
volume show-space -vserver svm_prod
Verify

Feature gaps and the source-to-target share mapping have application-owner sign-off.

2. Create and secure the Azure file share

  1. In Azure portal, create a storage account and classic SMB file share with the planned region, tier, capacity and redundancy. Configure a private endpoint and private DNS where private access is required. From every future client location, verify that the account name resolves to the intended endpoint and outbound SMB port 445 works through VPN/ExpressRoute or approved connectivity.
  2. Choose an identity source for SMB, for example on-premises AD DS. Follow Microsoft’s AD DS registration procedure (AzFilesHybrid or manual) for the storage account; this creates an AD object representing the account. Synchronize necessary identities to Microsoft Entra ID for share-level Azure role assignments. Assign share-level roles to groups, then configure directory/file NTFS ACLs. These are two separate permission layers.
  3. For migration, mount the Azure share with an admin-level identity that can preserve metadata; Microsoft also documents storage-account-key access for backup-mode Robocopy, but keys have broad scope. Protect secrets and use the least-privilege supported migration design.
Verify

A normal named user reaches the empty target share with intended permission, and the migration identity can set ACLs/owner as needed.

3. Prepare the Windows copy host

  1. Use a current patched Windows Server close to the source or Azure destination, with enough CPU, network and log storage. Mount the NetApp source share as S: and Azure target share as T: using approved credentials. Confirm that source and target correspond to exactly the intended folder roots; never mirror a parent directory into the wrong target share.
  2. Run a pilot copy of a small folder containing nested ACLs, a file owned by another user, a long path and a locked-file case. Compare permissions, owner, timestamps and user access at the destination. Fix identity mapping and permission issues before copying terabytes.
Illustrative Windows commands · authenticate with approved methods 
net use S: \\svm-files\projects
net use T: \\stprojects01.file.core.windows.net\projects
robocopy S:\Pilot T:\Pilot /E /COPY:DATSO /DCOPY:DAT /R:2 /W:1 /LOG:C:\Logs\pilot.log
Verify

Pilot destination content and ACLs match supported fidelity; logs show no unexplained failures.

4. Seed data and repeat delta passes

  1. From an elevated session with backup privilege where required, perform the initial copy using Microsoft’s documented Robocopy pattern. /COPY:DATSO copies data, attributes, times, NTFS ACL and owner; audit information is not supported on Azure Files. /MIR deletes target-only content, so use it only for a dedicated empty or controlled destination whose root matches the source exactly.
  2. Run the first pass while source clients continue working. Review Robocopy summary and detailed errors; make a list of locked files, denied folders and unsupported metadata. Repeat the same job until copy time and outstanding changes fit your downtime window. Preserve logs and avoid running more threads than your NAS, VM and WAN can handle.
Example Robocopy · /MIR removes destination-only files 
robocopy S:\ T:\ /MT:20 /R:2 /W:1 /B /MIR /IT /COPY:DATSO /DCOPY:DAT /NP /NFL /NDL /XD "System Volume Information" /UNILOG:C:\Logs\projects-seed.log
Verify

Each pass finishes with an understood exit code; error count and delta duration trend down.

5. Freeze source and perform final synchronization

  1. Notify users, stop application writes and close or disconnect source SMB sessions using your change process. Confirm source is no longer changing. Run one last Robocopy mirror with a new log file and examine failures before changing client access. Because /MIR deletes target-only items, verify the path pair aloud with another administrator.
  2. Compare file and directory counts, byte totals and sampled checksums, ACLs, owners and timestamps. Recreate source share-level permissions through Azure RBAC; filesystem ACL copy alone is insufficient. Complete a read/write and denied-user test against the destination.
Final pass · execute only after source freeze 
robocopy S:\ T:\ /MT:16 /R:2 /W:1 /B /MIR /IT /COPY:DATSO /DCOPY:DAT /NP /UNILOG:C:\Logs\projects-final.log
Verify

No unexplained copy failures; normal and denied identities behave as expected.

6. Cut over, observe and rollback

  1. Update DFS namespace targets, client drive mappings, application UNC paths or DNS approach to use the Azure Files UNC. Do not assume a storage account can be substituted transparently behind any arbitrary old SMB host name: validate Kerberos, SPNs and Microsoft’s supported namespace method. Start applications, test representative transactions, monitor Azure Files latency, throttling, capacity and authentication failures.
  2. Keep the NetApp source read-only or inaccessible to ordinary writers during stabilization. If the target fails before new writes, point users back to the original source. If users have written to Azure Files, freeze target writes and reconcile the changed files back under an explicit recovery plan before reverting. Enable Azure backup/snapshots and document ownership and ongoing operating costs.
Verify

Applications use one writable location and both share-level roles and NTFS ACLs are verified.

NetApp references