What should be inventoried before a server migration?

Everything the old server quietly does: roles, applications, file shares, scheduled tasks, databases, printers, integrations, and which person depends on each. Most migration surprises are things nobody knew the server was doing.

Should I upgrade in place or migrate side by side?

Side by side for aging hardware or old Windows versions: build the destination cleanly, move workloads deliberately, and keep the old server as rollback. In-place upgrades carry every past mistake forward.

When should users move to the new server?

Only after the destination passes real-workflow tests: sign in, open the business app, print, save, restore a file. Then run both servers in parallel briefly with rollback ready.

What protects the business during cutover?

A verified backup of the source, a snapshot before every major change, a written rollback plan, and a schedule with slack. Cutovers fail safely when the old system is one decision away.

Server Migration Checklist for Windows Server (2026)

In short

A server migration checklist should answer five questions before production moves: what the current Windows Server does, what must move, how the destination will be built, how users will be tested, and exactly how you will roll back if cutover fails. Raff Technologies recommends a side-by-side migration for many small-business Windows workloads because the old server can remain available while the new Windows VM is built, tested, synchronized, and validated.

Do not treat migration as a file-copy task. A Windows Server can contain Active Directory, DNS, RDS, SQL Server, IIS, business applications, scheduled tasks, certificates, printers, service accounts, file shares, backup jobs, and integrations that fail independently.

For most small businesses, the safe order is:

Text

Inventory
-> classify workloads
-> choose migration method
-> build destination
-> protect source
-> migrate and test
-> freeze writes
-> final sync
-> cut over
-> validate users
-> keep rollback
-> monitor

If the source is Windows Server 2016, extended support ends on January 12, 2027. Start compatibility testing and migration planning before that date rather than treating the support deadline as the project start date.

Server migration checklist for small businesses

Use this as the control list for the project.

Phase	Checklist item
Scope	List every server role, application, database, share, user, service account, certificate, and dependency
Destination	Decide whether the target is a new physical server, Windows VM, or hybrid environment
Migration method	Choose in-place upgrade, side-by-side migration, clean rebuild, or role-specific migration
Access	Plan RDP, RDS, RD Gateway, VPN/private access, DNS, firewall rules, and user authentication
Applications	Confirm vendor support, installers, versions, licences, service accounts, and data locations
Files	Inventory shares, NTFS permissions, mapped drives, open files, storage use, and growth
Databases	Plan SQL Server backup/restore, logins, jobs, connection strings, permissions, and validation
Active Directory	Review DC health, DNS, FSMO roles, GPOs, replication, DHCP, and time synchronization
Protection	Take source backups and verify a restore path before migration work starts
Testing	Test real business workflows, not only server boot or administrator login
Cutover	Freeze writes, run final sync, switch users and endpoints, then validate
Rollback	Define the rollback trigger, owner, deadline, data handling, and old-server state
Monitoring	Watch CPU, RAM, disk, backups, authentication, services, jobs, and user issues after cutover
Documentation	Record credentials, access paths, licences, backup ownership, support contacts, and recovery steps

Roadmap visual showing Windows Server migration phases from inventory to cutover and monitoring

The goal is not zero change. The goal is controlled change with enough evidence to know when the destination is ready.

Choose the migration method before building the destination

Microsoft distinguishes several Windows Server upgrade and migration methods, including in-place upgrade, clean install, migration to another server, and cluster rolling upgrade. Starting with Windows Server 2025, supported nonclustered systems can upgrade across as many as four Windows Server versions in one supported path, subject to edition, role, application, and platform restrictions.

That does not mean every server should be upgraded in place.

Approach	What it does	Best fit
In-place upgrade	Installs a newer Windows Server version over the existing OS while retaining supported roles, settings, and data	Simple healthy member or application server where the workload supports the target OS
Side-by-side migration	Builds a separate destination and moves roles, apps, data, and users to it	Cloud moves, hardware replacement, mixed-role servers, cleaner rollback
Clean rebuild	Installs the destination from scratch and recreates only required services	Poorly documented, unstable, or heavily cluttered legacy servers
Role-specific migration	Uses Microsoft or vendor-supported migration workflows for services such as file server, AD DS, DHCP, IIS, or RDS	Infrastructure roles with their own migration requirements
Cluster rolling upgrade	Upgrades supported cluster nodes in sequence	Supported failover-cluster scenarios where availability must be maintained

For small businesses moving an office server to a cloud Windows VM, side-by-side migration is often the easiest method to test and reverse.

Architecture visual showing side-by-side Windows Server migration from old office server to cloud Windows VPS

When in-place upgrade can make sense

Consider it when:

the source server is healthy and well documented;
the server role supports the path;
every business application supports the target Windows Server version;
the hardware or virtualization platform supports the upgrade;
you have a verified full recovery path;
the required downtime is acceptable.

When side-by-side migration is safer

Prefer it when:

you are moving from local hardware to cloud infrastructure;
the server has several unrelated roles;
the source is old, undocumented, or unstable;
Active Directory is involved;
you want to change the storage or network architecture;
vendor software should be installed cleanly;
rollback simplicity matters.

Microsoft's current role migration matrix specifically recommends migration rather than treating AD DS as an ordinary in-place upgrade case.

Windows Server 2016 migrations now have a fixed deadline

Windows Server 2016 reaches the end of extended support on January 12, 2027. That makes 2026 migration planning especially important for organizations still running Server 2016.

A practical schedule is:

Inventory and application compatibility now.
Choose the target Windows Server release and destination architecture.
Build a test destination.
Run at least one migration rehearsal for critical applications or data.
Schedule production cutover with enough time for remediation before January 12, 2027.

If your source is Server 2016, use the dedicated Windows Server 2016 to 2025 migration guide for version-specific upgrade and AD DS guidance.

Phase 1: inventory everything the current server does

Most failed migrations are discovery failures first.

Document:

Area	What to capture
Server identity	Hostname, IP addresses, OS/version/build, edition, activation, domain membership
Windows roles	AD DS, DNS, DHCP, RDS, IIS, file services, print services
Applications	Product, version, install path, vendor, licence, support status
Users	Administrators, staff users, groups, service accounts
Files	Shares, NTFS permissions, share permissions, mapped drives, storage use
Databases	SQL instances, databases, jobs, maintenance plans, logins, linked servers
Scheduled work	Scheduled Tasks, scripts, exports, sync jobs, backup jobs
Certificates	IIS, RD Gateway, VPN, internal application certificates, expiry dates
Network	Firewall rules, listening ports, DNS records, NAT, VPN/private paths
Remote access	Admin RDP, RDS Session Host, RD Gateway, profiles, licensing
Backups	Software, schedule, destination, retention, encryption, restore status
Dependencies	Printers, scanners, mapped drives, APIs, SMTP, external shares, vendor services

Useful PowerShell inventory examples include:

Powershell

Get-ComputerInfo | Select-Object WindowsProductName, WindowsVersion, OsBuildNumber
Get-WindowsFeature | Where-Object InstallState -eq 'Installed'
Get-Service | Where-Object Status -eq 'Running'
Get-ScheduledTask | Where-Object State -ne 'Disabled'
Get-SmbShare
Get-NetFirewallRule -Enabled True

Do not delete or "clean up" the source during inventory. Record first, then decide what should change.

Phase 2: classify each workload as migrate, rebuild, replace, or retire

Not everything on the old server deserves to reach the new one.

Decision	Meaning
Migrate	Still required and should move with its supported migration method
Rebuild	Still required, but should be installed cleanly on the destination
Replace	Better handled by a newer SaaS, managed service, or architecture
Retire	No longer used and should not consume destination resources

Examples:

Active accounting application: migrate or rebuild.
Old employee profile folders: archive or retire.
Current SQL database: migrate with a database-specific plan.
Legacy application with no Server 2025 support: replace, isolate, or choose a supported target OS.
Abandoned installer directories: retire.
Old local backup folders: replace with the new backup design.

This step prevents a clean destination from becoming a copy of years of old server clutter.

Phase 3: choose the destination from workload data

Do not size a new Windows VM from the old server's marketing label alone. Record real use first:

peak CPU;
peak and available RAM;
used disk space;
storage growth;
peak concurrent RDP/RDS sessions;
database size and growth;
backup size;
busiest application periods.

For remote-user workloads, use Windows VPS sizing for remote users. If you are deciding whether cloud hosting is appropriate at all, see Cloud Windows Server vs Local Office Server.

A migration is also a good time to stop placing every role on one Windows Server. Separate roles when it improves security, maintenance, performance isolation, recovery, or vendor support.

For example:

Text

VM 1: AD DS / DNS
VM 2: RDS or business application
VM 3: SQL Server when workload and licensing justify separation

Do not split roles just to make the diagram look more enterprise. Every extra server adds cost, patching, backup, and operational work.

Phase 4: plan remote access before users move

Remote access changes both architecture and licensing.

Access need	Planning direction
One or two administrators	Restricted administrative RDP may be sufficient
Staff need daily shared desktop sessions	Use RDS Session Host and the correct hosted licensing model
Users connect from changing locations	Consider RD Gateway or another controlled access layer
Users need broad private network access	Consider VPN/private access rather than exposing multiple services publicly
Users only need a web app	Avoid giving a full Windows desktop unnecessarily
MSP manages several client servers	Standardize access policy, MFA approach, monitoring, and documentation

For external RDS access, compare Remote Desktop Gateway vs direct RDP.

Do not use Windows Server's administrative Remote Desktop sessions as a substitute for a properly designed multi-user RDS deployment.

Phase 5: protect the source and prove recovery

Before the first major change, protect the environment you already have.

Recovery item	Why it matters
Whole-server backup	Recovery if migration work damages the source
File backup	Restore shares and user data separately
SQL/app backup	Consistent recovery for databases and business applications
System State	Important for supported Windows infrastructure recovery scenarios
Certificate export	Prevent loss of IIS, RD Gateway, or application identity material
Configuration export	Preserve firewall, tasks, IIS, application, and role settings
Restore test	Proves the backup is actually usable

A successful backup job is not a successful restore test.

For a production Windows VM destination, review Windows VPS Backup Strategy for Small Businesses before the cutover.

Phase 6: build and harden the destination before production data arrives

The new Windows Server should be ready before users depend on it.

Prepare:

a supported Windows Server version;
correct CPU, RAM, and storage;
current Windows updates;
named administrator accounts;
Windows Firewall rules;
Defender or the approved endpoint-security stack;
remote access controls;
private networking where roles communicate internally;
backup and recovery settings;
monitoring;
DNS and hostname strategy;
application prerequisites;
licensing and activation path.

Apply a role-appropriate Windows Server hardening checklist before cutover, not weeks afterward.

Phase 7: migrate file shares with permissions and paths in mind

File migration failures often appear as user problems after cutover rather than copy errors during migration.

Inventory:

share names;
NTFS ACLs;
share permissions;
security groups;
file ownership;
mapped drive letters;
UNC paths;
open files;
long paths and unusual filenames;
quotas;
application folders;
backup exclusions or policies.

Microsoft's Storage Migration Service can inventory and transfer supported file-server data and configuration to newer Windows Server systems. Its workflow includes inventory, transfer, cutover, and post-migration operations. It applies to Windows Server 2025, 2022, 2019, and 2016 scenarios supported by the service.

Use it when the file-server scope fits the tool. Do not treat Storage Migration Service as a universal migration engine for SQL Server, Active Directory, or third-party applications.

Phase 8: migrate applications with vendor support as a hard gate

A Windows migration can be technically successful while the business application is unsupported.

For each application, confirm:

App item	What to verify
OS support	Does the vendor support the target Windows Server version?
RDS support	Is multi-user or RemoteApp use supported?
Installer	Do you have the correct supported installer?
Licence	Does activation transfer to a new VM or hardware identity?
Data	Where is production data stored and how is it moved?
Services	Which Windows service accounts are required?
Dependencies	.NET, ODBC, runtimes, drivers, Office components, Java, VC++ runtimes
Printing	Are printer drivers, labels, PDF tools, or redirected printers required?
Network	What ports, DNS names, UNC paths, APIs, or SMTP services are used?
Recovery	How do you return users to the source if validation fails?

Test the actual workflow, such as opening a company file, posting a transaction, generating a report, printing, exporting, and closing the application cleanly.

Phase 9: treat SQL Server as its own migration project

SQL Server migration is more than moving .mdf and .ldf files.

Plan:

SQL Server version and edition;
supported database upgrade path;
full, differential, and log backups as appropriate;
database owners;
compatibility level;
SQL and Windows logins;
login SIDs;
SQL Agent jobs;
maintenance jobs;
linked servers;
credentials;
certificates and keys;
Database Mail;
connection strings;
firewall ports;
backup jobs on the destination.

For many small-business migrations, backup and restore provides a repeatable test path. Restore the database on the destination before production cutover and point a test application instance at it.

Do not call the migration successful until the application, not only SSMS, can use the restored database.

Phase 10: migrate Active Directory role by role

If the old server is a domain controller, use a dedicated AD DS migration plan.

Check:

AD area	What to verify
Domain controllers	Current DC list, OS versions, Global Catalog status
Replication	`repadmin /replsummary` and `repadmin /showrepl` health
DNS	Zones, forwarders, client DNS configuration, stale dependencies
FSMO	Current role holders
GPOs	Drive maps, scripts, security settings, software deployment
DHCP	Scopes, reservations, options, failover, relay/IP helpers
Time	PDC and upstream time-source design
Certificates	AD CS or internal certificate dependencies
Decommission	Graceful demotion and post-demotion validation

Microsoft's current role matrix lists AD DS migration as supported and says in-place upgrade is not the recommended approach for getting the newer AD DS performance and feature improvements. Build a clean newer DC, replicate, validate, move roles, then demote the old DC through the supported workflow.

If the project is specifically Server 2016 to Server 2025, use Upgrade Windows Server 2016 to 2025 for the full DC path.

Phase 11: create a migration test plan with business owners

The administrator should not be the only person testing the destination.

Test area	Example acceptance test
Login	Intended users can sign in and unauthorized users cannot
RDP/RDS	Remote sessions work from the expected locations
Files	Users can open, edit, save, and create files with correct permissions
Accounting/ERP	Approved transaction and reporting workflow succeeds
SQL Server	Application connects and performs a safe business transaction
IIS	Site loads, authentication works, API/database connections succeed
Printing	Required printer, PDF, label, and redirected-print workflows work
Scheduled tasks	Exports, sync jobs, reports, and scripts execute successfully
Backups	Destination backup jobs complete
Restore	At least one representative restore test succeeds

Include the people who actually use the workload. A server can look healthy to an administrator while the accounting team cannot print invoices or the warehouse cannot generate labels.

Phase 12: write the cutover sequence before the maintenance window

A production cutover should be a checklist, not a live brainstorming session.

Example:

Notify users of the maintenance window.
Confirm the latest source backup and restore path.
Confirm destination backup is enabled.
Stop or freeze production writes where required.
Stop application services that would create conflicting writes.
Run the final file or database synchronization.
Restore or attach final application data on the destination.
Change DNS records, aliases, mapped drives, shortcuts, or connection strings.
Start destination services.
Validate administrator access.
Validate business-user access.
Test applications, files, reports, printing, jobs, and backups.
Decide go-forward or rollback before the agreed deadline.
Keep the old environment isolated or read-only until the new system is proven.

Final Windows Server migration cutover checklist showing backups, apps, files, RDS, SQL, rollback, and monitoring

Phase 13: define rollback before you need it

Rollback is a planned recovery action, not an admission that the project failed.

Document:

Rollback item	Question
Trigger	Which failures require rollback?
Owner	Who can make the rollback decision?
Deadline	How long can troubleshooting continue before recovery begins?
New writes	What happens to data written to the destination after cutover starts?
Old server	Is the source still intact and isolated from conflicting writes?
DNS/access	How will users return to the old path?
Communication	Who tells users and vendors that rollback is in progress?

Do not erase, repurpose, or permanently alter the old server immediately after the first successful login.

Phase 14: monitor the first days after migration

Watch both infrastructure and user behavior.

Signal	Why it matters
CPU	Detect undersizing and application spikes
RAM	Identify RDS, browser, ERP, and SQL memory pressure
Disk space	Prevent profile, database, file, and backup failures
Storage latency	Detect application slowdowns hidden behind normal CPU use
Backup success	Confirm the new recovery plan is working
Failed logons	Find access problems and suspicious authentication activity
Event logs	Catch services, drivers, certificates, and application errors
Scheduled tasks	Verify reports, sync jobs, and automation survived the move
SQL jobs	Confirm database maintenance and backups are running
User reports	Detect workflow failures that technical monitoring cannot see

Migration is complete when the destination is stable, protected, documented, and users can complete normal work.

Common server migration mistakes

Copying files before understanding dependencies

Inventory roles, applications, services, database connections, mapped drives, certificates, and scheduled tasks first.

Upgrading every Windows Server in place

In-place upgrade is a supported tool, not the default answer for every role. Side-by-side migration often provides cleaner testing and rollback, especially for cloud moves and mixed-role servers.

Treating Active Directory like a normal application server

Use a role-specific DC migration process and validate replication, DNS, FSMO, and client dependencies before demotion.

Moving SQL databases but forgetting instance objects

Databases, logins, jobs, linked servers, credentials, and server-level settings need separate attention.

Moving daily users onto admin RDP

Administrative RDP and a licensed RDS Session Host deployment are not the same thing.

Forgetting vendor licensing

Applications can fail after migration because activation is tied to hardware, hostname, MAC address, licence server, or vendor approval.

Testing only whether the server boots

Validate real business workflows with real users.

Changing too many names and paths during the same cutover

A migration already creates risk. Avoid unnecessary simultaneous changes to hostnames, drive letters, application versions, paths, authentication, and network design unless the project specifically requires them.

Keeping no rollback window

A source server removed immediately after cutover turns every post-migration issue into an emergency.

How Raff fits a Windows Server migration

Raff Windows VMs can be the destination when a business wants to move Windows workloads away from aging office hardware or another cloud VM while keeping a self-managed Windows Server model.

Typical migration targets include:

RDP/RDS business application servers;
accounting and tax software;
IIS and ASP.NET applications;
SQL Server workloads;
Windows file-server workloads;
Active Directory and DNS where the architecture supports cloud-hosted DCs;
MSP-managed client servers.

Raff provides the Windows VM infrastructure. Application compatibility, guest OS configuration, Microsoft and third-party licensing, role migration, testing, and production cutover still need to be planned for the actual workload.

Use Raff Windows VM and pricing only after CPU, RAM, storage, user count, licensing, and backup requirements are understood.