Checklist: migrate Windows servers to the cloud

Who this is for

This guide, Checklist: migrate Windows servers to the cloud, is for the person who owns the Windows environment at a small or mid-sized company. You may have five servers or fifty. They run IIS, a .NET line of business app, a license server, a print server, or a set of Windows services that talk to each other over TCP. The move is not a backup restore. It is a change of host, network, identity, and often licensing at the same time.

This checklist stays away from file servers, Active Directory, SQL Server, and plain VMware lifts, because other guides cover those. The focus here is the application server: the box with services, registry settings, certificates, COM components, and integrations that no one has touched in years. Those are the servers that cause cutover surprises.

You do not need a large team. You need one owner, a maintenance window, a test target, and a rollback that you have tried. If you cannot name the business owner of a server, stop and find that person before you copy anything.

Before you begin

Start with a register, not a console. For each server, record the host name, OS version, patch level, role, business owner, users, dependencies, and acceptable downtime. Add the reason the server exists. 'Unknown' is a valid entry and a reason to investigate, not a reason to guess.

Take a full backup and prove you can restore it. Export the things that live outside the file system: IIS configuration from applicationHost.config, certificates with private keys from the Certificates MMC snap-in, registry keys under HKLM and HKCU that hold app settings, scheduled tasks as XML, and service account details into your password vault. Keep the old server running until the new one passes tests.

Decide the target for each server: a cloud VM that mirrors the current build, a managed service that replaces a role, or a rebuild on a newer Windows Server version. Rehosting is the fastest path, but it carries old settings forward. A rebuild takes longer and gives you a cleaner baseline. Pick per server, not for the whole batch.

Check licensing early. Windows Server licensing, per core rules, Software Assurance, and third party app licenses can change the design. Ask your Microsoft reseller and the app vendor for written confirmation of what the cloud VM needs. Do this before you build, not after.

The checklist

Run the checklist per server and keep evidence for each item: a screenshot, a command output, a test result, or a signed note. The order matters. Inventory first, build second, test third, cut over last. Expect to loop back when a test exposes a dependency you missed.

A server with a low risk profile and a clear owner is a good first candidate. Leave domain controllers, mail servers, and anything with a hardware dongle for later. Do not migrate a server just because it is old. Migrate it because you understand it and have a target that works.

Use the same OS version and patch level on the target as the source unless you have planned an upgrade. Small differences in .NET versions, Visual C++ runtimes, or TLS settings can break an app that worked fine on the old host. Patch the target, then test again.

• Record each server's role, business owner, users, dependencies, and acceptable downtime in one shared register.
• List installed roles and features with Get-WindowsFeature and confirm the target image includes every one the app needs.
• Export every Windows service and its logon account, then mark which services start automatically and which can stay manual.
• Map inbound and outbound connections with TCPView or Get-NetTCPConnection, and allow only the required ports in the cloud firewall.
• Copy IIS sites, bindings, application pools, and certificates to the target, then test each site over HTTPS.
• Check COM+ applications and DCOM permissions under Component Services, because a new machine name or IP can break them.
• Search the registry, web.config, machine.config, and app config files for hard coded host names, IP addresses, drive letters, and UNC paths.
• Confirm Windows Server licensing, per core requirements, and third party app licenses before you build the target VM.
• Create a test target in an isolated network, restore the app and data, and run the business owner's acceptance tests.
• Test service accounts, Kerberos, TLS certificates, and any integration that uses a host name or IP address.
• Write a cutover runbook with exact steps, owners, timings, DNS changes, and a rollback that does not depend on the new environment.
• After cutover, watch Event Viewer, Performance Monitor, backup jobs, patch status, and monitoring alerts for several days.
• Keep the old server powered off but intact for an agreed period, then decommission it and remove its DNS records.

What good looks like

A good migration has no mystery servers. Every server in the new environment has an owner, a documented build, a backup schedule, a patch schedule, and a monitoring check that fires when the service stops. You can rebuild it from your notes without guessing.

The acceptance test is simple: users sign in, the app does its main job, integrations pass, and the business owner signs off. Backup restore is tested, not assumed. Alerts reach the on call person. The old server stays off but available until the agreed rollback window closes.

Cost and operations stay visible. Tag each resource with owner, application, and environment so finance can map spend back to a service. Review the first invoice against the design, because idle disks, public IPs, and oversized VMs are easy to leave behind after a lift. Then remove the old host, its DNS records, and its backup jobs.

What to do next

Pick one low risk Windows server and run this checklist end to end. That gives you a template, a test plan, and a realistic cutover window. Then group the remaining servers into waves by dependency and business owner, not by alphabetical order.

For each wave, set a go or no go meeting, name the rollback trigger, and keep the old environment until the new one has run through a full backup and patch cycle. If a server needs a rebuild or a version upgrade, schedule that as a separate project. Do not mix it into a weekend cutover.

If you want a structured start, the Discovery and roadmap sprint from Cloudverg is a two-week fixed-price engagement at $9,500. It ends with a target architecture, a phased roadmap, and a fixed price quote for phase one. It is one option among others, and it fits best when the server list is messy and the dependencies are unclear.

Frequently asked questions