Can I migrate a local office server to a cloud Windows VPS?

Yes. A local office server can be migrated to a cloud Windows VPS when files, apps, users, databases, remote access, backups, licensing, and rollback are planned and tested before production cutover.

Is side-by-side migration better than in-place upgrade?

For local server to cloud migration, side-by-side migration is usually cleaner. The old server stays available while the new Windows VPS is built, tested, and prepared for user cutover.

What should I back up before moving an office server to cloud?

Back up the full server, files, databases, system state where needed, application data, certificates, scheduled tasks, configs, and vendor-specific data. Restore testing is as important as backup completion.

Can a Windows VPS replace a local file server?

Yes. A Windows VPS can replace a local file server when shared folders, SMB access, NTFS permissions, mapped drives, backups, and user access are planned carefully. Direct SMB exposure to the public internet should be avoided.

Do remote users need RDS CALs after migration?

If staff use Remote Desktop Services sessions on Windows Server, RDS CAL planning is usually required. One or two admin RDP sessions are different from daily staff desktop access.

When should I avoid moving a local server to cloud?

Avoid or delay migration when the application vendor does not support cloud/RDS use, local devices are critical and untested, internet is unreliable, backups are unproven, or high availability is required but not designed.

Server Migration to Cloud: Windows Server Guide (2026)

Move a local Windows Server to the cloud with a staged migration plan for apps, files, SQL Server, AD, RDS, licensing, backups, cutover, rollback, and validation.

In short

A server migration to cloud project should move the business workload, not just the files on a physical server. For a local Windows Server, that means inventorying roles, applications, databases, users, file shares, licences, certificates, scheduled tasks, devices, and remote-access requirements before production data moves.

For many small-business migrations, Raff Technologies recommends a side-by-side approach: keep the local server available, build the cloud Windows Server separately, test real workflows, complete a final synchronization, cut users over, and retain a controlled rollback path until the new environment is proven.

This guide is specifically for moving a local or office Windows Server to a cloud Windows VM. For a broader migration control list that also applies to cloud-to-cloud and version-to-version projects, use Server Migration Checklist for Windows Server. If you are still deciding whether the server should leave the office at all, start with Cloud Windows Server for Small Business.

Should you migrate a local Windows Server to the cloud?

A cloud migration is a strong candidate when the existing office server is aging, remote users depend on it, several locations need the same Windows workload, or hardware replacement is approaching.

Comparison visual showing local office server model versus cloud Windows VPS model for users, apps, files, and backups

Situation	Cloud migration fit	What to verify first
Office server is aging or out of warranty	Strong candidate	Application compatibility, storage, backup, target Windows version
Remote users depend on business software	Strong candidate	RDS model, licensing, latency, printers, user profiles
Several offices need one shared Windows system	Strong candidate	Internet continuity, access design, application behavior
Server hosts file shares	Good candidate	Permissions, mapped paths, file size, open files, access method
Server hosts SQL Server	Good candidate after database planning	SQL version, logins, jobs, backups, I/O, connection strings
Server is a domain controller	Requires role-specific planning	AD replication, DNS, FSMO, time, demotion path
Workload depends on USB, serial, scanning, or industrial hardware	Test carefully	Redirection, vendor support, local dependency
Users work only on one fast LAN	Depends	Whether cloud solves a real operational problem
User internet connectivity is unreliable	Risky without mitigation	Secondary connectivity or hybrid/local design
Workload requires high availability	Architecture project	Do not treat one cloud VM as the whole HA design

Cloud infrastructure removes the need to own the physical server, but it does not remove responsibility for Windows, applications, users, security, backups, or licensing.

Review your current Windows Server roles, applications, users, storage, RDS model, licensing, and recovery requirements before choosing the cloud destination.

Talk to Windows Engineer

What actually moves in an office-server migration

A long-running office server usually contains more dependencies than its administrator remembers. Treat discovery as a technical deliverable.

Migration area	Examples
Server roles	AD DS, DNS, DHCP, file services, IIS, RDS, print services
Applications	Accounting, tax, ERP, inventory, Access, custom Windows software
Databases	SQL Server, vendor databases, Access back ends
Users and identities	Administrators, staff accounts, groups, service accounts
File shares	SMB shares, NTFS permissions, mapped drives, ownership
Remote access	Admin RDP, RDS Session Host, RD Gateway, VPN/private access
Scheduled work	Tasks, exports, scripts, maintenance jobs, integrations
Certificates	IIS, RD Gateway, application TLS certificates
Network dependencies	DNS names, IPs, firewall rules, SMTP, APIs, UNC paths
Devices	Printers, scanners, label printers, USB/serial devices
Recovery	Server backup, file backup, database backup, restore procedures

If the server has been in service for years, assume hidden dependencies exist until the inventory proves otherwise.

Side-by-side migration keeps testing and rollback separate from production

Microsoft distinguishes migration, where roles and features move to another server, from in-place upgrade, where a newer Windows Server version is installed over the existing system. Microsoft's current role matrix also makes clear that some Windows Server roles support migration differently from in-place upgrade.

For many local-to-cloud SMB projects, Raff uses side-by-side migration as the default planning pattern because it lets the destination be validated before the source is retired.

Architecture visual showing side-by-side migration from a local office server to a cloud Windows VPS

Text

Local Windows Server stays available
-> Cloud Windows Server is built separately
-> Roles, apps and data are migrated or rebuilt
-> Users test the new environment
-> Final synchronization is completed
-> Production access switches to the cloud server
-> Old server remains controlled for rollback
-> Source is retired only after validation

Side-by-side is not automatically correct for every role. Use Microsoft or vendor-specific migration procedures for Active Directory, SQL Server, RDS, IIS, file services, and third-party business applications.

Phase 1: inventory the local Windows Server

Document the current system before changing it.

Area	Capture
Server identity	Hostname, Windows Server version/build, edition, IPs, domain/workgroup
Installed roles	AD DS, DNS, DHCP, RDS, IIS, file services, print services
Applications	Product, version, installer, vendor, support status, licence model
Users	Administrators, employees, groups, service accounts
Files	Shares, ACLs, mapped paths, capacity, growth, open-file behavior
SQL Server	Instances, databases, recovery models, logins, jobs, linked servers
Tasks and services	Scheduled Tasks, Windows services, scripts, exports, sync jobs
Certificates	Purpose, subject, expiry, private-key availability
Network	Listening ports, firewall rules, DNS records, NAT/VPN dependencies
Devices	Printers, scanners, dongles, serial devices, label hardware
Backups	Tool, schedule, retention, destination, encryption, last restore test

Useful inventory commands can 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 remove accounts, services, folders, or applications during discovery. Record first, then classify.

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

Use four buckets:

Decision	Meaning
Migrate	Still required and has a supported move path
Rebuild	Still required, but should be installed/configured cleanly
Replace	Better handled by another product, SaaS service, or architecture
Retire	No longer required and should not move

A cloud migration is an opportunity to stop carrying abandoned installers, stale users, obsolete shares, and unsupported applications into the next server.

Examples:

Active company files: migrate.
Current business application: rebuild or migrate according to vendor guidance.
SQL Server database: migrate with a database-specific plan.
Old employee accounts: disable or exclude after ownership review.
Unsupported legacy utility: replace or isolate.
Old local backup archives: retain according to policy, but do not confuse them with the new recovery design.

Phase 3: choose the destination Windows Server version and licensing model

Windows Server 2025 is Microsoft's current LTSC release, but that does not mean every application should move to it immediately. Choose the destination OS from the application and role support matrix.

For each workload, verify:

Which Windows Server versions the vendor supports.
Whether RDS or multi-user use is supported.
Whether SQL Server or another database has its own version requirements.
Whether drivers, printers, scanners, or legacy components support the target OS.
Whether the chosen server roles have a supported migration path.

Use Windows Server Version Comparison for the OS decision.

For Raff, production Windows Server licensing generally follows one of two paths:

Raff-provided SPLA licensing; or
eligible customer BYOL under the customer's applicable Microsoft agreement and outsourcing rights.

Do not plan a production migration around a Windows Server Evaluation image. Use Windows Server Licensing on Raff for the current SPLA, BYOL, CAL, and RDS licensing model.

Phase 4: size the cloud Windows Server from real workload data

Do not copy the physical server's CPU and RAM numbers blindly, and do not choose a VM solely from employee count.

Collect or estimate:

peak concurrent users;
CPU use during important workflows;
available and committed memory;
current disk use and growth;
database size and growth;
backup size and retention;
active RDP/RDS sessions;
user-profile growth;
busiest reporting or month-end periods;
application-specific I/O requirements.

For remote desktop workloads, use Windows VPS Sizing for Remote Users, which maps workload targets to current Raff VM tiers. This avoids treating theoretical configurations as live SKUs.

Use Raff Pricing only after CPU, memory, storage, licensing, and backup requirements are known.

Compare current Raff Windows VM plans after you have estimated concurrency, CPU, memory, storage, licensing, and recovery needs.

View Pricing

Phase 5: design admin RDP, RDS, and remote access before cutover

Administrative Remote Desktop and daily employee desktop access are different use cases.

Access need	Planning direction
One or two administrators maintain the server	Restricted administrative RDP may be sufficient
Employees need shared desktop sessions	Plan RD Session Host
Employees need published Windows applications	Plan RemoteApp/RDS architecture
Users connect from public networks	Consider RD Gateway or another controlled access layer
Users need several private services	Consider VPN/private networking rather than publishing each service
Users only consume an IIS application	Use HTTPS rather than full desktop access

Microsoft's customer-owned RDS model requires compatible RDS CALs for users or devices connecting to RD Session Host. Raff-hosted SPLA deployments use the applicable service-provider licensing model, including RDS User SALs where RDS is consumed.

Use RDS CAL Licensing Guide and Remote Desktop Gateway vs Direct RDP before production access is opened.

Phase 6: back up the source and prove the restore path

Before migration changes begin, protect the local server.

Verify the layers that match the workload:

Recovery layer	Purpose
Whole-server backup	Recover the original system after a failed change
File backup	Restore shares and business documents independently
SQL/database backup	Recover databases consistently
System State	Support relevant Windows infrastructure recovery scenarios
Application-specific backup	Preserve vendor application data and configuration
Certificate export	Preserve private keys required by IIS, RD Gateway, or apps
Configuration export	Preserve tasks, firewall rules, IIS settings, app configuration
Restore test	Prove that recovery actually works

Do not use “backup completed successfully” as the only recovery test. Restore representative data before the production cutover.

Define two business targets:

RPO: how much recent data can the business afford to lose?
RTO: how long can the workload remain unavailable?

Those targets should drive backup frequency, retention, and cutover planning.

Phase 7: build and harden the cloud destination first

The new server should be production-ready before production data arrives.

Prepare:

supported Windows Server image;
named administrator accounts;
correct Windows licensing path;
Windows updates;
Windows Firewall rules;
Microsoft Defender or the approved endpoint-security configuration;
RDP/RDS/RD Gateway access model;
private networking where required;
storage layout;
backup configuration;
monitoring;
DNS and naming plan;
application prerequisites;
documentation and recovery access.

Use the Windows Server Hardening Checklist before users depend on the destination.

File-server migration: preserve permissions and paths, not only bytes

For a file server, inventory:

share names;
NTFS permissions;
share permissions;
local groups used by ACLs;
mapped-drive letters;
UNC paths embedded in applications;
open files;
quotas;
long paths;
archive data;
backup exclusions and policies.

Microsoft's Storage Migration Service supports Windows Server 2025, 2022, 2019, and 2016 migration scenarios. Its workflow inventories source data, transfers files and configuration, and supports cutover to a Windows Server destination.

It is a file-server migration tool, not a universal migration engine. Microsoft specifically notes that Storage Migration Service does not migrate domain controllers as domain controllers.

File migration visual showing shared folders, NTFS permissions, mapped drives, and final sync moving from local server to Windows VPS

For a file-centric project, use File Server Migration to Windows VPS for the dedicated workflow.

Business-application migration: vendor support is a hard gate

An installer launching on the new Windows Server does not prove that the production architecture is supported.

For each application, verify:

Item	Question
Windows Server support	Does the exact application release support the target OS?
Hosted/virtualized use	Does the vendor support the application on a hosted VM?
RDS support	Can the application run in multiple RDS sessions if required?
Licence transfer	Does activation move to a new server identity?
Data location	Where is the live production data stored?
Database dependency	Which SQL/database version and configuration are required?
Services	Which service accounts and Windows services are required?
Devices	Are printers, scanners, USB, serial, or dongles required?
Integrations	Which APIs, SMTP services, exports, mapped paths, or Office components are used?
Recovery	How is the application restored and validated?

Test real workflows, not only startup. Create or edit a record, generate a report, print or export, close and reopen the application, and verify the backup/restore process.

Use Windows VPS for Business Software for architecture and compatibility planning.

SQL Server migration: move server-level dependencies too

SQL Server migration is not complete when the .mdf file reaches the destination.

Plan:

SQL Server version and edition;
database compatibility;
recovery model;
full/differential/log backups where applicable;
SQL and Windows logins;
login SIDs and orphaned-user handling;
SQL Agent jobs;
linked servers;
credentials and certificates;
Database Mail;
maintenance jobs;
connection strings;
firewall access;
destination backup jobs.

For many SMB workloads, backup and restore provides a repeatable way to test the database on the new server before final cutover. Validate the application against the restored database, not just database connectivity from SSMS.

Use SQL Server Migration to Windows VPS for the database-specific procedure and SQL Server Backup Strategy for recovery planning.

Active Directory migration needs its own DC plan

If the local office server is a domain controller, do not treat it like an ordinary application server or use Storage Migration Service as the DC migration method.

Check:

AD area	Validate
Replication	`repadmin /replsummary` and `repadmin /showrepl` are healthy
DNS	Zones, forwarders, client DNS settings, stale dependencies
FSMO roles	Current role holders are documented
Global Catalog	Correct DCs provide GC where required
GPOs	Drive maps, scripts, security policy, software deployment
DHCP	Scopes, reservations, options, failover, relays
Time	PDC Emulator and upstream time-source design
Applications	LDAP, DNS, hard-coded DC names, service-account dependencies
Decommission	Graceful demotion and post-demotion validation

A common side-by-side AD path is to build a supported new DC, allow replication, validate DNS and directory health, move required roles, update dependencies, and then demote the old DC through Microsoft's supported process.

For AD topology validation, use Active Directory Replication Topology.

Test from the locations and accounts that will actually use the server

Do not let the administrator be the only tester.

Test area	Acceptance example
Office user	Can authenticate and complete normal work
Remote user	Can connect from the real remote location
Admin access	Approved administration path works
RDS	User session opens with intended profile and policy
Files	Open, edit, create, rename, and save with correct permissions
Business app	Representative transaction or workflow succeeds
SQL	Application connects and completes expected operations
Printing	Required printers, PDF output, and labels work
Integrations	Email, exports, APIs, scheduled syncs work
Backup	Destination backup completes
Restore	Representative restore succeeds

Run tests with normal user permissions. Administrator success can hide permission and profile problems that production users will encounter.

Cutover runbook: freeze, synchronize, switch, validate

Write the sequence before the maintenance window.

Notify users and confirm the downtime window.
Confirm current source backup and restore path.
Confirm destination backup and recovery access.
Stop or freeze production writes where necessary.
Stop services that could create conflicting writes.
Run the final file synchronization or database backup/restore.
Update DNS, aliases, mapped drives, shortcuts, or connection strings.
Start required services on the cloud Windows Server.
Validate administrator access.
Validate a representative business user.
Test files, applications, SQL, reports, printing, scheduled work, and backups.
Decide whether to continue or roll back before the agreed decision point.
Keep the old server isolated from conflicting writes while rollback remains available.

Pre-cutover checklist visual for moving a local office server to a cloud Windows VPS

The cutover should be an execution checklist, not the first time the team decides how data will move.

Define rollback before production switches

A rollback plan should specify:

Item	Question
Trigger	Which failures require rollback?
Owner	Who can make the rollback decision?
Deadline	How long can troubleshooting continue before rollback begins?
New writes	What happens to data created after cutover starts?
Source state	Is the old server intact and protected from conflicting writes?
DNS/access	How do users return to the original paths?
Communication	Who tells users and vendors what changed?

Do not erase or repurpose the old server after the first successful login. Retire it only after the destination passes the agreed technical and business validation period.

Monitor the first days after migration

Watch both infrastructure and workflow signals:

CPU and sustained processor pressure;
available memory and paging;
disk free space and storage latency;
active RDP/RDS sessions;
failed logons;
Windows and application event logs;
SQL Agent jobs and database backups;
scheduled tasks and integrations;
backup completion;
user-reported workflow problems.

Use Windows Server Performance Monitoring to establish a repeatable PerfMon baseline instead of diagnosing performance from Task Manager alone.

Migration is complete when the destination is stable, recoverable, documented, and real users can complete the work the server exists to support.

How Raff fits local Windows Server to cloud migration

Raff provides the Windows VM infrastructure layer for businesses and MSPs moving supported Windows workloads away from local hardware.

Typical destination workloads include:

business applications over RDP/RDS;
accounting and tax software;
ERP and inventory systems;
IIS and ASP.NET applications;
SQL Server-backed workloads;
Windows services and scheduled automation;
supported file-server workloads;
domain services where the network and AD architecture have been designed correctly.

Raff Windows VMs provide administrator access, RDP access, NVMe-backed storage, private networking options, and backup/snapshot options. The customer or MSP still owns application compatibility, guest Windows configuration, licensing review, security hardening, backup design, and production migration unless a separate managed service covers those responsibilities.

Build the destination Raff Windows VM before cutover so users, applications, files, networking, backups, and rollback can be tested alongside the local server.

Deploy Windows Now

Final local-server-to-cloud checklist

Resolve unknown items before the production cutover.

Frequently asked questions

What is server migration to cloud?

Server migration to cloud is the process of moving a workload from a physical or locally hosted server to cloud infrastructure. For Windows Server, this can include roles, applications, databases, files, users, permissions, remote access, licensing, backups, and operational procedures.

Should I migrate a local Windows Server in place or side by side?

For many local-to-cloud projects, side-by-side migration is easier to test and roll back because the source can remain available while a separate destination is built. The correct method still depends on the Windows role, application, data, and vendor-supported migration path.

Can Storage Migration Service move my whole Windows Server?

No. Storage Migration Service is primarily for file-server data and configuration migration. Microsoft supports current Windows Server 2025, 2022, 2019, and 2016 scenarios, but it does not migrate a domain controller as a domain controller and it is not a general application or SQL Server migration engine.

Do I need RDS CALs after moving Remote Desktop users to the cloud?

If users consume RD Session Host in a customer-owned Microsoft licensing model, the applicable RDS CAL rules apply. Raff-hosted SPLA deployments use the applicable service-provider licensing model, including RDS User SALs for hosted RDS use. Administrative RDP is a different use case from employee desktop sessions.

Can I move an old Windows Server licence to a cloud VM?

Not automatically. Raff can provide Windows Server under SPLA, while eligible customer BYOL depends on the customer's Microsoft agreement, qualifying rights, and applicable outsourcing rules. Review Windows Server Licensing before production.

How long should I keep the old local server after migration?

Keep it according to the written rollback plan until the cloud destination has passed technical and business validation. Prevent conflicting writes if both environments remain online.

Validation scope

This article was revalidated on September 11, 2026 against current Microsoft guidance for Windows Server upgrade and migration methods, role migration, Storage Migration Service, Windows Server 2025 release status, and Remote Desktop Services licensing.

The existing four in-article migration visuals and the existing featured image were preserved. This refresh does not claim that one migration method fits every Windows role or that every legacy application will work unchanged in a cloud VM.

What's next

Cloud Windows Server for Small Business - decide whether the office workload should move to cloud infrastructure.
Server Migration Checklist for Windows Server - use the broader migration control list.
Windows VPS Sizing for Remote Users - map user and application load to current VM tiers.
Windows Server Licensing - review SPLA, eligible BYOL, CAL, and RDS licensing.
File Server Migration to Windows VPS - handle file shares and permissions.
SQL Server Migration to Windows VPS - plan database migration separately.
Remote Desktop Gateway vs Direct RDP - secure external Remote Desktop access.
Windows Server Hardening Checklist - secure the destination before production.
Raff Windows VM - review the destination platform.
Raff Pricing - confirm current infrastructure pricing.

Sources

Microsoft Learn - Upgrade and migrate roles and features in Windows Server: https://learn.microsoft.com/en-us/windows-server/get-started/upgrade-migrate-roles-features
Microsoft Learn - Use Storage Migration Service to migrate a server: https://learn.microsoft.com/en-us/windows-server/storage/storage-migration-service/migrate-data
Microsoft Learn - Storage Migration Service FAQ: https://learn.microsoft.com/en-us/windows-server/storage/storage-migration-service/faq
Microsoft Learn - Windows Server release information: https://learn.microsoft.com/en-us/windows/release-health/windows-server-release-info
Microsoft Learn - RDS Client Access Licenses: https://learn.microsoft.com/en-us/windows-server/remote/remote-desktop-services/rds-client-access-license
Microsoft Learn - Remote Desktop Gateway: https://learn.microsoft.com/en-us/windows-server/remote/remote-desktop-services/remote-desktop-gateway-role
Sources revalidated: 2026-09-11

Server Migration to Cloud: Local Windows Server Guide (2026)

In short

Should you migrate a local Windows Server to the cloud?

What actually moves in an office-server migration

Side-by-side migration keeps testing and rollback separate from production

Phase 1: inventory the local Windows Server

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

Phase 3: choose the destination Windows Server version and licensing model

Phase 4: size the cloud Windows Server from real workload data

Phase 5: design admin RDP, RDS, and remote access before cutover

Phase 6: back up the source and prove the restore path

Phase 7: build and harden the cloud destination first

File-server migration: preserve permissions and paths, not only bytes

Business-application migration: vendor support is a hard gate

SQL Server migration: move server-level dependencies too

Active Directory migration needs its own DC plan

Test from the locations and accounts that will actually use the server

Cutover runbook: freeze, synchronize, switch, validate

Define rollback before production switches

Monitor the first days after migration

How Raff fits local Windows Server to cloud migration

Final local-server-to-cloud checklist

Frequently asked questions

What is server migration to cloud?

Should I migrate a local Windows Server in place or side by side?

Can Storage Migration Service move my whole Windows Server?

Do I need RDS CALs after moving Remote Desktop users to the cloud?

Can I move an old Windows Server licence to a cloud VM?

How long should I keep the old local server after migration?

Validation scope

What's next

Sources

Frequently asked questions

Your Windows Server, live in ~55 seconds

Related articles