On-premises NAS migration to Azure Files
Here’s a concise, structured summary of the article “Use DataBox to migrate from Network Attached Storage (NAS) to Azure file shares.” Links are preserved.
What this guide covers
Scenario: Migrate files from on-premises NAS to native Azure file shares using Azure DataBox for offline bulk transport and RoboCopy for catch-up. Not intended for Azure File Sync (no caching on-prem).
Goals: Move NAS shares to Azure file shares with integrity and minimal downtime.
Applies to
SMB file shares only (Standard GPv2 and Premium FileStorage supported). NFS not supported.
High-level migration phases
Identify how many Azure file shares you need
Deploy Azure storage resources
Determine how many Azure DataBox appliances you need
Provision temporary Windows Server(s) for RoboCopy
Prepare networking, authentication, and authorization for Azure file shares
Copy data onto DataBox
Catch-up RoboCopy from NAS and cut over users/apps
Phase highlights and guidance
Phase 1 — Mapping shares
Choose 1:1 mapping (one Azure file share per on-prem share) for small numbers, or share grouping (combine related on-prem shares into one Azure file share) for many shares.
Phase 2 — Deploy Azure storage
Create storage accounts and file shares (storage account is the scale target for performance for standard shares).
Consider pooling shares into accounts for low-activity/archive shares; isolate highly active shares into their own accounts. Premium FileStorage is provisioned per share.
Note: 250 storage accounts per subscription per region.
See: Create an SMB file share (link preserved).
Phase 3 — DataBox sizing and limits
Any DataBox can move data into up to 10 storage accounts.
Choose DataBox option(s) based on usable capacity and share sizes.
Primary recommended option: DataBox appliance (usable ~80 TiB). Data Box Disks is not recommended — it doesn't preserve ACLs and some metadata.
Plan mapping of which DataBox writes to which storage account; do not split a single file share across two DataBoxes.
Phase 4 — Temporary Windows Server(s)
Deploy Windows Server(s) to copy files onto DataBox and later to run catch-up RoboCopy.
RoboCopy throughput depends on IOPS (source/target), network bandwidth, and ability to enumerate/process namespace. Size RAM and CPU accordingly.
Phase 5 — Prepare Azure file shares for use
Key decisions: Networking (SMB routing), Authentication (Kerberos/AD integration via AD Connect and domain-joining storage account), Authorization (share-level ACLs + NTFS ACLs), Business continuity (consider DFS-Namespace to preserve share addresses).
Complete these before mounting Azure shares.
Phase 6 — Copy files onto DataBox
Follow DataBox setup docs (links preserved).
DataBox will expose SMB shares pre-provisioned for the storage accounts you specified. For standard accounts, use the shares ending with _AzFiles; ignore block/page blob shares.
Recommended to use RoboCopy to preserve full fidelity. The article gives a higher-fidelity RoboCopy example to use when copying onto DataBox: Robocopy /MT:32 /NP /NFL /NDL /B /MIR /IT /COPY:DATSO /DCOPY:DAT /UNILOG: <Dest.Path>
As alternative, Data Box provides a data copy service (link preserved). If using it, ensure you target the correct Azure file share.
Phase 7 — Catch-up RoboCopy and cut-over
Needed if NAS remained writable during transport. Run repeated RoboCopy /MIR passes to catch changes; final run occurs during downtime/failover.
Steps to start a catch-up copy (converted to stepper):
RoboCopy: recommended command and key switches
Recommended catch-up command example: robocopy <Dest.Path> /MT:20 /R:2 /W:1 /B /MIR /IT /COPY:DATSO /DCOPY:DAT /NP /NFL /NDL /XD "System Volume Information" /UNILOG:
Important switches explained (summary):
/MT:n — multithread; helps saturate bandwidth (tests favor 8–20, up to 64 or more dependent on CPU).
/R:n and /W:n — retry count and wait between retries.
/B — backup mode to copy files that current user lacks permissions for (requires elevated prompt).
/MIR — mirror source to target (be careful: mismatched folder levels can delete data).
/IT — helps preserve certain changes (ACL + attribute scenarios).
/COPY:DATSO and /DCOPY:DAT — copy data, attributes, timestamps, security, owner, and directory attributes.
/NP /NFL /NDL — suppress progress and name logging to improve performance.
/UNILOG — Unicode log file (overwrites existing log).
/L — test run (list only), /Z and /ZB — restart modes (use cautiously; slow).
Operational tips and troubleshooting
Use Windows Server 2022 recommended; for Windows Server 2019 ensure latest patches or KB5005103.
Migration speed limited by slowest of source IOPS, target IOPS, or network. Consider network QoS and inter-packet delay (/IPG:n) to avoid saturating production resources.
Processing many small files is CPU/namespace-enumeration bound; increase /MT threads for initial runs and scale back for subsequent runs to match CPU threads.
Avoid large-scale namespace changes (moving files, mass ACL changes) during migration because they can create excessive rework and longer RoboCopy runs.
Use reasonable retry/wait settings (example: /R:5 /W:5) so failed files are retried but runs are not stalled excessively.
Expect to run multiple RoboCopy passes; each subsequent pass typically finishes faster.
See also / links
Migration overview (link preserved)
Networking considerations for direct access (link preserved)
Azure file share snapshots (link preserved)
DataBox docs and specific Quickstart/setup links are preserved within the original article.
Last updated: 12/23/2025
If you want, I can:
Produce a one-page checklist for each phase (deployment, DataBox prep, RoboCopy commands and logs).
Convert the RoboCopy switch table into a collapsible/expandable section for GitBook. Which would you prefer?
Was this helpful?