Windows Server Storage Migration Service: Inventory, Transfer, and Cutover

Storage Migration Service (SMS) moves file-server data and supported configuration through an orchestrated inventory, transfer, and cutover workflow. It can help migrate Windows file servers and supported cluster file-server resources, and Microsoft documents source scenarios including Samba and NetApp FAS with applicable requirements. It is not a general-purpose server clone: it does not migrate installed applications or replace role-specific migration planning, and some source types or OS versions have limited cutover support.

The most consequential step is cutover, which can move a source server’s network identity to the destination so clients continue using the previous server name and address. That convenience creates a real identity handoff. Data transfer success alone does not prove that the destination is ready to assume the source’s shares, ACLs, network settings, certificates, service accounts, monitoring, backup, and client expectations.

Confirm that SMS fits the migration boundary

Define whether the goal is file data and share migration, a server-name/IP identity transfer, cluster file-server resource migration, or application/role migration. SMS does not migrate installed applications. A domain controller cannot be cut over through SMS; do not use the file-server workflow to replace a domain controller. Microsoft also documents limitations for consolidation scenarios and source/destination combinations. Check the current FAQ and supported version matrix before committing a schedule.

Record source server type and version, destination version, domain/forest membership, standalone versus clustered resource, share count, data volume, local accounts/groups, identity mapping, storage formats, and network interfaces. A file server that also hosts databases, print queues, scheduled jobs, backup agents, or custom services needs a separate plan for those dependencies. Inventory all shares and consumers, including hidden shares, scripts, DNS aliases, service paths, and application configuration.

Storage Migration Service and the Windows Admin Center extension are the management workflow. Check current SMS prerequisites, supported WAC version/extension, orchestrator OS, source/destination requirements, and update level. For domain-joined sources, the orchestrator must meet the documented domain/forest requirements. If migrating a cluster file-server resource, inventory the role rather than treating each physical node as an ordinary standalone source.

Validate firewall and credentials before inventory

SMS inventory and cutover use multiple management and file-transfer channels. Microsoft documents required inbound firewall rules such as File and Printer Sharing (SMB-In), Netlogon Service (NP-In), and Windows Management Instrumentation rules, plus SMS orchestrator/proxy ports. The complete port path depends on which system is orchestrator, source, proxy, and destination and on OS version. Use the current Microsoft prerequisites for the precise topology, then scope firewall changes to the migration hosts and maintenance window.

Before the job, test the relevant endpoints from the systems that will connect. A successful ping does not prove SMB, RPC/DCOM, WMI, or SMS proxy reachability. A port probe only proves a listener/path at that moment; it does not prove the credentials, rights, firewall application profile, or application-level migration operation.

$source = 'FS-OLD.example.test'
$destination = 'FS-NEW.example.test'

foreach ($server in @($source, $destination)) {
    foreach ($port in @(445, 135)) {
        Test-NetConnection -ComputerName $server -Port $port |
            Select-Object ComputerName, RemotePort, TcpTestSucceeded
    }
}

Get-SmbShare | Select-Object Name, Path, Description, EncryptData,
    ContinuouslyAvailable, FolderEnumerationMode
Get-Volume | Select-Object DriveLetter, FileSystemLabel, FileSystem,
    HealthStatus, Size, SizeRemaining
Get-NetAdapter | Select-Object Name, Status, LinkSpeed, MacAddress

The share and volume commands capture a useful source baseline; run them on the source with an account that can read the intended configuration. The connectivity sample checks SMB and RPC endpoint-mapper reachability only. Do not infer that it validates all dynamic RPC or Storage Migration Service ports. Confirm firewall profile, source/destination direction, RPC dynamic range requirements, and the SMS orchestrator/proxy rules from the current migration documentation.

Use least-privilege administrative credentials approved for the migration. Validate rights on source data and destination volumes, domain membership, local account/SID handling, and any remote-management restrictions. Do not disable UAC remote restrictions, endpoint protection, or host firewall globally to work around a failed validation. Identify the specific operation and account that failed, then make a narrow change with rollback.

Create a job in Windows Admin Center, add each source device or cluster file-server resource, run validation, and start inventory. Review the discovered shares, paths, adapters, volumes, and configuration rather than accepting the scan summary. SMS excludes system folders and other paths that could interfere with Windows operation; warnings for excluded paths are not necessarily migration failures. Decide which shares are in scope and confirm source-to-destination volume mappings.

Check for overlapping share names, path collisions, duplicate data, long paths, unusual ACLs, unresolved SIDs, alternate data streams, reparse points, locked files, and file names that behave differently across source filesystems. Review file-server share properties and security descriptors. A successful file copy can still leave an application broken if a share’s continuous-availability, encryption, caching, access-based enumeration, or permissions differ from the source.

Build an exclusion and exception list with an owner. System and boot files should not be manually forced into the transfer. If a file or share is skipped, record whether the exclusion is by design, out of scope, or a defect that needs a separate method. Avoid deleting files from the source merely to make the inventory warnings disappear.

Transfer in measurable, repeatable passes

Map each source volume and share to the intended destination path. Ensure sufficient destination capacity for data, growth, staging, and any existing destination content that SMS may preserve or move according to its current behavior. Confirm the destination filesystem and cluster design support the planned share settings. If the destination has important data already, take a backup and document how the first and subsequent transfer passes handle existing files.

Run an initial transfer well ahead of cutover, save the transfer log/CSV and errors, and investigate failures. SMS can run another transfer so that changes since the previous copy are transferred. Schedule the final pass close enough to cutover to reduce the change window while allowing time to inspect errors. Stop or quiesce application writers as required by the data consistency plan; an incremental file copy is not automatically an application-consistent database migration.

Validate data on the destination before cutover. Review the SMS transfer log, file errors, representative directory trees, file counts and sizes, ACLs, owners, timestamps, alternate streams where required, share configuration, and application open/read/write behavior. Use a sample that covers different sizes, permissions, nested folders, and business-critical files. If a hash comparison is required for a regulated workload, perform it with a documented process that accounts for the I/O and time cost and does not accidentally create a load spike.

First-transfer and re-transfer behavior can differ. Read the current SMS UI and documentation for whether destination files are backed up, refreshed, or overwritten in the current job stage. Never assume an incremental pass is non-destructive just because it worked previously. Keep a current destination backup and preserve the transfer logs for each pass; later job runs can replace some prior job-state details.

Plan cutover as an identity change

Cutover can move configured network identity, including computer name and selected IP configuration, from the source to the destination. It involves restarts and depends on network, Active Directory, and DNS convergence. Map each source adapter to the correct destination adapter and decide what address the old source should receive after the move. Incorrect adapter mapping can take unrelated management or storage paths offline. Rehearse this mapping and confirm out-of-band access before the window.

Create a minute-by-minute cutover plan: stop/disable new writes, run the final transfer, check errors, begin cutover, monitor restarts and name/address transition, verify DNS/AD registration, test share access, validate application behavior, and define rollback criteria. Ensure administrators can access both source and destination using a management path that does not depend on the identity being moved. Notify application, network, identity, backup, and service-desk owners.

After cutover, the source still contains its original files but is renamed or readdressed to avoid serving the old identity. It is not automatically powered off or securely decommissioned. Keep it isolated and available for an agreed recovery interval, prevent accidental duplicate name/IP use, and record its new identity. Microsoft’s post-migration guidance recommends a source-retention period; apply the current product guidance and the organization’s retention policy to the actual risk and compliance requirements.

Certificates are not automatically reissued simply because the destination assumes the source name. Inspect machine certificates and service bindings that were issued while the destination had its original name, then reissue or rebind them where necessary. Also validate monitoring agents, backup policies, scheduled tasks, local services, SPNs, aliases, firewall policy, and endpoint protection after the new identity becomes active.

Troubleshoot inventory, transfer, and cutover separately

An inventory failure points toward discovery, permissions, remote management, service/feature prerequisites, name resolution, firewall, or source compatibility. A transfer failure points toward access to source/destination paths, capacity, file errors, locked files, unsupported objects, or a network/data-plane bottleneck. A cutover failure is a network-identity and orchestration problem and may occur after data transfer is already complete. Preserve the job stage and percentage before troubleshooting; “migration failed” is not a sufficient diagnosis.

Collect the Storage Migration Service logs from the documented log directory, event records, WAC job status, transfer CSV, source/destination event logs, firewall evidence, account context, and exact stage. Microsoft documents SMS logs under C:\ProgramData\Microsoft\StorageMigrationService\Logs. Protect these artifacts because they may include server names, paths, usernames, share configuration, and operational metadata.

If cutover is stuck, note the failed stage and use the documented manual cutover guidance only after understanding which operations completed. Do not manually swap names and IPs while SMS is still mutating Active Directory or network state. Coordinate the source and destination ownership, DNS/AD replication, firewall, and cluster state. Reconcile the actual server identities and job state before retrying, so a second cutover does not create duplicate names or inconsistent share ownership.

Rollback and decommission deliberately

Define rollback before the initial transfer. If validation fails before cutover, stop and remediate while users still access the source. If failure occurs after identity handoff, decide whether the safe recovery is to move identity back, keep the destination and fix an application dependency, or restore from backup. The source’s files can be a recovery copy but may be stale after users begin writing to the destination. Do not bring the source back online with the old name/address until the destination is isolated and data divergence is reconciled.

Document who owns the source after cutover, how long it remains available, what final backup is required, and when it will be powered off, repurposed, or securely removed. Retain logs, transfer results, permission validation, certificate changes, and user sign-off. Remove temporary firewall rules and credentials when the migration window closes.

Storage Migration Service checklist

Confirm supported source/destination, workload boundary, Windows Admin Center/SMS prerequisites, and domain/cluster requirements.
Validate scoped firewall, RPC, SMB, orchestrator, proxy, permissions, storage, and network paths before inventory.
Review every discovered share, volume, adapter, exclusion, ACL, and destination mapping.
Run initial and final transfers, save errors/logs, and validate data and share behavior before cutover.
Rehearse identity/adapter changes, out-of-band access, validation criteria, and rollback ownership.
After cutover, inspect certificates, SPNs, DNS/AD, applications, monitoring, backup, and source retention.

Storage Migration Service can reduce client disruption by transferring a server’s file data and supported configuration before moving its network identity. The workflow is dependable only when inventory is treated as a design review, transfer is validated independently from cutover, and both the destination and the displaced source have explicit owners and recovery plans.

Related:

Sources: