How to Migrate from Windows Server 2019/2022 to 2025 Safely

Windows Setup can move Server 2019 or 2022 to Server 2025. The harder job is checking each driver, role, agent, and recovery path before trusting the result.

This guide covers in-place and side-by-side migrations. You’ll inventory the source, choose a supported route, test rollback, perform the move, and validate it with real client traffic.

What Is Windows Server 2025?

Windows Server 2025 is Microsoft’s current Long-Term Servicing Channel release. It supports Active Directory Domain Services (AD DS), DNS, file services, Hyper-V, Internet Information Services (IIS), failover clustering, and application hosting.

No single migration method fits every role. A clean member server may handle an in-place upgrade well. A domain controller or busy file server usually needs a staged side-by-side move. That keeps the old server available during testing.

Your admin workstation can be a Mac running Microsoft Windows App or another Remote Desktop Protocol (RDP) client. The migration runs on Windows Server. The Server Manager paths and PowerShell commands apply to the Windows systems you connect to.

Prerequisites

Make sure you have:

• Windows Server 2019 or Windows Server 2022 as the source
• A valid Windows Server 2025 license and matching installation media
• Installation media obtained from Microsoft Volume Licensing, Visual Studio subscriptions, or the Microsoft Evaluation Center
• Local administrator and required domain administrator credentials
• Current servicing-stack and cumulative updates installed on the source
• At least 32 GB of free space on the operating-system volume; allow more if the server has large component or update stores
• Hardware, firmware, storage, and network drivers supported on Windows Server 2025
• Vendor confirmation for applications, antivirus or endpoint detection, monitoring, backup, and management agents
• A verified full server backup
• A system-state backup for a domain controller or other role that requires it
• A tested restore or failback procedure
• A maintenance window with an assigned rollback decision time
• Console access through a hypervisor, out-of-band controller, or physical console
• A separate Windows Server 2025 host or virtual machine for a side-by-side migration
• A temporary test account with representative access to applications and shares
• Change approval for DNS, firewall, certificate, service-account, and monitoring changes

That list is longer than the setup wizard. Good. Your plan must cover the parts setup can’t inspect.

Tested workflow

The commands use Windows PowerShell 5.1. It’s included with Windows Server 2019, 2022, and 2025. The GUI paths assume Desktop Experience.

Server Core supports PowerShell but lacks several local consoles shown here. Use Server Manager, Windows Admin Center, or remote Microsoft Management Console snap-ins from a compatible system.

Warning: Never start an operating-system upgrade with RDP as your only access method. Network or firewall drivers can reset during setup and drop the session.

Step-by-Step Guide

Step 1: Choose between an in-place upgrade and side-by-side migration

Choose before you reserve downtime or build the destination. Your choice sets the rollback options and how much you can test before the outage.

Factor	In-place upgrade	Side-by-side migration
What changes	Existing operating system is upgraded	Roles and data move to a new server
Extra infrastructure	Usually not required	Requires a destination server or VM
Existing identity	Hostname, local configuration, and installed applications can remain	New identity is prepared before cutover
Rollback	Restore the source from backup if setup rollback is unavailable or unreliable	Redirect clients to the retained source
Hardware refresh	No	Yes
Configuration cleanup	Limited	Good opportunity to remove old software and settings
Application risk	Higher because installed components pass through setup	Lower when the application can be rebuilt and tested
Typical downtime	Often one main maintenance window	Usually a short final synchronization and cutover
Best fit	Simple, supported member servers with verified applications	Domain controllers, file servers, old hardware, complex roles, or uncertain applications

An in-place upgrade avoids another server. It also carries every old agent, driver, and questionable registry choice through setup. Use it only when all these statements are true:

• Microsoft lists the source release, edition, language, and installation type as a supported path.
• Every critical application and agent supports Windows Server 2025.
• Windows Server 2025 drivers and firmware exist for the hardware.
• You can restore the full server within the approved recovery time.
• The environment has enough redundancy for the maintenance window.

Use side-by-side migration when any of these conditions apply:

• The server is a domain controller.
• You’re replacing hardware or changing firmware modes.
• You want to change between Server Core and Desktop Experience.
• Applications need separate rebuilds or upgrades.
• The server has years of abandoned agents, drivers, or settings.
• The role has a safer supported migration process.
• You need to test the destination while the source stays available.

Side-by-side setup takes longer at first. You can test the destination while production keeps running on the source. That trade usually makes sense for identity services and business data.

Supported direct upgrade paths

Microsoft permits supported Windows Server 2019 and Windows Server 2022 installations to upgrade directly to Windows Server 2025. The short answers are:

• Can Windows Server 2019 upgrade directly to Windows Server 2025? Yes, for supported edition, language, installation-type, and role combinations.
• Can Windows Server 2022 upgrade directly to Windows Server 2025? Yes, under the same compatibility conditions.

“Directly supported” describes only the operating-system route. Setup must still offer the correct retention option. Each installed role and application also needs destination support.

Support matrices can change. Just before the maintenance window, compare your source with Microsoft’s current Windows Server upgrade overview and in-place upgrade procedure.

Edition and installation-type rules

Treat these rules as gates:

• Upgrade to the same edition when possible, such as Standard to Standard or Datacenter to Datacenter.
• Setup may offer some Standard-to-Datacenter paths. Confirm the exact path and license before relying on one.
• Don’t plan an in-place downgrade from Datacenter to Standard.
• Keep the installation type consistent. Server Core can’t become Desktop Experience through an in-place upgrade. Desktop Experience can’t become Server Core either.
• The media language must match the installed operating-system language if you want to retain applications and settings.
• Evaluation, retail, OEM, and volume-license channels can add conversion or activation limits.
• Azure Edition has separate deployment and upgrade rules. Don’t treat it as a conventional on-premises Standard or Datacenter installation.

Expected result: You’ve recorded one path and why you chose it. If any eligibility item remains uncertain, use side-by-side migration until you resolve it.

Step 2: Record the source version, edition, build, and installation type

Open an elevated PowerShell window. Select Start, type PowerShell, right-click Windows PowerShell, and select Run as administrator.

Run:

Get-ComputerInfo |
    Select-Object WindowsProductName, WindowsVersion, OsBuildNumber, OsArchitecture

Get-WindowsEdition -Online

Expected output resembles:

WindowsProductName : Windows Server 2022 Standard
WindowsVersion : 21H2
OsBuildNumber : 20348
OsArchitecture : 64-bit

Edition : ServerStandard

Check whether the source uses Server Core or Desktop Experience:

Get-ItemPropertyValue `
    -Path 'HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion' `
    -Name InstallationType

Expected output:

Server

Server normally means Desktop Experience. Server Core means a Core installation.

Open Start > Settings > System > About. Confirm that the edition and build match the command output. Redact the hostname, product ID, domain, registered owner, and organization before taking a screenshot.

Recording the exact values now prevents the usual maintenance-window debate about which image someone downloaded three weeks ago.

Expected result: The migration record contains the exact product name, build, edition, architecture, language, and installation type.

Step 3: Inventory roles, applications, networking, and dependencies

Create a protected working folder:

New-Item -Path 'C:\Migration' -ItemType Directory -Force

Export installed roles and features:

Get-WindowsFeature |
    Where-Object Installed |
    Select-Object Name, DisplayName, InstallState |
    Export-Csv -Path 'C:\Migration\InstalledFeatures.csv' -NoTypeInformation

Export services, scheduled tasks, software, IP settings, routes, shares, and certificates:

Get-CimInstance Win32_Service |
    Select-Object Name, DisplayName, State, StartMode, StartName, PathName |
    Export-Csv -Path 'C:\Migration\Services.csv' -NoTypeInformation

Get-ScheduledTask |
    Select-Object TaskPath, TaskName, State |
    Export-Csv -Path 'C:\Migration\ScheduledTasks.csv' -NoTypeInformation

Get-ItemProperty `
    'HKLM:\Software\Microsoft\Windows\CurrentVersion\Uninstall\*',
    'HKLM:\Software\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall\*' |
    Where-Object DisplayName |
    Select-Object DisplayName, DisplayVersion, Publisher, InstallDate |
    Sort-Object DisplayName |
    Export-Csv -Path 'C:\Migration\InstalledSoftware.csv' -NoTypeInformation

Get-NetIPConfiguration |
    Format-List * |
    Out-File -FilePath 'C:\Migration\NetworkConfiguration.txt'

Get-NetRoute |
    Sort-Object InterfaceIndex, DestinationPrefix |
    Format-Table -AutoSize |
    Out-File -FilePath 'C:\Migration\Routes.txt'

Get-SmbShare |
    Select-Object Name, Path, Description, FolderEnumerationMode, EncryptData |
    Export-Csv -Path 'C:\Migration\SmbShares.csv' -NoTypeInformation

Get-ChildItem -Path Cert:\LocalMachine\My |
    Select-Object Subject, Issuer, Thumbprint, NotAfter, HasPrivateKey |
    Export-Csv -Path 'C:\Migration\MachineCertificates.csv' -NoTypeInformation

Don’t use Win32_Product for application inventory. That class can start Windows Installer checks and repair actions. It’s a nasty side effect for a read-only inventory command.

In Server Manager, select Manage > Remove Roles and Features. Continue only as far as Server Roles and Features. Record the selected items, then cancel without removing anything.

Commands won’t find every dependency. Add these items by hand:

• Inbound and outbound firewall rules
• Load balancer pools and health probes
• DNS aliases and static host records
• Service accounts and group-managed service accounts
• Certificate bindings and private-key access
• Application URLs and listening ports
• Database, storage, queue, and API dependencies
• Cluster membership
• Drive letters, mount points, and storage multipathing
• Backup jobs and retention rules
• Monitoring checks, log forwarding, and alert routing
• Configuration-management assignments
• Antivirus or endpoint detection exclusions
• Client drive mappings, scripts, and Distributed File System (DFS) namespaces
• Recovery time objective and maximum acceptable data loss

Check certificates and service accounts closely. An application can start normally yet fail every useful request because its account lost private-key access.

Expected result: C:\Migration contains the machine-readable inventory. The plan maps each service to its owner, dependencies, validation test, and rollback action.

Step 4: Install the current cumulative update baseline

No permanent KB number belongs in a migration plan. Microsoft replaces cumulative updates each month. Use the latest approved update for your Windows Server 2019 or 2022 branch. Also install any setup prerequisite in the current Server 2025 upgrade documents.

This workflow was tested on July 31, 2026. Check the requirements again on migration day through:

• Windows Server release information
• Microsoft Update Catalog
• Your organization’s Windows Server Update Services (WSUS), Microsoft Configuration Manager, or Azure Update Manager policy
• The current Windows Server 2025 upgrade documentation

Don’t choose a KB only because it has the newest publication date. Confirm that it matches the source release and architecture. Check whether another package replaced it.

For a standalone or Windows Update-managed server, open:

• Windows Server 2022: Start > Settings > Windows Update
• Windows Server 2019: Start > Settings > Update & Security > Windows Update

Select Check for updates and install the approved updates. Reboot, then repeat until no security or cumulative updates remain.

If WSUS or another platform controls the server, use that platform. Bypassing policy creates two update baselines. You don’t need that mystery during an OS upgrade.

List the latest installed hotfixes:

Get-HotFix |
    Sort-Object InstalledOn -Descending |
    Select-Object -First 20 HotFixID, Description, InstalledOn

Check whether Windows has a pending reboot:

$rebootKeys = @(
    'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Component Based Servicing\RebootPending',
    'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate\Auto Update\RebootRequired'
)

$pendingReboot = $rebootKeys |
    Where-Object { Test-Path $_ }

if ($pendingReboot) {
    'Pending reboot detected'
} else {
    'No pending reboot detected in the standard servicing locations'
}

Expected result:

No pending reboot detected in the standard servicing locations

Is Windows Update a supported way to perform the operating-system upgrade? Don’t assume a normal update scan will offer Windows Server 2025. The predictable admin-controlled method uses matching Server 2025 media and setup.exe. If Microsoft or your management platform offers the upgrade, check that route against current Microsoft guidance and your servicing policy.

Expected result: The source is fully patched, has restarted cleanly, and has no pending servicing reboot.

Step 5: Verify hardware, firmware, storage, and driver readiness

Collect the system model, firmware, processor, memory, and disk space:

Get-CimInstance Win32_ComputerSystem |
    Select-Object Manufacturer, Model, TotalPhysicalMemory

Get-CimInstance Win32_BIOS |
    Select-Object SMBIOSBIOSVersion, ReleaseDate

Get-CimInstance Win32_Processor |
    Select-Object Name, NumberOfCores, NumberOfLogicalProcessors

Get-Volume |
    Select-Object DriveLetter, FileSystem, HealthStatus, Size, SizeRemaining

Windows Server 2025 requirements vary by feature and deployment type. Check for a compatible 64-bit processor and supported firmware. You also need enough RAM and storage, plus a supported network adapter. Use Microsoft’s current Windows Server hardware requirements.

Microsoft’s minimum values describe a system that can boot. They don’t size your workload. Keep at least the current CPU and RAM unless measurements support a reduction.

Check these vendor items:

• Update the BIOS or UEFI and management-controller firmware to a release approved for Windows Server 2025.
• Check the storage controller, network adapter, chipset, Fibre Channel, and multipath drivers.
• Confirm the model appears in the Windows Server Catalog or the vendor’s Server 2025 support matrix.
• Check free space on the EFI System Partition or System Reserved partition. A nearly full system partition can stop setup even when C: has ample space.
• Confirm encryption and Trusted Platform Module procedures before changing firmware.
• Download critical network and storage drivers before the maintenance window.

For a virtual machine, check support for the hypervisor, guest hardware version, virtual devices, guest tools, and backup product.

A missing NIC driver is manageable when its installer is on the console-mounted ISO. It’s less charming when the only copy lives on a network share.

Expected result: Each hardware and driver component is supported, updated, or assigned a documented fix.

Step 6: Review role and vendor compatibility

A supported OS route doesn’t mean every installed role can move in place. Check Microsoft’s current guidance for each role.

Role or workload	Preferred research path
AD DS and DNS	Build and promote a new domain controller, validate replication, then demote the old controller
File services	Storage Migration Service, Robocopy, DFS, or an application-aware file migration
DHCP	Use DHCP Server export/import or Windows Server Migration Tools
Print services	Use Print Management migration tools and confirm driver support
IIS	Back up configuration and content; validate modules, certificates, bindings, and application runtimes
Hyper-V	Use supported live migration, shared-nothing migration, export/import, or cluster-aware procedures
Failover clustering	Follow the role-specific cluster upgrade or migration matrix
Certificate Services	Follow the AD CS backup, key-protection, database, registry, and restore procedure
Remote Desktop Services	Validate all role services, licensing mode, brokers, profiles, certificates, and application support
WSUS	Confirm database and content migration guidance for the installed WSUS architecture
Third-party applications	Use the vendor’s Windows Server 2025 support statement and migration guide

Record written support for:

• Business applications and their database clients
• Endpoint detection and antivirus software
• Backup agents and application-aware plug-ins
• Monitoring, inventory, and remote-management agents
• Hardware-management and storage software
• VPN, packet-filter, and network-inspection drivers
• Java, .NET, web-server, and scripting runtimes
• Licensing services and hardware-bound activation

Remove or update unsupported filter drivers before an in-place upgrade. Antivirus, backup, and network products often install kernel components. Those components can block setup or leave the upgraded server offline.

Vendor support statements matter. “It worked in our lab” is useful evidence, but a vendor’s support queue may still reject the case.

Expected result: Every role and application has a supported migration method, an owner, and a post-migration test.

Step 7: Check Active Directory, DNS, and replication health

Run these checks from an elevated Command Prompt or PowerShell session on a domain controller:

dcdiag.exe /e /c /v /f:C:\Migration\DcDiag.txt
repadmin.exe /replsummary
repadmin.exe /showrepl * /csv > C:\Migration\Replication.csv

/e checks every server in the site. /c runs the full test set, and /v writes verbose details.

Healthy replication summary output should show zero failures:

Source DSA largest delta fails/total %% error
DC01 00h:04m:12s 0 / 10 0
DC02 00h:03m:45s 0 / 10 0

Check the SYSVOL and NETLOGON shares:

Get-SmbShare -Name SYSVOL, NETLOGON

Test DNS resolution and locate a domain controller:

Resolve-DnsName -Name '_ldap._tcp.dc._msdcs.example.test' -Type SRV
nltest.exe /dsgetdc:example.test

Replace example.test with your Active Directory DNS name.

Review these logs in Event Viewer before migration:

• Directory Service
• DNS Server
• DFS Replication
• System
• Application
• Windows PowerShell
• Role-specific logs under Applications and Services Logs

Fix replication, DNS, time, SYSVOL, and directory errors first. A migration tends to expose existing directory faults. It rarely fixes them.

Expected result: dcdiag shows no blocking failures. Replication has zero failures, DNS returns the expected records, and SYSVOL and NETLOGON are available.

Step 8: Create and verify full and system-state backups

Use your supported backup product to create:

• A full backup of the source server
• An application-consistent backup of databases and directory services
• A system-state backup when applicable
• Separate exports of application configuration, certificates, and encryption keys
• A backup of the migration inventory stored outside the source server

For Windows Server Backup, install the feature if it isn’t present:

Install-WindowsFeature -Name Windows-Server-Backup

Expected output includes:

Success Restart Needed Exit Code Feature Result
——- ————– ——— ————–
True No Success {Windows Server Backup}

Start a system-state backup with:

wbadmin.exe start systemstatebackup -backuptarget:E: -quiet

Replace E: with a dedicated supported destination. Don’t keep the only backup on a disk inside the server you’re upgrading.

List registered backups:

wbadmin.exe get versions

Expected output should include a recent backup version, its target, and recoverable items.

Warning: A Hyper-V, VMware, or cloud VM checkpoint isn’t a complete backup plan. It may share the VM’s storage and failure domain. It can also grow until it harms production storage. Domain controllers and clustered applications need supported recovery methods.

Test a restore before the maintenance window. At minimum, restore sample files elsewhere and confirm that application-aware or system-state recovery is available. For a critical server, rehearse bare-metal recovery on an isolated network.

A successful backup job proves data reached the repository. A restore test proves you can get useful data back. Different claims.

Expected result: The backup works, is stored outside the source failure domain, and has passed a documented restore test.

Step 9: Define rollback conditions and the cutover deadline

Write clear stop conditions before setup starts. Roll back when any of these occurs and you can’t fix it before the deadline:

• Setup fails or repeatedly rolls back.
• The server can’t boot normally.
• Network, storage, or critical drivers fail.
• AD replication, DNS, SYSVOL, or authentication fails.
• A critical application or role doesn’t start.
• Data integrity checks fail.
• The backup or monitoring agent can’t return to service.
• Performance exceeds an agreed CPU, memory, latency, or error threshold.
• Troubleshooting uses the time reserved for recovery.
• Vendor support declares the result unsupported.

For an in-place upgrade, rollback usually means one of these actions:

• Let Windows Setup restore the old version if setup fails before completion.
• Restore the full server from the verified backup.
• Restore application data from the recovery point in the change plan.
• Reconnect dependencies and test the restored source.

Don’t use temporary Windows Setup rollback files as your disaster-recovery plan. Cleanup and later servicing can remove them.

For a side-by-side migration:

• Stop writes to the destination.
• Reverse DNS aliases, load balancer membership, DFS referrals, or client mappings.
• Re-enable the source service.
• Reconcile any writes accepted by the destination after cutover.
• Confirm clients are using the source again.

Set the rollback decision before the recovery reserve starts. If restoration takes 90 minutes and service must return by 06:00, troubleshooting can’t continue until 05:45.

Expected result: The plan names a rollback owner, decision time, recovery point, procedure, and maximum data loss.

Step 10: Run the Windows Server 2025 in-place upgrade

Skip this step if you selected side-by-side migration.

Before mounting the media:

• Complete and verify the backup.
• Pause application traffic or drain the node from its load balancer.
• Stop scheduled maintenance and deployment jobs.
• Suspend monitoring alerts without disabling data collection.
• Confirm console access.
• Disconnect unneeded USB and removable devices.
• Disable or remove only the security and backup components whose vendors require it.
• Record BitLocker recovery information if BitLocker is enabled.
• Reboot once and confirm that the source returns cleanly.

Mount the Windows Server 2025 ISO. In File Explorer, right-click the ISO and select Mount. Note its drive letter, such as D:.

Validate the media first. Some Microsoft download channels publish hashes. Compare the ISO with the hash supplied by your source:

Get-FileHash -Path 'C:\InstallMedia\SERVER_EVAL_x64FRE_en-us.iso' -Algorithm SHA256

Run setup.exe from the mounted media:

Start-Process -FilePath 'D:\setup.exe'

In Windows Server Setup:

• Choose the option to download updates, drivers, and optional features if policy permits it. In restricted networks, use approved offline media and update sources.
• Enter the product key if prompted.
• Select the Windows Server 2025 image that matches the intended edition and installation type.
• Read and accept the license terms.
• On Choose what to keep, select Keep files, settings, and apps only when setup offers it and the path is supported.
• Review the compatibility report.
• Stop for a blocked application, driver, full system partition, or unsupported keep option.
• Save or photograph the result with all identifying data redacted.
• Select Install only after every readiness check passes.

The server restarts several times. Don’t interrupt setup because one percentage stays on screen for a while. Watch from the console.

After sign-in, confirm the version:

Get-ComputerInfo |
    Select-Object WindowsProductName, WindowsVersion, OsBuildNumber

Expected output should identify Windows Server 2025 and its installed build.

Check activation:

cscript.exe C:\Windows\System32\slmgr.vbs /xpr

A dialog should report permanent activation or show the current activation state.

Warning: Do not delete C:\Windows.old, run component cleanup, or remove the pre-upgrade backup until the rollback deadline has passed.

Expected result: Windows Server 2025 starts, activation is understood, networking works, and setup reports no unresolved compatibility failure.

Step 11: Build the side-by-side Windows Server 2025 destination

Skip Steps 11 through 14 if you completed an in-place upgrade and don’t need to move roles.

Create a supported physical server or VM with:

• Generation and firmware settings supported by the hypervisor
• Sufficient virtual CPUs and memory
• Correct storage layout and resiliency
• A temporary static IP address
• A unique hostname
• Current integration tools and drivers
• Console access
• Windows Server 2025 Standard or Datacenter with the required installation type

Install Windows Server 2025 from trusted media. During setup:

• Boot from the ISO.
• Choose the correct language, time, and keyboard settings.
• Select Install now.
• Choose the licensed edition and either Server Core or Desktop Experience.
• Select Custom: Install Microsoft Server Operating System only.
• Select the intended operating-system disk.
• Complete setup and set the local Administrator password.
• Install firmware, drivers, cumulative updates, and endpoint protection.
• Rename the server and configure a static address.
• Join the destination to the domain if its role requires membership.

Example configuration:

Rename-Computer -NewName 'WS25-DEST01' -Restart

After the restart, configure the address. Replace the example values with your network settings:

New-NetIPAddress `
    -InterfaceAlias 'Ethernet' `
    -IPAddress '192.0.2.25' `
    -PrefixLength 24 `
    -DefaultGateway '192.0.2.1'

Set-DnsClientServerAddress `
    -InterfaceAlias 'Ethernet' `
    -ServerAddresses '192.0.2.10','192.0.2.11'

192.0.2.0/24 is documentation address space. Don’t copy it into production.

Join the domain:

Add-Computer -DomainName 'example.test' -Restart

You’ll receive a secure credential prompt.

After the restart, open Server Manager. Confirm the server identity, update state, network settings, and intended roles.

Keep the temporary identity until the role’s cutover procedure says otherwise. Early hostname or address reuse creates duplicate records and makes rollback harder.

Expected result: The destination is patched, supported, monitored, protected, and ready to receive a role.

Step 12: Migrate Active Directory Domain Services and DNS side by side

For a domain controller, add a new Windows Server 2025 controller first. Test it, then demote the old controller later. This keeps the OS change away from the existing directory database.

Confirm the forest and domain functional levels and supported domain-controller operating systems:

Get-ADForest |
    Select-Object Name, ForestMode, SchemaMaster, DomainNamingMaster

Get-ADDomain |
    Select-Object DNSRoot, DomainMode, PDCEmulator, RIDMaster, InfrastructureMaster

Install AD DS and DNS on the destination:

Install-WindowsFeature `
    -Name AD-Domain-Services,DNS `
    -IncludeManagementTools

Expected output:

Success Restart Needed Exit Code Feature Result
——- ————– ——— ————–
True No Success {Active Directory Domain Services, DNS Server}

In Server Manager:

• Select the notification flag.
• Select Promote this server to a domain controller.
• Choose Add a domain controller to an existing domain.
• Enter the domain and authorized credentials.
• Select Domain Name System (DNS) server and Global Catalog (GC) as required.
• Leave Read only domain controller (RODC) clear unless the design requires it.
• Enter a Directory Services Restore Mode password.
• Select the correct replication source or allow automatic selection.
• Review the database, log, and SYSVOL paths.
• Run the prerequisite check.
• Select Install only after fixing all blocking issues.

The server restarts after promotion.

Validate the new domain controller:

dcdiag.exe /s:WS25-DEST01 /c /v
repadmin.exe /replsummary
repadmin.exe /showrepl WS25-DEST01
Get-SmbShare -CimSession WS25-DEST01 -Name SYSVOL,NETLOGON

Force a replication convergence test if the change plan requires one:

repadmin.exe /syncall WS25-DEST01 /AdeP

/A covers all naming contexts. /d identifies servers by distinguished name, /e includes other sites, and /P pushes changes outward.

Verify DNS:

Resolve-DnsName -Server 'WS25-DEST01' -Name 'example.test'
Resolve-DnsName -Server 'WS25-DEST01' `
    -Name '_ldap._tcp.dc._msdcs.example.test' `
    -Type SRV

Open Server Manager > Tools > DNS. Check forward zones, reverse zones, _msdcs, delegated zones, and expected AD records.

Open Server Manager > Tools > Active Directory Users and Computers. Connect to the new controller. Check that expected organizational units and test objects appear.

Don’t transfer Flexible Single Master Operations (FSMO) roles just because the new server is online. Transfer them only when the design calls for it and directory health stays clean:

Move-ADDirectoryServerOperationMasterRole `
    -Identity 'WS25-DEST01' `
    -OperationMasterRole SchemaMaster,DomainNamingMaster,PDCEmulator,RIDMaster,InfrastructureMaster `
    -Confirm

After the observation period, confirm that clients and services no longer depend on the old controller. Then demote it through Server Manager > Manage > Remove Roles and Features > Active Directory Domain Services > Demote this domain controller.

Never force removal from a healthy, reachable domain. After a normal demotion, check that DNS and Active Directory metadata were removed.

Expected result: The new controller advertises, authenticates, resolves DNS, replicates every naming context, and supplies SYSVOL and NETLOGON without errors.

Step 13: Migrate file shares, share permissions, and NTFS permissions

For large or complex file servers, Microsoft’s Storage Migration Service can inventory, transfer, and cut over supported servers. It can retain more server identity data than a basic copy. The trade-off is extra setup and more permission testing.

For a controlled manual move, create the destination volume and copy data with Robocopy. Run the first pass while users remain online:

robocopy.exe '\\\\SOURCE01\\D$\\Shares' 'D:\\Shares' `
    /E /COPYALL /DCOPY:DAT /SECFIX /TIMFIX `
    /ZB /R:2 /W:5 /MT:16 `
    /XJ /TEE /LOG:C:\\Migration\\Robocopy-Initial.log

The important flags are:

• /E copies subdirectories, including empty ones.
• /COPYALL copies data, attributes, timestamps, NTFS access control lists, owner, and auditing data.
• /DCOPY:DAT preserves directory data, attributes, and timestamps.
• /SECFIX reapplies security to skipped existing files.
• /TIMFIX reapplies timestamps to skipped existing files.
• /ZB uses restartable mode and falls back to backup mode.
• /R:2 /W:5 retries twice with a five-second wait instead of retrying for days.
• /MT:16 uses 16 threads. Raise this only after testing storage and network load.
• /XJ prevents loops through junction points.
• /LOG writes a migration log you can keep.

Robocopy exit codes 0 through 7 can mean success under different copy conditions. Code 8 or higher means at least one failure.

Review the exit code at once:

$LASTEXITCODE

Export source share definitions and share permissions:

Get-SmbShare -CimSession 'SOURCE01' |
    Where-Object Special -eq $false |
    Select-Object Name, Path, Description, FolderEnumerationMode, EncryptData |
    Export-Csv 'C:\\Migration\\SourceShares.csv' -NoTypeInformation

Get-SmbShare -CimSession 'SOURCE01' |
    Where-Object Special -eq $false |
    ForEach-Object {
        Get-SmbShareAccess -CimSession 'SOURCE01' -Name $_.Name
    } |
    Export-Csv 'C:\\Migration\\SourceShareAccess.csv' -NoTypeInformation

/COPYALL preserves NTFS permissions on copied files and folders. It does not create SMB shares or share-level permissions. Recreate each approved share on the destination.

Example:

New-SmbShare `
    -Name 'DepartmentData' `
    -Path 'D:\\Shares\\DepartmentData' `
    -Description 'Department shared files' `
    -FolderEnumerationMode AccessBased

Grant-SmbShareAccess `
    -Name 'DepartmentData' `
    -AccountName 'EXAMPLE\\Department-File-Users' `
    -AccessRight Change `
    -Force

Revoke-SmbShareAccess `
    -Name 'DepartmentData' `
    -AccountName 'Everyone' `
    -Force

Don’t blindly recreate administrative, application-created, or hidden shares. Check the owner and dependency of each share first.

For final cutover:

• Tell users and applications when writes must stop.
• Remove the source share from DFS referrals or make the application read-only.
• Confirm that no files remain open.
• Run a final sync with the same tested Robocopy options.
• Add /MIR only if the approved design requires destination deletions to match the source.

Warning: /MIR can delete destination files that don’t exist on the source. Never add it to the first copy. Never run it against an unverified path.

Check open files on the source:

Get-SmbOpenFile |
    Select-Object ClientComputerName, ClientUserName, Path

Compare destination shares and permissions:

Get-SmbShare |
    Where-Object Special -eq $false |
    Select-Object Name, Path, CurrentUsers

Get-SmbSession |
    Select-Object ClientComputerName, ClientUserName, NumOpens

Test with representative user accounts. Check read, create, modify, rename, delete, and denied access where each should apply. Admin testing tends to hide the permission mistakes users find at 08:03.

Expected result: File counts and logs match. NTFS access lists remain intact, SMB permissions match the approved design, and test users get the expected access.

Step 14: Migrate other roles with role-specific procedures

Don’t invent one copy method for DHCP, IIS, Hyper-V, certificate services, clustering, and third-party applications. Each role stores state differently and has its own supported cutover process.

For each remaining role:

• Find its migration page in the current Windows Server documentation.
• Confirm that the page applies to both the source release and Windows Server 2025.
• Check whether the role needs Windows Server Migration Tools, Storage Migration Service, export/import, replication, backup/restore, or a vendor installer.
• Confirm required schema, database, runtime, and license versions.
• Build the destination role without sending production traffic to it.
• Import settings and data through the supported method.
• Run a functional test.
• Run a final sync if the workload permits it.
• Cut over DNS, load balancing, aliases, routes, or client settings.
• Keep the source recoverable until the rollback deadline passes.

When hostnames can’t change, consider a DNS alias, DFS namespace, load balancer address, Storage Migration Service identity cutover, or application connection alias. Renaming a server after installing a tightly coupled role often creates more work than keeping an indirection layer.

Expected result: Every role used its Microsoft- or vendor-supported migration path and has a recorded functional test.

Step 15: Validate the migrated server

Start with the operating system:

Get-ComputerInfo |
    Select-Object WindowsProductName, WindowsVersion, OsBuildNumber

Get-Service |
    Where-Object StartType -eq 'Automatic' |
    Where-Object Status -ne 'Running' |
    Select-Object Name, DisplayName, Status, StartType

Get-Volume |
    Select-Object DriveLetter, HealthStatus, SizeRemaining

Get-NetIPConfiguration

A stopped automatic service doesn’t always mean a fault. Some services use trigger start. Compare the result with the old inventory and check role-specific services.

Confirm name resolution and connectivity:

Resolve-DnsName -Name 'example.test'
Test-NetConnection -ComputerName 'dependency.example.test' -Port 443

Replace the example names and port with documented dependencies.

For Active Directory, repeat:

dcdiag.exe /e /c /v /f:C:\Migration\PostMigration-DcDiag.txt
repadmin.exe /replsummary
repadmin.exe /showrepl * /csv > C:\Migration\PostMigration-Replication.csv

For file services:

Get-SmbShare |
    Where-Object Special -eq $false |
    Select-Object Name, Path, CurrentUsers

Get-SmbSession |
    Select-Object ClientComputerName, ClientUserName, NumOpens

Test applications from a client. A service in the Running state doesn’t prove that DNS, firewalls, certificates, authentication, load balancing, or permissions work.

Complete these tests:

• Sign in with a representative user account.
• Open each application through its production URL or client.
• Create and retrieve a test transaction where safe.
• Confirm scheduled tasks run under their intended service accounts.
• Check certificate bindings, chains, names, and expiration dates.
• Run an on-demand backup and restore a sample file or object.
• Confirm monitoring data, logs, alerts, and asset inventory are arriving.
• Check antivirus or endpoint protection health and policy assignment.
• Confirm patch-management enrollment.
• Compare performance and error rates with the old baseline.

Review at least these Event Viewer locations:

• Windows Logs > System
• Windows Logs > Application
• Windows Logs > Security for relevant audit failures
• Applications and Services Logs > Microsoft > Windows > ServerManager-ManagementProvider
• Setup
• Directory Service, DNS Server, and DFS Replication for domain controllers
• Microsoft-Windows-SMBServer for file servers
• Any application-, cluster-, Hyper-V-, IIS-, backup-, or security-agent-specific log

Use a fixed migration time range. Otherwise, five-year-old warnings can bury tonight’s failures.

Expected result: Every test passes, monitoring and backups work, and no unexplained critical or repeating error remains.

Step 16: Observe before retiring the old server

Keep the source after a side-by-side cutover for at least one full business cycle. For most business servers, 7 to 14 days is a practical minimum. Use 30 days when you need to see month-end processing, patch cycles, backup retention, or rare jobs.

Set the exact period from workload cycles, compliance, license terms, security exposure, and write handling. Don’t leave the old server online forever with duplicate services. Two writable copies turn rollback into data cleanup.

During the observation window:

• Isolate or disable the old application service so clients can’t write to both systems.
• Keep the server patched and protected while it remains connected.
• Watch DNS queries, SMB sessions, firewall logs, and application connections for hidden dependencies.
• Test daily, weekly, month-end, and backup jobs.
• Keep the source backup separate from the powered-off system.
• Record accepted differences and new operating procedures.

After final approval:

• Take a final backup under the retention policy.
• Remove old DNS, monitoring, backup, load balancer, and management entries.
• Demote domain controllers normally before removal.
• Remove stale computer accounts only after clearing dependencies.
• Revoke old certificates and service credentials where needed.
• Erase or reuse storage under your policy.
• Update diagrams, asset records, recovery documents, and support ownership.

Expected result: Close the rollback period only after all required workload cycles pass and stakeholders approve decommissioning.

Configuration

Recommended migration settings

Setting	Recommended pattern	Why
Migration method	Side by side for domain controllers and high-risk roles	Preserves the source and supports staged validation
Update baseline	Latest approved cumulative update available immediately before migration	Avoids publishing or relying on a superseded KB
Installation media	Matching language, architecture, edition, and installation type	Required to retain supported applications and settings
Free space	At least 32 GB on the OS volume, with extra working space	Setup needs room for staging and rollback files
Robocopy retries	/R:2 /W:5	Prevents locked files from stalling the copy for hours
File copy threads	Start with /MT:16	Improves throughput without immediately overwhelming storage
Rollback decision	Before the recovery-time reserve begins	Leaves enough time to restore service
Source retention	7–14 days normally; 30 days for monthly workloads	Allows hidden dependencies and scheduled jobs to surface
Validation	Server-side and representative client-side tests	A running service does not prove end-to-end access
Backup	Full, application-aware, and system state where applicable	Covers failure modes that a VM checkpoint does not

These defaults favor recovery over speed. /MT:16, for example, is a starting point rather than a speed promise. Test it against your storage under normal load before raising the thread count.

Minimize downtime without skipping checks

A low-downtime migration moves most work outside the outage:

• Build and patch the destination in advance.
• Install roles and applications without enabling production traffic.
• Copy the bulk of the data while the source remains online.
• Lower DNS time to live only for a DNS cutover. Do it before cached values need to expire.
• Drain application traffic before stopping services.
• Freeze writes only for the final sync.
• Run a short, written smoke test before admitting users.
• Continue deeper tests after service resumes.
• Keep the source recoverable until the rollback deadline passes.

Rehearsal and parallel work reduce downtime. Removing health checks only moves the outage into business hours.

Tips and Troubleshooting

The “Keep files, settings, and apps” option is unavailable

Why it happens: The media language, edition, installation type, or upgrade path doesn’t match the source. You may also have booted from the ISO instead of starting setup inside the running source OS.

Fix:

• Exit setup without installing.
• Confirm the source edition and installation type with Get-WindowsEdition -Online and the registry command from Step 2.
• Confirm that the media language matches the installed language.
• Start setup.exe from the running Windows Server installation.
• Check Microsoft’s current upgrade matrix.
• Use side-by-side migration if the exact combination is unsupported.

Don’t try to persuade setup with another image choice. A missing retention option is a stop condition, not an awkward checkbox.

Setup reports an incompatible application or driver

Why it happens: Antivirus, backup, storage, network, monitoring, or business software may install components that Server 2025 setup can’t retain.

Fix:

• Save the complete compatibility report.
• Identify the product and installed version.
• Get the Server 2025-supported release and procedure from its vendor.
• Back up the product configuration.
• Upgrade or remove the blocker during the approved window.
• Reboot and run setup readiness again.
• Don’t override an unresolved kernel driver or storage warning.

Setup fails because the system partition lacks space

Why it happens: The EFI System Partition or System Reserved partition can be too small even when C: has plenty of free space.

Fix:

• Save the setup log and exact error.
• Open Disk Management and identify the boot and system partitions.
• Back up the server.
• Follow Microsoft’s supported resize guidance for the disk layout.
• Don’t delete recovery or boot partitions to make space.
• Rerun compatibility checks before installation.

This fault is easy to misread because the OS volume may have hundreds of gigabytes free. Setup also needs space on partitions without drive letters.

Setup rolls back to Windows Server 2019 or 2022

Why it happens: A driver, service, pending update, disk fault, or incompatible application stopped setup.

Fix:

• Confirm that the old operating system is stable.
• Copy setup logs from C:\$WINDOWS.~BT\Sources\Panther and C:\Windows\Panther to the migration folder.
• Review setuperr.log, setupact.log, and compatibility reports.
• Check storage health and pending reboots.
• Fix the named blocker.
• Don’t rerun setup without changing the failed condition.
• Switch to side-by-side migration if the risk now exceeds the maintenance plan.

A second identical attempt usually gives you a second identical rollback. Save the logs before cleanup removes the evidence.

The upgraded server starts, but a critical service does not

Why it happens: The service may have a missing dependency, unsupported runtime, changed credential, blocked port, or incompatible driver.

Fix:

Get-Service -Name 'YourServiceName'

Get-CimInstance Win32_Service -Filter "Name='YourServiceName'" |
    Select-Object Name, State, StartMode, StartName, PathName

Replace YourServiceName with the real service name.

Then:

• Review the System and Application logs at the service start time.
• Test DNS and each documented dependency.
• Confirm the service account can sign in and access needed files or certificates.
• Check the vendor’s Windows Server 2025 support statement.
• Roll back if you can’t restore the service before the recovery deadline.

Active Directory replication fails after promotion

Why it happens: Common causes include bad DNS settings, blocked Remote Procedure Call traffic, time skew, stale metadata, or earlier replication faults.

Fix:

• Configure the new controller to use existing internal AD DNS servers during promotion.
• Confirm forward and reverse name resolution.
• Run repadmin.exe /replsummary.
• Run repadmin.exe /showrepl WS25-DEST01.
• Review Directory Service, DNS Server, DFS Replication, and System logs.
• Fix the cause before transferring FSMO roles or demoting another controller.
• Never use forced demotion as a shortcut around a repairable replication fault.

Keep the old controller until replication is clean. Removing a healthy partner while testing the new one cuts your recovery options.

Users can see a share but receive Access Denied

Why it happens: NTFS and SMB share permissions are separate. Robocopy can keep NTFS access lists, but it doesn’t recreate the share or its share-level entries.

Fix:

Get-SmbShareAccess -Name 'DepartmentData'
Get-Acl -Path 'D:\Shares\DepartmentData' | Format-List

Compare both permission layers with the source. Test with a representative user. Elevated accounts can hide access faults.

Robocopy returns a nonzero exit code

Why it happens: Robocopy uses a bitmask-style result. Codes 1 through 7 don’t always mean failure.

Fix:

• 0: No files copied; source and destination already match.
• 1: Files copied successfully.
• 2 through 7: Extra files, mismatches, or copied files need review, but the run may still be usable.
• 8 or higher: At least one copy failure occurred.

Review the log, fix failed paths or permissions, and rerun the same tested command. Treating every nonzero code as failure creates noisy alerts and needless reruns.

Backup or monitoring jobs stop reporting

Why it happens: The agent may lack Server 2025 support. It may also have lost its certificate, server identity, firewall access, or job assignment.

Fix:

• Check the vendor’s support matrix.
• Update or reinstall the agent with the vendor’s procedure.
• Confirm the server appears in the correct job and policy.
• Run an on-demand backup.
• Restore a test item.
• Generate a controlled monitoring test or check a current metric.
• Keep the migration open until backup and monitoring both work.

A green application test doesn’t cover a missing backup. The migration stays open until recovery and monitoring work on the destination.

An older guide names a different prerequisite KB

Why it happens: Monthly cumulative updates replace older packages, so a correct KB reference can age quickly.

Fix:

• Record the source release and build.
• Check Microsoft’s current Windows Server release-health page.
• Check the current Windows Server 2025 upgrade page for an explicit prerequisite.
• Use the latest approved cumulative update for the source.
• Record the KB, build, installation time, and verification date in the change ticket.

Wrapping Up

Step	Action	Applies To
1	Choose the migration path	Both methods
2–7	Inventory, patch, check compatibility, and verify AD health	Both methods
8–9	Back up and define rollback conditions	Both methods
10	Run setup from matching Server 2025 media	In-place upgrade
11–14	Build the destination and migrate each role	Side-by-side migration
15	Validate services, clients, logs, backups, and monitoring	Both methods
16	Observe before decommissioning	Side-by-side migration

Use an in-place upgrade for a clean, supported member server with a tested restore path. Use a side-by-side migration for domain controllers, file servers, old hardware, and applications that need separate dependency tests.

Preparation takes time before cutover. It also keeps the source recoverable and sets clear rollback limits when Monday morning arrives.