Use this Windows Server migration checklist to plan apps, files, users, RDP/RDS, SQL Server, Active Directory, backups, testing, cutover, and rollback. Category: migration

A Windows Server migration checklist helps small businesses move users, apps, files, databases, Remote Desktop access, and backups without turning the cutover into guesswork. Before migrating to a new Windows Server or cloud Windows VPS, document what the old server does, test the destination, protect the data, plan rollback, and move production only after users can complete real workflows. Raff Technologies provides Windows VMs and Windows migration support for teams that want to move Windows workloads to cloud-hosted infrastructure.

A server migration is not only an operating system task. It is a business continuity task. The server may hold files, accounting software, SQL Server databases, Active Directory, Remote Desktop users, IIS apps, printers, scheduled jobs, certificates, mapped drives, and vendor software.

That is why small businesses should not start with “copy everything to the new server.” Start with the checklist. Then decide what should migrate, what should be rebuilt, what should be retired, and what needs a test before the cutover.

Quick migration checklist

Use this table as the short version before starting the project.

Phase	Checklist item
Scope	List every server role, app, database, share, user, and dependency.
Destination	Decide whether the new environment is a physical server, cloud Windows Server, or Windows VPS.
Access	Plan RDP, RDS, RD Gateway, VPN, DNS, firewall rules, and user access.
Apps	Confirm vendor support, installers, licenses, versions, and data locations.
Files	Inventory shared folders, NTFS permissions, mapped drives, and storage growth.
Databases	Plan SQL Server backup/restore, logins, jobs, connection strings, and tests.
Active Directory	Review domain controllers, DNS, FSMO roles, GPOs, and replication if AD is involved.
Backups	Take source backups and confirm destination backup policy before cutover.
Testing	Test real user workflows, not only server login.
Cutover	Schedule downtime, freeze writes, copy final data, switch users, and verify.
Rollback	Keep the old environment available until the new one is proven.
Documentation	Record credentials, access paths, support owners, backups, and restore steps.

The goal is not to make migration complicated. The goal is to prevent surprises after users start working on the new server.

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

Need help planning your Windows Server migration? Talk to Raff before moving production users, files, apps, databases, and remote access.

Talk to Windows Engineer

Why migration planning matters for small businesses

Small businesses often run a lot of business logic on one server. The server may have started as a file share, then gained accounting software, remote users, SQL Server, printers, scheduled exports, vendor tools, and backup jobs over time.

That creates hidden migration risk.

Common hidden dependencies include:

Hidden dependency	Why it matters
Mapped drives	Apps may expect the same drive letter or UNC path.
Local service accounts	Services may stop if credentials are missing.
Scheduled tasks	Reports, exports, sync jobs, and backups may not run.
SQL logins	Database restores can succeed while app logins fail.
Printer drivers	Reports, labels, and PDFs may print differently.
Certificates	IIS, RD Gateway, VPN, or apps may depend on them.
DNS records	Users and apps may still point to the old server.
Firewall rules	Apps may need specific inbound or outbound ports.
Vendor licensing	Software activation may not survive a server move.
User permissions	Access may break if groups and NTFS permissions are not migrated correctly.

Visual showing hidden Windows Server migration dependencies including mapped drives, SQL logins, certificates, DNS, printers, and scheduled tasks

A migration checklist forces those issues into the open before the cutover.

Choose the migration approach first

Microsoft describes several methods for moving to a newer Windows Server version, including in-place upgrade, clean install, migration, cluster rolling upgrade, and edition conversion. Each method has different trade-offs for downtime, complexity, and hardware requirements.

For small businesses, the most common choices are:

Approach	What it means	Best fit
In-place upgrade	Upgrade the existing server OS while keeping roles and data	Lower hardware change, but higher risk if the old server is messy
Side-by-side migration	Build a new server and move roles/data/apps to it	Best for cleaner migrations and cloud Windows VPS moves
Clean rebuild	Reinstall apps and recreate settings manually	Good when old server is undocumented or unhealthy
File/data migration	Move shares and permissions to a new server	Good for file server replacement
App/database migration	Move app and database together	Good for business software, SQL, ERP, Access, tax tools
Hybrid migration	Keep some roles local and move others to cloud	Good when local devices or compliance needs remain

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

For Raff Windows VPS migrations, side-by-side migration is usually the cleaner model. You build the destination Windows VM, test it, copy data, verify apps, then cut over users.

Phase 1: inventory the current server

Do not migrate what you do not understand. Start with inventory.

Document:

Area	What to capture
Server identity	Name, IP address, OS version, domain membership
Roles	File server, AD DS, DNS, DHCP, RDS, IIS, SQL Server, print server
Applications	Business apps, versions, install paths, vendor contacts
Users	Admins, staff users, groups, service accounts
Files	Shares, folders, permissions, mapped drives
Databases	SQL instances, databases, jobs, maintenance plans
Scheduled tasks	Exports, reports, backups, scripts
Certificates	IIS, RD Gateway, VPN, internal app certificates
Firewall	Inbound/outbound rules and app-specific ports
Backups	Tools, schedules, destinations, retention, restore status
Dependencies	Printers, scanners, USB devices, integrations, APIs

Write this down before touching the destination server. Many migration problems are actually discovery problems.

Phase 2: decide what moves and what retires

Migration is a good moment to clean up. Not everything should move.

Sort workloads into four groups:

Group	Meaning
Migrate	Still used and must move to the new server
Rebuild	Still used, but should be installed cleanly
Replace	Better handled by SaaS, managed service, or newer architecture
Retire	No longer needed and should not move

Examples:

Item	Possible decision
Active accounting app	Migrate or rebuild
Old employee folders	Archive or retire
Abandoned app installer folders	Retire
SQL database for active ERP	Migrate carefully
Legacy Access database	Test and migrate with split design
Old user profiles	Migrate selectively
Print server role	Migrate only if still needed
Local backup folders	Replace with new backup strategy

Moving every old folder and app without review creates a new server with old clutter.

Phase 3: choose the destination environment

For small businesses, the destination is usually one of three options:

Destination	Best fit
New local server	Best when users are on-site, internet is unreliable, or local hardware is required
Cloud Windows Server / Windows VPS	Best for remote access, hosted apps, multi-location users, and office server replacement
Hybrid setup	Best when some roles must stay local and others can move to cloud

A Windows VPS is a strong fit when the business needs:

Remote Desktop access
shared Windows apps
cloud file server workloads
accounting or tax software
Microsoft Access or legacy apps
ERP or inventory software
SQL Server tools
IIS/.NET workloads
a replacement for aging office hardware

It is not always the right fit for high-availability architectures, heavy LAN-only file workloads, unsupported vendor apps, or local hardware dependencies that have not been tested.

Use Raff Windows VM as the destination environment for Windows Server migration, remote access, apps, and shared workloads.

Explore Windows VM

Phase 4: plan remote access and user sessions

If users will access the new server remotely, plan the access model before migration.

Use this table:

Access need	Planning direction
One or two admins only	Restricted admin RDP can work
Staff need daily desktop sessions	Plan RDS Session Host and RDS CALs
Users connect from changing networks	Consider RD Gateway or another controlled access layer
Users need mapped drives	Plan VPN/private access or RDP/RDS workflow
Users only need a web app	Do not give full desktop access unnecessarily
MSP manages the environment	Standardize access policy and documentation

Microsoft states that each user or device connecting to an RD Session Host running Windows Server needs an RDS Client Access License. Build that into migration planning before staff start using the new server daily.

Remote access is not just a port. It affects licensing, security, user experience, support, and backup risk.

Phase 5: protect the source before changing anything

Before migration work begins, protect the current environment.

Do this before the first major change:

Backup item	Why it matters
Full server backup	Recover if migration work damages the source
File backup	Restore shares and user data
Database backup	Recover SQL/app data cleanly
System state backup	Important for AD/domain-controller scenarios
App-specific backup	Required for accounting, ERP, tax, Access, and vendor apps
Export key settings	IIS, certificates, scheduled tasks, firewall rules, app configs
Restore test	Proves backup is usable

A backup that has never been restored is an assumption. At minimum, test restoring a file, a folder, and one business-critical app or database backup before cutover.

Phase 6: build the destination server cleanly

Build the destination before moving production data.

For a Windows VPS destination, prepare:

Item	Checklist
OS version	Choose supported Windows Server version
VM size	Size CPU, RAM, and storage for users and workload
Storage layout	Separate OS, data, app, or backup staging where useful
Admin users	Named admin accounts, no shared daily admin login
Firewall	Allow only required access paths
Updates	Patch Windows before production
Security baseline	Apply reasonable hardening before users connect
Monitoring	Track CPU, RAM, disk, backups, and failed logins
Backups	Enable backup policy before production data is stored
Documentation	Record server name, IPs, roles, users, and access model

Do not build the new server in a hurry and then try to harden it later. Production hardening should happen before cutover.

Phase 7: migrate file shares carefully

File server migration is often more sensitive than it looks. Users care about folder paths, permissions, mapped drives, and file versions.

For file shares, document:

File migration item	What to check
Share names	Keep or update share names deliberately
NTFS permissions	Preserve or redesign permissions
Share permissions	Confirm effective access
Security groups	Use groups instead of per-user permissions where possible
Mapped drives	Update scripts, GPOs, or documentation
File ownership	Watch for orphaned SIDs or old users
Long paths	Identify files that may fail to copy
Open files	Schedule cutover during low activity
Archive data	Do not migrate unnecessary old data
Backup	Confirm new file backup policy

Microsoft’s Storage Migration Service is designed to inventory servers, transfer data to newer Windows servers or Azure virtual machines, and optionally transfer the source server identity so apps and users do not need to change links or paths. For SMB file server migrations, that tool can be useful when the migration scope fits.

Phase 8: migrate applications and dependencies

Business apps are usually the hardest part of the migration.

Before installing or moving an app, confirm:

App migration item	What to check
Installer	Do you have the installer and license details?
Vendor support	Does the vendor support Windows Server / RDS / cloud VM use?
Data path	Where does the app store data?
Service accounts	Which Windows accounts run services?
Dependencies	.NET, ODBC, runtimes, drivers, Office/Access runtime
Printers	Reports, labels, PDFs, and print drivers
Mapped drives	Hardcoded drive letters or UNC paths
Firewall	Required ports and outbound access
Updates	App patch process and update timing
Rollback	How to return to the old app if testing fails

Do not judge migration success by whether the app opens. Test real workflows: create a record, edit data, run a report, export a file, print, email, sync, and close the day.

Phase 9: handle SQL Server and databases separately

SQL Server migration needs its own plan. Copying database files is not the same as a validated database migration.

For SQL Server, check:

SQL item	What to plan
Instances	Default and named instances
Databases	Size, recovery model, owner, compatibility level
Logins	SQL logins and Windows logins
Jobs	SQL Agent jobs, schedules, maintenance
Backups	Full, differential, log backups where needed
Connection strings	Apps may point to old server name or IP
Firewall	SQL ports and app connectivity
Permissions	Database users and roles
Collation	Compatibility with the application
Restore test	Confirm app works after database restore

Microsoft documents SQL Server database copy by backup and restore, and SQL Server backup/restore planning includes strategy and security considerations. For small businesses, backup/restore is often the cleanest migration method because it creates a repeatable test before production cutover.

If the app depends on SQL Server, test the app against the restored database on the new server before scheduling cutover.

Phase 10: plan Active Directory carefully

Active Directory migration is not a casual copy operation. If the old server is a domain controller, DNS server, or FSMO role holder, migration must be planned carefully.

Check:

AD item	What to verify
Domain controllers	Which servers hold AD DS
DNS	Which DNS zones and clients point to the server
DHCP	Whether DHCP runs on the old server
FSMO roles	Which server holds each role
GPOs	Logon scripts, mapped drives, security policies
Users/groups	Active, disabled, stale, service accounts
Replication	Health of domain replication
Time sync	Domain time source
Certificates	AD CS or internal cert dependencies
Decommission	Old DC removal plan after migration

Microsoft provides documentation for transferring FSMO roles in Active Directory Domain Services. If AD is involved, keep this article as a checklist and use a dedicated AD migration plan for the technical work.

For many small businesses, AD migration is the point where it is worth talking to an engineer instead of improvising.

Review Active Directory, file shares, SQL Server, RDS, and app dependencies before cutting over your Windows Server migration.

Talk to Windows Engineer

Phase 11: test with real users

A migration is not validated until real users can complete real work.

Test:

Test area	Example
Login	Users can sign in with correct permissions
Remote access	RDP/RDS/RD Gateway works from expected locations
Files	Users can open, edit, save, and find shared folders
Apps	Business software launches and completes normal workflow
Database	App connects to SQL or local database correctly
Reports	Reports generate and export correctly
Printing	Printers, labels, PDFs, and forms work
Scanning	Scanner or document workflow is usable
Scheduled tasks	Reports, backups, and sync jobs run
Backups	Destination backups complete successfully
Restore	At least one restore test succeeds

Do not let only the technical admin test the new server. Include the person who uses the accounting app, the person who prints labels, the person who runs reports, and the person who needs remote access.

Phase 12: plan the cutover window

A cutover should have a written sequence.

Example cutover plan:

Announce downtime window.
Confirm latest source backup.
Freeze writes on the old server.
Stop relevant services or app access.
Run final file/database sync.
Restore or attach final database on destination.
Update DNS, mapped drives, shortcuts, or connection strings.
Start destination services.
Test admin login.
Test user login.
Test files, apps, reports, printing, and backups.
Confirm users can work.
Keep old server online but read-only or isolated.
Monitor logs and user reports after launch.

The cutover should be boring. If it feels exciting, too much was left unknown.

Phase 13: keep rollback available

Rollback is not failure. It is risk management.

Before cutover, define:

Rollback item	Question
Trigger	What problem requires rollback?
Owner	Who decides rollback?
Time limit	How long before rollback becomes harder?
Data state	How will writes on the new server be handled?
Old server	Is it still intact and accessible?
DNS/access	How do users return to the old path?
Communication	Who tells users what to do?

Keep the old environment available until the new one is proven. Do not wipe or repurpose the old server immediately after first login works.

Phase 14: monitor after migration

The first week after migration matters.

Monitor:

Signal	Why
CPU	Detect undersizing or app spikes
RAM	Identify RDS/user/app pressure
Disk free space	Prevent file, profile, and backup failures
Backup success	Confirm new protection is working
Failed logins	Detect remote access issues or attacks
Event logs	Catch services, drivers, app errors
User complaints	Slow workflows reveal real bottlenecks
Scheduled tasks	Ensure reports and sync jobs still run
SQL jobs	Confirm maintenance and backups run
RDP/RDS sessions	Understand peak concurrent usage

Migration is not done when the old server is shut down. It is done when the new server is stable, backed up, documented, and users can work normally.

Checklist by workload type

Different server roles need different migration attention.

Workload	Migration focus
File server	Shares, NTFS permissions, mapped drives, backup, cutover
RDP/RDS server	User sessions, RDS CALs, profiles, RD Gateway, performance
SQL Server	Backup/restore, logins, jobs, connection strings, restore test
Active Directory	DC health, DNS, FSMO, GPOs, replication, decommission
IIS/.NET	Sites, app pools, certificates, bindings, configs, databases
Accounting software	Vendor support, data path, printers, backups, user testing
Access/legacy apps	Split design, file paths, RDP/RDS testing, backups
Tax software	Seasonal users, client files, vendor support, backups
ERP/inventory	Database, reports, integrations, devices, warehouse workflows

This is why one generic migration plan is not enough. Use the checklist as the control layer, then use workload-specific guides for detailed execution.

How Raff fits Windows Server migration

Raff fits Windows Server migration when a small business wants to move from an aging office server, unsupported Windows Server version, branch server, or local business software environment to a cloud-hosted Windows Server VM.

Raff Windows VMs can serve as the destination for Remote Desktop environments, business apps, cloud file servers, SQL Server tools, Access and legacy apps, tax software, ERP/inventory workloads, and MSP-managed client environments.

Raff is not a replacement for application vendor support, licensing review, or workload-specific testing. The clean model is: use Raff for the Windows VM infrastructure, then migrate with a clear plan for apps, users, files, databases, backups, access, and cutover.

Protect your Windows Server migration with backup, snapshot, and restore planning before moving production workloads.

Explore Data Protection

Final pre-cutover checklist

Before production cutover, confirm:

Check	Done
Source backup completed	☐
Source restore test completed	☐
Destination Windows VM built and patched	☐
Destination backups enabled	☐
Users and admins documented	☐
Apps installed and tested	☐
File shares copied and permissions verified	☐
SQL databases restored and app-tested	☐
RDS/RD Gateway/RDP access tested	☐
RDS CAL requirements reviewed	☐
Printers/scanners/reports tested	☐
DNS/mapped drives/connection strings planned	☐
Cutover window approved	☐
Rollback plan written	☐
Old server preserved after cutover	☐
Post-migration monitoring assigned	☐

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

If any line is unclear, pause before moving production users.

What's next

Review Raff’s Windows Server migration service if you want migration help.
Read How to Migrate Windows Server 2016 to 2025 if your source server is still Windows Server 2016.
Read Cloud Windows Server vs Local Office Server if you are deciding whether to keep local hardware.
Read Windows VPS sizing for remote users before choosing CPU, RAM, and storage.
Read Windows VPS Backup Strategy for Small Businesses before migrating production data.
Read Remote Desktop Gateway vs Direct RDP before exposing remote access.
Read Windows VPS as a Cloud File Server if file shares are part of the migration.
Review Raff Windows VM and pricing when planning the destination server.

Sources

Microsoft Learn — Plan Your Windows Server Upgrade Path
Microsoft Learn — Upgrade and migrate roles and features in Windows Server
Microsoft Support — Support for Windows Server 2016 will end in January 2027
Microsoft Learn — Storage Migration Service overview
Microsoft Learn — Migrate a file server by using Storage Migration Service
Microsoft Learn — License Remote Desktop Services with Client Access Licenses
Microsoft Learn — Back up and restore of SQL Server databases
Microsoft Learn — Copy databases with backup and restore
Microsoft Learn — Transfer FSMO roles in Active Directory Domain Services
Microsoft Learn — Backup and Storage overview for Windows Server
Raff — Windows Server migration service
Raff — Windows VM product page
Raff — Pricing

Windows Server Migration Checklist for Small Businesses