Server Migration Checklist Template

Record which server is moving, why, where to and how, and who does each step. Enter the planned cutover date on the first task: every task before it counts back from that date in business days and every task after it counts forward, so changing the date moves the whole plan.

• Record the server, why it is moving, where to, how, and who is involved — the source server’s name and what it does, the reason for the move, the target platform, the migration method, the planned cutover date, and the migration lead, migration engineer and service owner
• Agree what moves, what stays and what is retired — each workload on the server and where it goes (to the target, to another server or service, or switched off), anything out of scope, and the business reason for the move, agreed with the service owner
• End of support: record when the operating system stops getting security updates — the operating system and version on the source, the date its vendor stops security updates, taken from the vendor’s own lifecycle page, and any paid extended support that covers the server until the cutover
• Choose the cutover window with the service owner — a date and time when the service can be out of use for the cutover and a possible rollback, the longest outage the service can take, and dates to avoid, such as month-end, payroll or a busy season
• Get admin access, migration accounts and support contacts — administrator access to the source and the target for named accounts rather than a shared login, the accounts any migration tool needs, and support contacts for the hardware, the hosting provider and each application’s vendor

Find out everything the server does before anything moves. The things that break after a cutover can be the ones nobody listed: a scheduled job, a script with the old IP address in it, a certificate, a partner’s file transfer. The roles you tick on the first task of this phase add the tasks they need.

• List the roles, features and applications on the server — every role and feature installed and every application with its version, vendor and owner, read from the server itself rather than from old documentation
• Record the services, scheduled tasks and jobs that run on it — every service set to start automatically, every scheduled task, cron job or script, when each one runs and which account it runs as, so nothing silently stops after the move
• List the file shares and local data, with their size and owners — each share or folder with its path, size, permissions and owner, plus data kept outside the shares that something reads, such as application folders, exports and logs
• Record the service accounts, local accounts and certificates — the service accounts the server’s services and jobs run as, any local users and groups, and every certificate installed, with its expiry date and what uses it
• Record the server’s names, IP addresses, DNS records and firewall rules — the host name, every IP address, the DNS records and aliases that point at the server, the ports it listens on, and the firewall rules on the server and on the network that allow traffic to and from it
• Find every system and person that connects to it, and everything it connects to — inbound connections from users, other servers, devices and partners, and outbound connections to databases, mail relays, licence servers and other services, found from connection logs or monitoring and not only from documentation, including scripts, mapped drives and application settings that name the server or its IP address
• Check each application is supported on the target — for each application, whether its vendor supports the version you will run on the target operating system, and on virtual or hosted infrastructure if that is the target, and whether an upgrade or a new licence is needed

Measure how the server behaves today, agree how success will be tested, and write down how the cutover and the rollback will run. The service owner writes the acceptance tests now, so the sign-off after the cutover checks what matters to them.

• Record a performance baseline and size the target from it — CPU, memory, disk space, disk activity and network use over a normal period that includes the busiest times, and the target’s CPU, memory and storage with room for growth
• Write the acceptance tests with the service owner — the checks the service owner will run after the cutover to show the service works, such as signing in, the main transactions, reports, printing, integrations and anything that runs overnight, each with its expected result
• Take a full backup of the source and prove it restores — a full backup taken before any change and a test restore of a sample of files, or of the whole server to an isolated place, so there is a known good copy to fall back on
• Agree what to do about each unsupported application — for each application without vendor support on the target, a decision with the service owner: upgrade it to a supported version, replace it, keep it on a separate supported server, or accept the risk in writing
• Consolidation: check the workloads can share the target — the combined load of every workload moving onto the target, clashing ports, share names or host names, conflicting versions of runtimes or components, different maintenance windows, and workloads with different security needs that should stay apart
• Databases: plan the database move with its own checklist — each database on the server with its engine and version, moved with the Database Migration Checklist so the schema, the sync and the validation get their own steps, and how the database cutover fits this server’s window
• Decide how users and systems will find the new server — whether the target takes over the old server’s name and IP address, keeps the name with a new address, or gets a new name with DNS records, aliases, scripts and settings updated
• Write the cutover runbook and the rollback plan — each cutover step with its time and who does it, the freeze, the final sync, the switch, the smoke tests, the time by which you decide to keep the new server or roll back, and the exact steps to switch users back to the source
• Raise the change request for the cutover — a change request in your change process with the runbook, the rollback plan, the acceptance tests and the window, sent to whoever approves changes in good time before the go/no-go

Prepare the server the workloads will run on: built to your own standard, licensed, monitored and reachable before any data arrives. The method, the target platform and the roles you ticked add their own tasks.

• Build the target server to your standard — the operating system version you chose, installed and patched, hardened to your baseline and joined to the domain where needed, with a temporary name and address if it will take over the old server’s later
• Hosted VM: agree the size, region, network and what the provider manages — the virtual machine’s size and storage, the region or data centre, how it connects to your network and users, who patches and backs it up, and the provider’s support terms
• Replication: prepare the target platform and the replication tool — the target host or cloud account, the network the copy will run on, the replication tool’s requirements and agent, and an account with the access it needs
• Install the applications on the target and recreate their jobs, accounts and certificates — each application from the Phase 2 list, installed at a version its vendor supports on the target and configured from the source’s settings, then every service, scheduled task and job set to run as the right account and every certificate imported, with jobs left disabled until the cutover if they must not run twice
• Domain controller: promote a new domain controller instead of moving this one — a new server promoted to a domain controller in the existing domain as its own change, the FSMO roles moved to it after checking which server holds them, and the old domain controller’s demotion planned before it is retired
• License and activate the operating system and applications on the target — a licence for the target’s operating system, activated, and each application licence moved or reissued where it is tied to the old server’s name, hardware or address
• Add the target to monitoring, backup, patching and security tools — monitoring and alerts, backup jobs, patching, endpoint protection and log collection set up for the target, ready to switch on fully at the cutover
• Open the network and firewall access the target needs — the ports and rules from the Phase 2 record opened for the target on the server and on the network, including any access for partners or remote sites, tested from where the users and systems connect

Copy the data while the source keeps running, then practise the cutover so the real one has no surprises. The service owner runs the acceptance tests on the target before the go/no-go.

• Copy the data to the target and check the permissions — an initial copy of the shares and application data with a tool that keeps permissions, owners and timestamps, then repeat copies that pick up the changes, with the errors in each copy log fixed or explained
• Storage Migration Service: inventory the source and transfer the data — an orchestrator and the Storage Migration Service tool set up in Windows Admin Center, an inventory of the source, then a transfer to the target with the error log checked
• Replication: replicate the server and test-launch a copy in an isolated network — the source replicating until the initial copy is complete, then a test launch of the copy in a network that cannot reach production, checked by the engineer before the real cutover
• Rehearse the cutover and time each step — a practice run of the runbook against the target or a test copy, with the time each step took, so you know the final sync and the switch fit inside the window
• Run the acceptance tests on the target before the cutover — the service owner’s tests run against the target with test or copied data, with any failures fixed and the tests run again before the go/no-go
• Tell users and the service desk about the cutover window — the date and time of the outage, what users must do beforehand, what will change for them and how to report problems, with the service desk briefed on the runbook and the rollback plan

Confirm the change is approved, get the service owner’s go, then move. The go/no-go is the gate: nothing after it can be completed until the service owner records a decision. On the cutover date, freeze the source, run the final sync, switch over and test.

• Confirm the change is approved and get the switch ready — the change approved in your change process with any conditions met, the people in the runbook and the vendors’ support available for the window, and the TTL lowered on any DNS record that will change
• Go/no-go: the service owner approves the cutover — the service owner’s decision to go ahead in the approved window, based on the rehearsal, the acceptance tests on the target, a tested backup and the rollback plan; a no-go adds a task to record why and set a new date
• No-go: record why and set a new date or stop the migration — what was not ready and the work needed, then either a new planned cutover date on the first task, which moves every due date, or a decision to stop with the remaining tasks marked not applicable
• Freeze changes and stop the services on the source — a message that the outage has started, users signed out, the applications and services on the source stopped and, for file shares, the shares set to read-only so nothing changes during the final sync
• Run the final sync and check it finished without errors — the last copy, replication or transfer of the changes since the previous one, with its log checked and the totals compared with the source before anyone is switched over
• DHCP: move the scopes, reservations and options, and stop the old service — the scopes, reservations, options and leases moved to the target, the old DHCP service stopped so two servers never hand out the same addresses, and DHCP relays pointed at the new server
• Print server: move the printers, drivers and queues — printers, drivers, ports and queue settings moved to the target, with Printbrm on Windows Server or your print server’s own tools, and users’ printer connections pointed at the new server
• Switch names, addresses and DNS to the new server — the old server renamed or taken off the network and the target given its name and address, or the DNS records and aliases updated, as decided in Phase 3, with scripts, mapped drives and settings that name the old server changed
• Start the services on the target and run the smoke tests — services and scheduled jobs enabled, a quick test of each main function by the engineer, and a decision by the rollback time in the runbook to keep the new server or roll back

Prove the service works on the new server and get the service owner’s acceptance. A failed cutover adds the rollback task here, and a sign-off that is not accepted adds a task to fix the failures or roll back.

• Roll back: switch users back to the source and record what failed — the runbook’s rollback steps: the target taken out of service, the old server’s name, address and services restored, users told, and what failed recorded
• Replication: remove the agent and old drivers from the migrated server — the replication agent removed or the replication stopped as the tool’s guide says, and drivers, tools and agents for the old hardware or hypervisor removed so they do not run or alert on the new platform
• Check every dependency connects to the new server — each system and user on the Phase 2 dependency list checked against the new server now, with jobs that run only weekly or at month-end listed and checked when they first run during hypercare, and anything still pointing at the old name or address fixed
• Service owner runs the acceptance tests and signs off — the acceptance tests from Phase 3 run on the live service, with the results recorded and the service owner’s decision: accepted, accepted with follow-ups, or not accepted
• Not accepted: fix the failures or roll back — each failed test fixed and run again with the service owner or, if it cannot be fixed in time, the rollback steps from the runbook, with the old server kept unchanged until the service owner accepts

Support the new server through its first busy period, keep the old one recoverable until an agreed date, then hand it to the decommissioning process. Due dates count forward from the cutover date.

• Update the CMDB, documentation and network diagrams — the new server’s record in the CMDB or asset register with its owner, the old server’s record marked as being retired, and the documentation, diagrams and runbooks that name the old server updated
• Switch the old server off and keep it recoverable until an agreed date — the old server switched off or disconnected, not wiped, until a date agreed with the service owner, so files or settings found missing can still be recovered
• Compare performance with the baseline — the same measures as the Phase 3 baseline, taken on the new server over a normal week, with any slowdown investigated and the target resized if needed
• Tell users the move is complete and support them through the first busy period — a message to users that the migration is finished and how to report problems, then extra monitoring and quick support until the first month-end, payroll run or other busy period has passed, including the weekly and month-end jobs listed at the dependency check, with every issue logged and fixed
• Hand the old server to the decommissioning process — the old server passed to the Server Decommissioning Checklist on the agreed date, which removes its DNS records, firewall rules, accounts, backups and monitoring and deals with the hardware or the virtual machine; a domain controller is demoted first
• Close the migration and record what to change next time — the final state of every workload, open follow-ups handed to the service desk or the service owner, and what went well and what to change before the next server migration