12.4 Unstructured Data Migration Design (AzCopy, Data Box, Storage Migration Service)

Why This Topic Matters

The final Migrations bullet is "Recommend a solution for migrating unstructured data." Unstructured data — file shares, media archives, backup sets, blobs — is often the largest single dataset in a migration, and the deciding factor is rarely a feature gap; it's math: how long would this actually take to move over your available network, and can the business tolerate that?

The Core Calculation

Approximate transfer time with:

Transfer time ≈ Data size ÷ (available bandwidth × real-world efficiency)

A rough rule of thumb Microsoft itself uses in Data Box guidance: Azure Data Box is "ideally suited to transfer data sizes larger than 40 TB in scenarios with no to limited network connectivity." Below that threshold, or with strong bandwidth, an online tool is usually simpler and cheaper.

AzCopy: The Default Online Tool

AzCopy is a command-line utility for high-throughput copying to and from Azure Blob Storage and Azure Files. Key capabilities:

• Resume on failure — interrupted transfers pick up where they left off instead of restarting.
• Sync mode — one-way mirroring of a source to a destination, useful for incremental transfers after an initial bulk seed.
• Tunable parallelism and SAS-token authentication for scripted, automatable transfers.

AzCopy is the right call whenever the dataset is small enough (well under the ~40 TB Data Box threshold, or larger but with ample dedicated bandwidth) to move over the network within the business's acceptable window.

Azure Data Box Family: Offline Transfer

When available bandwidth makes an online transfer impractical or unacceptably slow, ship a physical appliance instead:

Exam trap: older material still names Data Box Heavy as the answer for petabyte-scale migrations. As of 2026, Data Box Heavy is retired; the equivalent (and larger) scale is now covered by the Data Box Next Gen 525 TB SKU, or multiple Data Box units shipped in parallel for even bigger estates.

Storage Migration Service: Full File-Server Migration

Storage Migration Service (a Windows Server feature, managed through Windows Admin Center) is purpose-built for migrating an entire Windows file server — not just the files, but the SMB share configuration, NTFS permissions/ACLs, DFS Namespace references, and even the server's identity. Its distinguishing capability is the cutover step: after data transfer, the new server (an Azure VM, or a server registered with Azure File Sync) can assume the old server's name, so client machines and applications keep using the same \\server\share paths with zero reconfiguration. Plain copy tools like AzCopy or robocopy move file content and can preserve many ACLs, but they do not perform this identity cutover — that gap is exactly why Storage Migration Service exists as a distinct recommendation from AzCopy.

Azure File Sync is a related but different service worth disambiguating here: it is an ongoing hybrid caching/tiering pattern (on-premises servers keep a locally-cached namespace of an Azure file share, with cold data tiered to the cloud), not a one-time migration tool. A scenario asking for continuous hybrid access after migration may layer Azure File Sync on top of a completed Storage Migration Service or Data Box move — but by itself it does not answer a "how do we migrate" question.

Exam Scenarios

A media company must move 600 TB of video archives to Azure Blob Storage (Archive tier) but has only a 100 Mbps dedicated line. At that bandwidth, transferring 600 TB would take many weeks even at full utilization — the correct recommendation is Azure Data Box Next Gen (525 TB SKU), potentially with a second unit run in parallel, not AzCopy.

A company is decommissioning two Windows Server 2012 R2 file servers holding 40 shares with complex NTFS ACLs, and end users must keep using the exact same share paths after the move. The correct tool is Storage Migration Service, because it performs the ACL-preserving transfer and the server-identity cutover that a manual file copy cannot replicate.

Key Takeaways

• Estimate transfer time (data size ÷ effective bandwidth) before choosing a tool; Microsoft's own guidance treats ~40 TB as the point where Data Box beats network transfer.
• AzCopy is the default online tool for Blob Storage/Azure Files with resume, sync mode, and scriptable parallelism.
• Data Box Heavy is retired; current large-scale offline transfer options are Data Box Disk (35 TB), Data Box classic (80 TB, being phased out), and Data Box Next Gen (120 TB or 525 TB).
• Storage Migration Service is the only tool here that preserves full file-server identity (SMB shares, ACLs, DFS-N, server name) via its cutover step — pick it whenever share paths must stay unchanged for end users.
• Azure File Sync is an ongoing hybrid-tiering pattern, not a one-time migration tool; don't confuse it with Storage Migration Service.