Migrate to Azure Files Using RoboCopy
Here’s a concise summary of the RoboCopy → Azure Files migration article, highlighting what to do, the recommended command, important switches, and operational considerations.
What this article covers
Use RoboCopy (SMB-based) to migrate files to an SMB Azure file share.
Typical route: source storage (SMB-capable) → Windows machine running RoboCopy → mounted Azure file share.
Not using Azure File Sync or caching on-premises — you mount and use Azure file shares directly.
Before you begin
Read the migration overview: https://docs.azure.cn/en-us/storage/files/storage-files-migration-overview
Deploy the Azure storage resources and mount the Azure file share (see “Use an Azure file share with Windows”: https://docs.azure.cn/en-us/storage/files/storage-how-to-use-files-windows).
Mount the share with admin-level access (recommended: identity-based admin RBAC; less secure: storage account key): https://docs.azure.cn/en-us/storage/files/storage-files-identity-configure-file-level-permissions#mount-the-file-share-with-admin-level-access
AzCopy vs RoboCopy (short)
RoboCopy: SMB-based, mature Windows tool, high-fidelity copy (NTFS ACLs, timestamps, attributes). Good for many migration scenarios.
AzCopy: cloud-native REST-based tool for Azure storage; has only recently added some file migration features and still has gaps (e.g., sync semantics differ — deleted source files may not be removed on target). Not recommended for Azure file share migrations today. (See details: https://docs.azure.cn/en-us/storage/files/storage-files-migration-robocopy#azcopy-vs-robocopy)
Recommended RoboCopy command (delta / mirror style)
robocopy <SourcePath> <Dest.Path> /MT:20 /R:2 /W:1 /B /MIR /IT /COPY:DATSO /DCOPY:DAT /NP /NFL /NDL /XD "System Volume Information" /UNILOG:<FilePathAndName>Key switches and their meaning (high-level)
/MT:n — multi-threaded copy (default 8; 8–20 often balanced for initial copy; max 128). Adjust to match network and CPU.
/R:n — retry count for failed copies. Lower values can speed runs if files are typically locked.
/W:n — wait time (seconds) between retries.
/B — backup mode (requires elevated/admin shell). Helps copy files you don't have permissions for.
/MIR — mirror source to target (copies deltas, deletes target items not in source). Use only when source/target folder levels match exactly.
/IT — includes "tweaked" files to preserve fidelity (useful for ACL+attribute changes).
/COPY:… and /DCOPY:… — control what metadata is copied (data, attributes, timestamps, security, owner, auditing).
/NP, /NFL, /NDL — suppress progress/filenames/dirnames to improve performance.
/XD — exclude directories (e.g., "System Volume Information").
/UNILOG: — Unicode log file (overwrites existing).
/L — list-only (test run).
/Z and /ZB — restart mode/checkpointing (reduces performance — use cautiously).
Best practices / recommendations
Use Windows Server 2022 or newer. If using Server 2019, ensure latest patches or at least KB5005103.
Mount Azure file share with admin-level access (prefer RBAC identity-based admin).
Run an initial full copy, then repeated smaller runs (with /MIR) to catch changes. Final cut-over: block user writes at source, do one last RoboCopy run to sync remaining changes.
For initial runs across higher-latency networks, over-provision /MT to saturate bandwidth; for later catch-up runs, match /MT to CPU thread capacity to avoid compute contention.
Consider /R and /W carefully — e.g., /R:5 /W:5 is a reasonable starting point to avoid prolonged retries on locked files.
Use /IPG:n (inter-packet gap in ms) if you need to throttle RoboCopy’s SMB packet rate to reduce load on network or NAS (not precise bandwidth throttling).
Troubleshooting and optimization — what affects performance
Source and target IOPS and their ability to handle metadata operations.
Network bandwidth between source and target (slowest of source/target/network determines max throughput).
Namespace processing speed (enumeration/metadata operations). Large numbers of small files increase namespace overhead.
Number of changes between runs and file sizes.
Avoid unnecessary namespace churn during migration (mass moves or ACL changes lead to rework and longer runs).
Processing strategy
First run: likely network-bound — favor higher /MT to saturate link.
Subsequent runs: more compute/namespace-bound — reduce /MT to match CPU threads.
Running multiple concurrent RoboCopy jobs is possible but watch overall network throughput and CPU/thread ratios.
Special scenarios
Copy from Azure Files snapshot back to a local drive: see https://docs.azure.cn/en-us/storage/files/storage-snapshots-files#copying-data-back-to-a-local-drive-from-share-snapshot
Cost considerations
Transaction costs for Azure Files depend on number of namespace items and operations, not data size.
Number of transactions scales with item count and metadata changes; many small files generate more transactions.
Multiple copy passes will process source/target items each time and can increase transactions — run tests to estimate transaction volume. See Understanding billing: https://docs.azure.cn/en-us/storage/files/understanding-billing
User cut-over summary
Initial RoboCopy run moves bulk data; users may still change source files during the run.
Run subsequent RoboCopy runs to pick up deltas.
For final cut-over: prevent users from modifying source, run a final RoboCopy; downtime ≈ time for that final scan/copy run (estimate from previous runs).
Parallel copies across shares are possible but keep CPU/network constraints in mind.
Next steps / further reading
What is Azure Files?: https://docs.azure.cn/en-us/storage/files/storage-files-introduction
Migration overview: https://docs.azure.cn/en-us/storage/files/storage-files-migration-overview
Troubleshooting and optimization details: https://docs.azure.cn/en-us/storage/files/storage-files-migration-robocopy#troubleshoot-and-optimize
If you want, I can:
Produce a compact migration checklist (stepper) you can follow.
Extract the recommended RoboCopy flags into a ready-to-run script template.
Create a sample testing plan to estimate transaction costs and run times on your data. Which would you prefer?
Was this helpful?