Upgrade Windows Server 2016 to 2025: Step-by-Step Guide

In short

Yes. Windows Server 2016 can be upgraded directly to Windows Server 2025 in supported nonclustered member-server and application-server scenarios using Windows Server 2025 installation media. You do not need to upgrade through Server 2019 or 2022 first.

The decision changes when the server is a domain controller. For AD DS, Microsoft recommends deploying a clean Windows Server 2025 machine, promoting it as a new DC, replicating Active Directory, transferring FSMO roles, and then demoting the Server 2016 DC instead of treating the DC like a normal in-place OS upgrade.

Windows Server 2016 reaches the end of extended support on January 12, 2027. For most production environments, plan the move role by role: direct in-place upgrade can be efficient for a simple supported member server, while side-by-side migration is usually easier to validate for domain controllers, file servers, SQL Server, DHCP, RDS, and mixed line-of-business workloads. If the migration also means moving infrastructure, Raff can be used as the Windows Server 2025 destination while you keep the old Server 2016 system available for validation and rollback.

Can you upgrade Windows Server 2016 directly to 2025?

Yes. You can upgrade Windows Server 2016 to 2025 directly with installation media on a nonclustered member or application server. Windows Server 2025 extended the supported in-place upgrade path back to Windows Server 2012 R2, so 2016 no longer needs an intermediate hop through 2019 or 2022. Domain controllers and clustered hosts are the exception: migrate those side by side instead.

That means a normal member or application server can have a valid Windows Server 2016 → Windows Server 2025 in-place upgrade path without stepping through intermediate Windows Server releases first. Before using it, verify edition compatibility, application support, backup/restore readiness, and Microsoft's current in-place upgrade prerequisites.

The important distinction is the upgrade method and server role:

One more distinction matters: Microsoft's current Windows Update upgrade path to Windows Server 2025 is for eligible Windows Server 2019 and 2022 systems. A Server 2016 → 2025 direct upgrade should therefore be planned around the supported installation-media path, not assumed to appear as a normal Windows Update feature upgrade.

Windows Server 2016 support ends in January 2027

Microsoft's current lifecycle information lists:

After extended support ends, Server 2016 no longer receives normal security updates through the standard lifecycle. Organizations that cannot migrate in time should evaluate Microsoft's current Extended Security Updates options directly rather than relying on old percentage-based pricing examples, because ESU availability and commercial terms can change. The full schedule for every version is in the Windows Server end-of-life dates table.

For a production business server, the practical goal is to finish compatibility testing and cutover before the January 2027 deadline, not begin the project when the deadline arrives.

Choose the migration path by workload

The old server's role determines the safest approach.

Domain controller

Use a side-by-side Active Directory migration. This is the cleanest path because you keep the existing DC available while the new Server 2025 DC replicates and is validated.

File server

Use a side-by-side migration with Storage Migration Service or a controlled file-copy workflow. Validate NTFS ACLs, share permissions, paths, quotas, and client mappings before retiring the source.

SQL Server

Build and patch the destination SQL Server first, then migrate user databases and recreate or transfer instance-level objects such as logins, SQL Agent jobs, credentials, linked servers, and configuration.

Do not plan a cross-version migration by restoring old master, model, or msdb system database backups onto a new major SQL Server version. Treat server-level configuration as a separate migration task.

Line-of-business application server

Check the application vendor's Windows Server 2025 support matrix first. A technically supported Windows in-place upgrade does not guarantee that your ERP, accounting, tax, document-management, or legacy application supports the new OS.

DHCP

Treat DHCP as its own migration step. Export the existing scopes and leases, install and authorize the DHCP role on the new server, import the configuration, update failover or relay settings if used, then validate clients before removing the old DHCP service.

Remote Desktop Services

RDS migrations need additional planning around Session Host roles, licensing, user profiles, certificates, applications, Group Policy, and client access. Administrative RDP and a true multi-user RDS deployment are not the same architecture. See Multi-User RDP vs RDS Session Host. Budget for Windows Server 2025 RDS CALs before cutover; 2016-era CALs will not license the new host.

Side-by-side migration vs in-place upgrade

Both approaches are valid tools. The role and rollback requirement decide which one you should use.

If the Server 2016 machine is a simple, well-documented member server and every installed application supports Server 2025, an in-place upgrade can reduce migration work.

If it is a domain controller, combined file/application server, poorly documented legacy machine, or the migration also moves workloads into a new cloud environment, side-by-side is usually easier to test and recover from.

Before you start: inventory, backups, and compatibility

Do not begin with the Windows Server 2025 installer. Begin with the source environment.

Document:

• server roles and features;
• installed applications and versions;
• Windows services;
• scheduled tasks;
• SMB shares and NTFS permissions;
• local users and groups;
• Active Directory roles;
• DNS zones and forwarders;
• DHCP scopes if present;
• certificates;
• SQL Server instances and databases;
• SQL Agent jobs, logins, linked servers, and credentials;
• RDS roles and CAL model if present;
• application service accounts;
• firewall rules and listening ports;
• backup jobs and restore procedures;
• integrations that connect by hostname, IP address, or UNC path.

Create a current backup and verify that the restore path works. A migration plan that has never tested recovery is not a rollback plan.

For business workloads, also document the current CPU, memory, storage utilization, active users, and database size. That data should drive the destination VM size.

Destination sizing on Raff

If the migration also moves the workload to new infrastructure, size the destination from the actual Server 2016 workload rather than copying the old VM or physical server configuration blindly. Review peak CPU, memory pressure, storage use, active users, database size, and growth before selecting the target.

Current Raff Windows VM examples are:

These are starting infrastructure examples, not workload guarantees. RDS User SALs, SQL Server licensing, additional storage, backups, and application licensing are separate when applicable. See Windows Server licensing and the live Windows VM plans before deployment.

A side-by-side move is especially useful when you want the old Server 2016 system to remain intact while the Server 2025 destination is tested. The decision usually looks like this:

The correct destination may be more than one VM. A migration is a good time to stop running every role on the same server when separation improves security, maintenance, performance isolation, recovery, or vendor support.

Windows VM 1
→ Active Directory / DNS

Windows VM 2
→ Business application / RDS

Windows VM 3
→ SQL Server, if workload and architecture justify separation

Phase 1 — Pre-flight checks on the Server 2016 source

Check AD DS health

If the source is a domain controller, validate Active Directory before adding a new DC.

dcdiag /v
repadmin /replsummary
repadmin /showrepl

Fix DNS, replication, time synchronization, or directory errors before migration. Adding a Server 2025 DC to an unhealthy domain only carries the existing problem forward.

Check domain and forest functional levels

Get-ADDomain | Format-List Name, DomainMode
Get-ADForest | Format-List Name, ForestMode

A Windows Server 2025 DC requires the existing domain and forest to be at least the Windows Server 2016 functional level. Windows Server 2012 R2 functional level does not support Server 2025 domain controllers.

If the level is lower, plan the functional-level change before attempting promotion and verify all existing DCs support the target level.

Confirm SYSVOL uses DFSR

For domains upgraded from much older Windows Server versions, verify SYSVOL replication is using DFSR rather than legacy FRS.

dfsrmig /getglobalstate
dfsrmig /getmigrationstate

A completed migration should report the DFSR migration as finished. Do not introduce a new Server 2025 DC into an environment that still depends on an unsupported legacy SYSVOL replication state.

Identify FSMO role holders

netdom query fsmo

Record the Schema Master, Domain Naming Master, PDC Emulator, RID Master, and Infrastructure Master before you make changes.

Inventory shares and permissions

Get-SmbShare | Format-Table Name, Path, Description -AutoSize

Get-SmbShare | ForEach-Object {
    Write-Host "`n=== Share: $($_.Name) ==="
    Get-SmbShareAccess -Name $_.Name | Format-Table
}

Keep this output so you can compare the destination after migration.

Phase 2 — Prepare the Windows Server 2025 destination

Deploy a clean Windows Server 2025 destination and patch it before adding production roles.

For a domain-controller migration, use a stable private IP, correct DNS settings, and network connectivity to the existing AD environment.

During the initial join phase, the new server should resolve the existing Active Directory domain through an existing DNS/DC path.

After patching and confirming connectivity, join the existing domain:

$domain = "yourdomain.local"
$cred = Get-Credential
Add-Computer -DomainName $domain -Credential $cred -Restart

Replace example names, addresses, and domain values with your own environment.

Phase 3 — Add the Server 2025 domain controller

Microsoft recommends a clean OS install and new DC promotion rather than an in-place OS upgrade of an existing domain controller.

Install AD DS:

Install-WindowsFeature -Name AD-Domain-Services -IncludeManagementTools

Then promote the Server 2025 machine as an additional domain controller:

$dsrmPassword = Read-Host -Prompt "Enter DSRM password" -AsSecureString

Install-ADDSDomainController `
    -DomainName "yourdomain.local" `
    -InstallDns:$true `
    -Credential (Get-Credential) `
    -SafeModeAdministratorPassword $dsrmPassword `
    -NoGlobalCatalog:$false `
    -Force:$true

Server Manager and the AD DS deployment process can prepare the forest/domain as part of supported promotion workflows when the account has the required rights.

Do not move FSMO roles immediately after the first reboot. First verify replication and DNS health.

Phase 4 — Validate AD replication before role transfer

Run:

repadmin /replsummary
repadmin /showrepl

Then confirm important directory objects are visible on both old and new DCs:

Get-ADUser -Filter * | Measure-Object | Select-Object Count
Get-ADComputer -Filter * | Measure-Object | Select-Object Count
Get-ADGroup -Filter * | Measure-Object | Select-Object Count

Object counts are a basic sanity check, not a full replication test. Replication errors must be resolved before the cutover continues.

Phase 5 — Transfer FSMO roles

After the new DC is healthy and replicating, transfer the FSMO roles:

Move-ADDirectoryServerOperationMasterRole `
    -Identity "NEW-DC-01" `
    -OperationMasterRole SchemaMaster, DomainNamingMaster, PDCEmulator, RIDMaster, InfrastructureMaster

Verify:

netdom query fsmo

All roles that you intended to move should now reference the Server 2025 DC.

Also verify Global Catalog status and DNS configuration before changing client dependencies.

Phase 6 — Move DNS and DHCP dependencies

DNS

Update DHCP options, static servers, network devices, and application configurations that still use the old DC's IP as their DNS server.

If you have more than one DC, follow your normal multi-DC DNS client design rather than pointing every DC only at itself. If the new Server 2025 DC eventually becomes the only DC, validate its DNS service and client configuration after the old server is retired.

DHCP

Migrating DHCP from 2016 to 2025 is a separate cutover:

1. Inventory scopes, reservations, options, policies, filters, and failover relationships.
2. Export the Server 2016 DHCP configuration and active leases using the supported Windows Server DHCP migration workflow.
3. Install the DHCP Server role on the Server 2025 destination.
4. Authorize the new DHCP server in Active Directory when applicable.
5. Import scopes and leases.
6. Update routers or DHCP relay/IP helper addresses if the server IP changes.
7. Validate several clients obtain the expected address, gateway, DNS servers, and lease duration.
8. Only then deactivate the old DHCP service.

Do not run two independent DHCP servers serving the same scope unless you have intentionally configured supported DHCP failover.

Phase 7 — Migrate file shares

Microsoft Storage Migration Service is designed for moving file-server data and configuration to newer Windows Server systems.

It is not an Active Directory domain-controller migration tool. AD DS and file-server migration should be treated as separate workstreams even if the old server currently runs both roles.

Storage Migration Service can help inventory and transfer file-server data while preserving important file and share metadata.

A typical workflow is:

1. Inventory source files and shares.
2. Select the Server 2025 destination.
3. Map source and destination volumes.
4. Transfer data.
5. Review transfer errors.
6. Run a final synchronization near cutover.
7. Validate NTFS ACLs and share permissions.
8. Decide whether to retain or change the old server identity/hostname based on the migration design.

After transfer, compare:

Get-SmbShare | Format-Table Name, Path, Description -AutoSize

with the inventory captured before migration.

Phase 8 — Migrate SQL Server correctly

If SQL Server runs on the Server 2016 machine, decide first whether SQL should remain on the same Windows VM as the application or move to its own server.

For a new SQL Server 2025 deployment, use Install SQL Server 2025 on Windows Server.

A safe high-level migration plan is:

1. Install and patch the target SQL Server version.
2. Back up user databases on the source SQL instance.
3. Restore the user databases to the target version using a supported database upgrade path.
4. Migrate logins while preserving SIDs where required.
5. Script or migrate SQL Agent jobs.
6. Recreate linked servers, credentials, operators, Database Mail, server-level permissions, and other instance objects as needed.
7. Update application connection strings or DNS aliases.
8. Run DBCC and application smoke tests.
9. Validate backups on the destination.

Do not assume old SQL system database backups can simply be restored onto a newer major SQL Server version. Server-level objects need their own migration plan.

After migration, apply the SQL Server 2025 Security Hardening Guide.

Phase 9 — Migrate line-of-business applications

The OS upgrade path may be supported while the application itself is not.

For each application:

1. Check the vendor's official Windows Server 2025 compatibility statement.
2. Confirm the application version is still supported.
3. Document services, ports, file paths, certificates, and service accounts.
4. Confirm how licensing moves to new hardware or a new VM.
5. Install the supported application version on the destination.
6. Migrate data using the vendor-supported process.
7. Validate a representative user workflow before broad cutover.

QuickBooks, Sage, ERP products, tax software, document-management systems, custom .NET applications, and legacy databases all have different migration constraints. Do not use a generic Windows migration procedure as a substitute for vendor documentation.

Phase 10 — Plan the cutover

A production cutover checklist should include:

Before the maintenance window

• source backup completed and verified;
• destination backup configured;
• AD replication healthy;
• new DNS/DC validated;
• file delta synchronized;
• SQL/app migration rehearsed;
• DHCP migration prepared if applicable;
• RDS licensing and profile plan confirmed;
• firewall rules validated;
• rollback criteria documented;
• users notified.

During cutover

• stop writes or application services where required;
• run final file/database synchronization;
• move application endpoints, DNS aliases, or client configuration;
• validate user authentication;
• validate application login;
• validate file access and permissions;
• validate database transactions;
• validate backup jobs;
• validate DHCP/DNS if those roles moved.

After cutover

Do not immediately delete Server 2016. Keep the old environment available according to the rollback plan while you confirm production stability.

Phase 11 — Demote the Server 2016 domain controller

Only demote the old DC after:

• FSMO roles have moved;
• replication is healthy;
• DNS no longer depends on the old DC;
• applications no longer use the old server for LDAP/Kerberos/DNS;
• DHCP or other co-hosted roles have been migrated;
• backup and rollback requirements are satisfied.

Use the supported AD DS demotion workflow.

After a graceful demotion, verify Active Directory Sites and Services, DNS, and the Computers/Domain Controllers containers are clean. Do not automatically delete the old DC's computer object or perform metadata cleanup when the normal demotion completed successfully.

Manual metadata cleanup is primarily for failed or forced demotions that leave orphaned DC metadata behind.

Phase 12 — Raise the AD functional level only when needed

After every domain controller runs Windows Server 2025, you can evaluate raising the domain and forest functional levels to Windows Server 2025.

Windows Server 2025 functional level enables Server 2025-specific AD DS capabilities such as the optional 32K database page feature.

Do not raise the functional level just because the migration is finished. Confirm:

• all DCs are Server 2025;
• AD replication is healthy;
• backups are current;
• applications and identity dependencies are validated;
• you understand which 2025-only features you intend to use.

Older guidance often described functional-level raises as strictly irreversible. Microsoft's current Windows Server 2025 documentation supports lowering a 2025 functional level back to Windows Server 2016 in specific supported conditions, provided features that prevent rollback have not been enabled. That does not make rollback something to depend on casually; treat functional-level changes as planned production changes with backups and validation.

In-place upgrade checklist for a simple member server

If you decide that a direct Server 2016 → 2025 in-place upgrade is the better path for a non-DC server, verify all of the following first:

• Server 2025 supports the hardware/virtual platform.
• The current Server 2016 installation is fully patched and healthy.
• Application vendors support Windows Server 2025.
• You have a verified full backup and rollback path.
• You are using a supported Windows Server 2025 installation-media upgrade path.
• Source and target editions are compatible with Microsoft's upgrade restrictions.
• You are not trying to switch between Server Core and Desktop Experience during the upgrade.
• The server is not booting from an unsupported VHD configuration for in-place upgrade.
• NIC Teaming and other documented upgrade blockers have been reviewed.
• You have captured network, role, feature, firewall, and application configuration before upgrade.

After the upgrade, verify Windows activation/licensing, services, application health, network interfaces, scheduled tasks, firewall rules, event logs, backups, and monitoring.

Common migration mistakes

Treating a domain controller like a normal app server

A direct OS upgrade may exist as a Windows upgrade path, but Microsoft recommends adding a clean newer DC and demoting the old one. Keep the AD DS migration architecture separate from generic member-server upgrade guidance.

Raising functional levels before the environment is stable

Functional level is not the first migration step. Complete the DC migration and validation first.

Moving SQL user databases but forgetting instance objects

Database backups do not automatically move logins, jobs, linked servers, credentials, and every server-level configuration item.

Restoring old SQL system databases onto a newer major version

Do not use this as a generic cross-version migration technique. Recreate or migrate server-level objects using supported procedures.

Forgetting DHCP relay or IP helper configuration

The DHCP database can migrate successfully while clients still fail because routers continue sending DHCP requests to the old server IP.

Leaving applications pointed at the old hostname or IP

Search configuration files, scheduled tasks, ODBC DSNs, mapped drives, service settings, DNS records, scripts, printers, and line-of-business integrations before shutdown.

Treating a snapshot as the entire backup strategy

A snapshot can help with short-term rollback but does not replace application-aware backups, off-server copies, and restore testing.

Running a Windows Server 2016 migration on Raff

A Windows Server 2016 migration to Raff follows the same role-by-role plan: build the 2025 destination on a Raff Windows VM, replicate or migrate the workload, validate it, then cut over only when the new system passes the required checks. Server 2016 leaves extended support on January 12, 2027, so the migration plan should be driven by the application and role dependencies rather than the deadline alone.

A Raff migration project can use:

• Windows Server 2025 VMs;
• private networking between destination systems;
• additional volumes for application or file data;
• snapshots and backups for rollback planning;
• separate Windows VMs when AD, application, RDS, or SQL roles should not share one operating system;
• Raff-provided Windows Server Standard licensing under SPLA, or eligible customer-owned licensing where Microsoft's Flexible Virtualization Benefit requirements are met.

Raff-hosted RDS licensing is separate from the Windows Server license and uses RDS User SALs. SQL Server and application licensing also remain separate unless explicitly included by the relevant agreement.

If the migration is also a provider move, keep the commercial decision separate from the technical cutover: first validate the target architecture, licensing, sizing, backup plan, and rollback path, then move production. The Windows VM page shows current plans, while Windows Server licensing covers SPLA, BYOL, CAL, and RDS distinctions.

Validation scope

The Raff Windows content lab has separately validated Windows Server 2025 deployment and core procedures used across this guide, including AD DS role installation/promotion workflows, FSMO transfer, Windows file-server migration tooling, and SQL Server 2025 deployment used by the linked Windows articles.

This article does not claim that one synthetic lab VM reproduced every possible 2016 → 2025 production migration end to end. Real migrations vary by domain health, applications, data size, networking, certificates, identity integrations, and vendor support requirements.

What's next

• Windows Server 2019 vs 2022 vs 2025
• Set Up an Active Directory Domain Controller
• Install SQL Server 2025 on Windows Server
• SQL Server 2025 Security Hardening
• Windows Server 2016 End of Life: Dates, ESU, and Migration Options
• Windows Server Licensing: SPLA, BYOL, CALs & RDS
• Raff Windows VM

Sources

• Microsoft Learn — Plan your Windows Server upgrade path
• Microsoft Learn — Perform an in-place upgrade of Windows Server
• Microsoft Learn — Upgrade domain controllers to a newer version of Windows Server
• Microsoft Learn — Active Directory Domain Services functional levels
• Microsoft Learn — Raise domain and forest functional levels
• Microsoft Learn — Lower domain and forest functional levels
• Microsoft Learn — Storage Migration Service overview
• Microsoft Learn — Windows Server release information
• Sources revalidated: 2026-09-17

Microsoft, Windows Server, Active Directory, SQL Server, Hyper-V, Windows Admin Center, and Storage Migration Service are trademarks or products of Microsoft Corporation. Raff is an independent infrastructure provider and is not affiliated with or endorsed by Microsoft.