Use this Windows Server migration checklist before a cloud cutover: eight checks, scored per workload from records, with each row marked Tested, Written or Absent. A workload joins the first wave only when every row is Tested.
Last reviewed 2026-11-14 by Manish Sharma.
The checklist suits an IT head or infrastructure lead whose Windows Server hosts and SQL Server instances are due to move, and the CIO who signs off each wave. It scores records the team already holds, or must write. Also, it gives no how-to steps, no prices and no license terms. For the dates that drive the timing, read when each Windows Server release leaves support.
What Each Mark Means on a Windows Server Migration Checklist
Each mark answers one question: has the record met the target build? Tested scores 2. The record exists, and its own test has run against the current target build, with a result someone other than its author can read. Written scores 1. The record exists, but nobody has run its test on the current build, and a new build resets a Tested row to Written. Absent scores 0. There is no record, or only a verbal answer.
A new build resets a Tested row to Written, until someone runs its test on that build.
When a check does not apply to a workload, it gets a line through it, with the reason written beside it. A host with no SQL Server instance, for example, strikes the SQL Server rows. That workload’s maximum then falls by 2 for each struck check. Otherwise, each workload scores out of 16. No pass mark exists, because the waves later in this guide read the rows, not the sum.
Which Rows the Tester Opens in Full
To begin with, every server and instance goes on the sheet. Our suggestion is that the tester runs each test in full on every workload the business names as critical, and on every fourth row of the list, counting from a row the CIO picks. Then the tester reads the remaining rows for the record only. A record gets tested by someone other than its author.
Have someone other than the author run each test, and keep the result where the CIO can read it.
Windows Server Migration Checklist Before the Build: Checks 1 to 4
Checks 1 to 4 cover what you run, how long it stays supported, whether your applications work on the target, and who signs in. These checks come before any build starts.
| Check | What to hold | How the tester tests it | Tested means |
|---|---|---|---|
| 1. Register | One list of servers and SQL Server instances, with OS version, edition, server roles and a named owner. | The tester compares the list with a fresh discovery export. | Every live host in the export sits on the list. |
| 2. Support dates | Each version’s support end date, the Microsoft Lifecycle page it came from and the date someone read it. | The tester opens two lifecycle pages. | The dates on both pages match the register. |
| 3. Application test | A test report for each application, naming the Windows Server and SQL Server build it ran on. | The tester matches the report’s build to the target build record. | The two builds are the same. |
| 4. Account register | A list of service accounts, managed service accounts and SQL Server logins, each with the workload that uses it. | The tester picks two entries and looks for their sign-in log lines on a target server. | Both entries show a sign-in on the target. |
Servers, Instances and Their Support Dates
Check 1 asks for one register with a named owner for every row, so nobody has to guess who answers for a host. Also, check 2 pairs each version with its support end date, the Microsoft page that gave it and the day someone read that page. On 14 November 2026, the Windows Server 2016 page on Microsoft Lifecycle listed 13 January 2027 as the end of extended support.
Applications and Accounts on the Target Version
Check 3 wants a report per application that names the builds it ran on. This Windows Server migration checklist also asks the report to say whether the server moves as it is or on a newer version, though the decision itself belongs elsewhere. Check 4 tracks who can sign in to what; for the idea behind it, see who can sign in to what and with which account. Finally, the sign-in lines show that the accounts work where the workload will live.
Key Takeaway Each of checks 1 to 4 is tested against the current target build, not against the old server.
Windows Server Migration Checklist Before the Switch: Checks 5 to 8 and SQL Server Rows
Checks 5 to 8 cover licensing paperwork, restores, the way back and updates. This section of the list also repeats rows for each SQL Server instance.
| Check | What to hold | How the tester tests it | Tested means |
|---|---|---|---|
| 5. License note | One dated note per server, signed by the holder of the agreements, saying how the licenses are covered in the cloud. | The tester finds the signer in the contract records as the agreement holder, and counts a note for every server in check 1. | The signer matches, and no server lacks a note. Either miss fails. |
| 6. Restore record | A log of a restore of each database and server image in scope, done on the cloud platform, with start and end times and who checked the data. | The tester reads the backup file date. | The backup file is newer than the current target build. |
| 7. Fallback record | The condition that sends users back to the source, the person who decides, and the log of one practice run. | The tester reads the practice log. | The log has an end time and a line showing users reached the source. |
| 8. Patch plan | An entry for each target server with its update group, maintenance window and accountable person. | The tester finds the server in that update group on the target. | The server is listed in the group. |
License Note and Restore Record
Check 5 is one row with no terms and no figures: only who signed, and for which servers. Check 6 shows that a restore works on the platform you move to, instead of on the old one.
Fallback Record and Patch Plan
Check 7 needs the practice run to finish, and then show that people reached the source. For how to set up the way back, read the nine-step order for moving SQL Server and its hosts. Finally, check 8 names who owns updates once the server lives on the target.
SQL Server Migration Checklist Rows for Each Instance
A SQL Server migration checklist row carries the register, support, application, account, restore, fallback and patch rows for every instance. Its evidence names the instance, its version and edition, its logins and a restored database. However, other database engines have their own list.
Windows Server Migration Checklist Totals by Workload, and the Move Waves
Add the marks for each workload, and then place the workload by its weakest row. A workload joins the first wave only when every row is Tested. A Written row gets a dated test slot, and the workload moves in a later wave. An Absent row keeps the workload on the source until the record exists. Finally, the CIO signs off each wave from the sheet. This is our suggestion, not a standard.
Key Takeaway The weakest row places a workload, not the sum of its marks.
A Worked Row on the Windows Server Migration Checklist
However, this is an illustration, not client data. Take check 3 for one application. Its test report names a Windows Server 2022 build, while the target record shows a newer build. The row scores Written, because the test has not run on the current build. The workload waits for a later wave until someone reruns the test.
Beyond the Score: Cloud Choice, Move Plan and Server Age
This Windows Server migration checklist shows that records exist and have met the target. It does not choose a cloud; for that, see how the two clouds compare for Windows servers and databases. It does not set the sequence of the move, and it does not score server age or hardware. For that, see scoring the servers themselves before a platform is picked. Checks that apply to any legacy move live in application checks that apply to any legacy move. If some servers stay on site, planning the replacement of servers that stay on site covers them, and an estate split between the office and a cloud names that setup.
Bring in help if no one will author a record, when restores keep failing, or when a workload sits on the source for two waves. Help moving Windows and SQL Server workloads describes that work.
Signisys offers it through our cloud migration practice for AWS and Azure and cloud platform engineering and support. A consultation reads your sheet against your own records and makes no promise on results. No charge, with a fixed scope.
Windows Server Migration Checklist FAQ
Do file and print servers belong on the sheet?
What counts as a test record when an application’s maker runs the target test?
Does a server moving to a cloud virtual machine on the same version still need check 3?
Who holds the sheet once the last wave has moved?
Security Insights, Delivered.
Practical, vendor-neutral analysis of threats, tools, and architecture decisions.