Migrating a Legacy File Server With 12 TB and Hardlinks
Tailspin must migrate FS01, a Windows Server 2012 R2 file server holding 12 TB across 900 shares, to Windows Server 2022 (FS02). FS01 uses DFS Namespaces (a single namespace, \\tailspin\files) with folder targets on FS01. About 40 TB of data is not changing, but 2 TB changes weekly. Some shares contain files with hardlinks and alternate data streams created by a legacy app. A pilot using robocopy /MIR copied data but lost hardlinks and produced 300 access-denied errors on files owned by a departed admin. The business allows a 6-hour cutover window on a Saturday night and requires that users' mapped drives and UNC paths keep working.
1. Which migration tool and method should replace robocopy `/MIR`, and why does it fit the constraints?
Read the worked answer
Use Storage Migration Service (SMS) in Windows Admin Center, with a DFS Namespace cutover. SMS inventories the source, transfers data with a filter that preserves ACLs, hardlinks, and alternate data streams, and - unlike robocopy /MIR - performs a final incremental sync before cutover, so the 2 TB of weekly change is handled in a short delta rather than a full recopy. It also reports per-file errors so the 300 access-denied files can be resolved before the window.
Why not robocopy alone. /MIR mirrors content but does not preserve hardlinks (it duplicates them, inflating size) and its handling of ADS depends on flags; the pilot proved it loses both. Robocopy also has no cutover orchestration, so mapped drives and UNC paths would break when FS01 is retired.
Cutover. SMS can cut over the server identity (IP/hostname) or, better here, use the existing DFS Namespace: add FS02 as a folder target, disable the FS01 target, and let clients follow the namespace. Because users connect via \\tailspin\files, mapped drives and UNC paths are unchanged - no client reconfiguration, and the 6-hour window is ample for the final sync and target flip.
2. How should the 300 access-denied files and the 2 TB weekly change be handled before and during the cutover window?
Read the worked answer
Access-denied files. These are owned by a departed admin, so the migration account lacks rights. Before cutover, take ownership at the folder level on FS01 (takeown /f <path> /r /d y) or grant the migration service account Backup Operators/SeBackupPrivilege so it can read regardless of ACL - SMS honors backup semantics when configured. Do not simply grant Everyone; preserve the original ACLs so the target matches the source. Document the ownership change for audit.
Weekly change (2 TB). Run a full initial transfer weeks ahead (SMS handles this outside the window), then schedule a final incremental sync in the cutover window. SMS's transfer uses a delta comparison, so the Saturday job moves only changed blocks - typically well under the 6-hour budget. Freeze writes on FS01 at the start of the window (disable SMB share access or set the shares read-only) so the delta is truly final, run the sync, verify counts and spot-check hardlinks and ADS, then flip the DFS target. Keep FS01 read-only for one week as a rollback path.
3. A stakeholder asks whether DFS Replication could replace the migration tool for the initial 12 TB copy. Evaluate.
Read the worked answer
Not for the initial 12 TB. DFS Replication (DFSR) is designed for ongoing multi-master replication of modest change volumes, not bulk seeding of terabytes. Its staging area (configurable, default 4 GB) throttles large transfers, and initial replication of 12 TB over a WAN or even a LAN would take far longer than the 6-hour window and risks staging backlog and replication backlog errors. DFSR also does not preserve hardlinks - replicated files become independent copies - and its handling of alternate data streams depends on the replication configuration, so it would repeat the pilot's data-integrity failures.
Where DFSR fits. After cutover, if Tailspin wants FS02 and a future FS03 to host the same namespace targets, DFSR can keep ongoing content in sync between them - small deltas, not the seed. Use SMS (or a seeded robocopy with /SL and backup mode) for the bulk copy, then enable DFSR for continuity.
Bottom line. Use SMS for migration; reserve DFSR for steady-state replication once the data is in place.