Windows Server 2016 File Servers: Upgrade or Migrate with Storage Migration Service

A Windows Server 2016 file server is the easiest role in the end-of-support series to get right and one of the easiest to get wrong quietly. The data is the business, the users notice every hiccup, and the old server is usually full of shares, permissions and habits that nobody wrote down. This guide shows both routes Microsoft documents, an in-place upgrade and a move with Storage Migration Service, how to pick between them, and where the rollback point sits. Sources checked 6 November 2026 against Microsoft Learn and Microsoft Lifecycle; they are listed at the end.

Verdict

Verdict: Either.

Microsoft marks in-place upgrade of File and Storage Services as supported and provides Storage Migration Service for a move, so choose by risk: upgrade a simple server in place, migrate anything you cannot afford to lose or want on new hardware.

Neither route is wrong. The real question is whether you can accept a one-way change to the server that holds your data. If the answer is no, build a new server and move the data, because the old server stays intact until you decide to retire it.

Who this is for and what changes on the end-of-support date

This is for anyone running the File and Storage Services role on Windows Server 2016: SMB shares on a physical server or virtual machine, a cluster file server, or a file server that has accumulated other jobs over the years.

Microsoft Lifecycle lists Windows Server 2016 under the Fixed Lifecycle Policy. The Lifecycle table shows the extended support end as 1/13/2027 6:59:59 AM, while Microsoft's extended security updates page names 12 January 2027. Plan to finish before 12 January 2027.

Files keep opening on the day. What stops is security updates, unless you buy Extended Security Updates (ESU). A file server is exposed to every desktop on the network and often to ransomware, so an unpatched one is a worse risk than its quiet role suggests. Microsoft's own Storage Migration Service documentation already notes that Windows Server 2016 as a destination "may be more difficult to migrate to" and that its support ends in January 2027.

On ESU, Microsoft's Azure Arc documentation says Windows Server 2016 reaches end of support on January 12, 2027, and that Extended Security Updates provide Critical and Important security updates for up to three years, through 2030, without new features, customer-requested nonsecurity hotfixes or design change requests. Arc-enabled ESU can be configured in the Azure portal from August 3, 2026, and its billing begins January 13, 2027. Standard and Datacenter editions are supported; physical-core licences need at least 16 cores per machine, and virtual-core licences need at least 8 per VM and use Standard. You must attest to Software Assurance or an equivalent server subscription, or license through SPLA. The pages I read show no price, so get a quote. Microsoft describes ESU generally as a last resort paid option and a temporary bridge, so treat it as a way to finish a migration, not as the plan. Confirm current terms before depending on it.

Decision table

Two notes. Microsoft's role matrix says migration support "varies by subfeature" for File and Storage Services, so check any DFS, deduplication or quota feature you use before assuming it moves. And upgrading with Windows Update to Windows Server 2025 is listed only from 2019 and 2022, so a 2016 server uses installation media.

Steps, with the rollback point

1. Inventory shares and features. On the server, list what exists: Get-SmbShare for shares, Get-SmbShareAccess -Name <share> for share permissions, Get-Volume for sizes and file systems, and Server Manager for installed role services. Note DFS Namespaces, DFS Replication, File Server Resource Manager quotas and screens, deduplication, shadow copies and any scripts that use the server name or IP address.
2. Choose the route per server. In-place suits a simple standalone server with a clean history. Choose migration for a server that is old, crowded with other roles, in poor health, on a language or boot configuration that blocks upgrade, or due for new hardware. Microsoft lists in-place blockers: language change, 32-bit to 64-bit, boot from VHD, Storage Server editions and switching between Server Core and Desktop Experience. Disable NIC Teaming before an in-place upgrade.
3. Take a backup and test a restore. Back up the data and the server, then restore a sample folder with its permissions. This is your rollback for the in-place route.
4. Prepare the destination. Build the new server on a supported Windows Server, join it to the same domain, create volumes at least as large as the source and at least as fast to write, and keep it free of production data. For the Storage Migration Service destination and orchestrator, Microsoft requires Windows Server 2019 or later for the orchestrator and recommends 2019 or later for the destination, which also doubles transfer speed.
5. Install the tooling. Use the latest Windows Admin Center, install the Storage Migration Service extension, and install it on the orchestrator. Install the Storage Migration Service Proxy on destination servers. Make sure these inbound rules are enabled on source and destination: File and Printer Sharing (SMB-In), Netlogon Service (NP-In), Windows Management Instrumentation (DCOM-In) and WMI-In. The migration account must be an administrator on source, destination and orchestrator.
6. Inventory with the service. In Windows Admin Center create a New job, enter credentials, add the source device, select Validate, then Start scan. Review the inventoried shares, volumes and network adapters. Shares under the Windows folder are flagged and must be skipped.
7. Transfer. Map source volumes to destination volumes, choose how to handle local users and groups, validate and Start transfer. Microsoft states that the first transfer moves anything already on the destination into a backup folder, and that later transfers mirror the source, overwriting and deleting. Do not put production data on the destination. Migrated local user accounts arrive disabled with random passwords.
8. Handle the exceptions. Download the error log. The service retries exclusively locked files three times and you can rerun the transfer to pick up skipped files. It does not migrate previous versions from shadow copies, locally installed applications, or NTFS to ReFS, and it will not migrate between domains. Reinstall applications and re-create any scheduled tasks yourself.
9. Verify before you cut over. Compare shares with Get-SmbShare on both servers, check permissions with icacls on sample folders, and compare file counts with robocopy \\old\share \\new\share /L /E /NJH /NJS (the /L switch lists without copying). Let a small pilot group use the new server by its own name for a few days. Rollback point: the source is untouched, because the service never removes files from it.
10. Cut over. On the Configure cutover page, map each destination adapter to a source adapter, set the source's new address and new name, validate, and Start cutover. The destination takes the source's name and IP address, and the source enters a maintenance state. Expect several restarts. Microsoft does not describe an automatic undo of cutover; your fallback is the renamed source, still holding every file, so write down its new name and address before you press the button.
11. After cutover. Reissue certificates that carry the old name, confirm backups run against the new server, repoint monitoring, and update antivirus exclusions. Microsoft recommends keeping the source online for at least two weeks, powering it off for another four, taking a final full backup, and then repurposing or deleting it.

For the in-place route, replace steps 4 to 10 with: install the latest updates, confirm free disk space, run Setup from media and choose to keep files and settings, then repeat step 9 against the same server. Rollback point: only the backup from step 3, so the pilot group matters less and the restore test matters more.

Mistakes that cause outages

• Cutting over with no pilot. Permissions that rely on local groups, mapped drives pointing at an IP address, and scanners that write to a share are found by users, not by checklists.
• Using a destination with production data. The transfer mirrors the source and removes files that are not on it.
• Making the file server a domain controller too. Microsoft states the service cannot cut over from or to a domain controller; demote first where you have another controller.
• Assuming consolidation works. Merging several servers into one name is not supported; Microsoft recommends separate file server resources on a cluster instead.
• Forgetting previous versions. Shadow copies are not carried over, so tell users before the old server goes away.
• Skipping certificates. Certificates issued to the destination before cutover, for example by autoenrolment, carry its old name and are not updated on rename. Microsoft says to reissue them.
• Picking a 2016 destination. It may be slower to transfer to, because the orchestrator proxies the transfer, and it is the version you are leaving.
• Powering off the old server too soon. Keep it until backups of the new server have run and month-end has passed.

Checklist

• Shares, permissions, volumes, DFS, quotas, deduplication and shadow copies inventoried
• Route chosen per server, with in-place blockers checked
• Backup taken and a sample restore tested
• Destination ready, no production data on it, Storage Migration Service and Proxy installed, firewall rules enabled
• Inventory, transfer and error log reviewed; locked files retried
• Pilot group tested; new name and address of the source written down
• Cutover done; certificates, backups and monitoring updated
• Source kept online two weeks, off four weeks, then final backup
• Finish before 12 January 2027

Related tools and reading

The Windows Server 2016 end-of-support planner on our licensing calculator gives the starting verdict for each role. For the licence side of new hosts, see the Windows Server licensing guide. For profiles that live on file shares, see roaming profiles and folder redirection, and for the cost of keeping servers on-premises, the Hyper-V vs Azure VMs vs Azure Local cost model.

Sources

Checked 6 November 2026.

• Windows Server 2016 on Microsoft Lifecycle
• Extended Security Updates for SQL Server and Windows Server
• Prepare to deliver Extended Security Updates for Windows Server through Azure Arc (2016 dates, coverage, Software Assurance)
• License provisioning guidelines for Extended Security Updates for Windows Server (editions, core minimums)
• Billing service for Extended Security Updates for Windows Server through Azure Arc (billing start)
• Product Lifecycle FAQ: Extended Security Updates
• Plan your Windows Server upgrade path (paths, restrictions)
• Upgrade and migrate roles and features (role matrix)
• Storage Migration Service overview (requirements, stages)
• Migrate a file server by using Storage Migration Service (steps, cutover, decommissioning)
• Storage Migration Service FAQ (exclusions, locked files, clusters, previous versions)

General planning information, not a design for your environment. Test with a pilot group first.