Server Migration Checklist: What to Check Before, During and After the Move

A server migration is complete when people can safely do their work on the new system, the data is correct and recovery has been tested. A server that boots successfully or a file transfer that reaches 100% does not establish those outcomes.

This server migration checklist covers what to check before, during and after the move. It is written for business owners and IT teams planning a hardware replacement, Windows Server upgrade, virtual-machine move or cloud migration. It includes practical acceptance tests, a rollback decision framework and a reusable change-record template.

The checklist is a planning framework, not a replacement for the supported procedure for your exact operating system, database, application and migration tool. A file server, a SQL Server and an Active Directory domain controller require different methods. For help applying it to your environment, see our server migration services in Toronto and Mississauga.

Server migration checklist at a glance

Give every check an owner, a result and a link to evidence. “Done” should mean something observable, such as a successful restore or an approved invoice test, rather than a reassuring comment in a meeting.

First, choose the right migration method for each workload

Start with the business service, not the physical box. One old server might host shared folders, an accounting database, a print service and an overnight export. Those functions may need separate destination systems and separate acceptance tests.

• File server: assess shares, file permissions, ownership, open files, paths and client access. Microsoft’s Storage Migration Service workflow separates inventory, transfer and cutover. Treat those as separate checkpoints.
• SQL Server: choose a supported database migration method and check version compatibility. The Microsoft upgrade guide covers assessment and migration considerations. Include logins and server-level dependencies, such as jobs and linked servers, rather than treating a database file as the whole application.
• Active Directory domain controller: use an identity-specific plan. Microsoft recommends introducing domain controllers on the newer operating system and demoting the old ones rather than relying on an in-place upgrade. Follow the domain-controller upgrade guidance, including prerequisites and role considerations.
• Virtual machine: confirm that the destination supports the guest, disks, networking and attached devices. A successful VM conversion still needs application testing.
• Cloud migration: include connectivity, region, identity, storage performance, backup and operating costs. Moving a VM does not automatically redesign its application for cloud availability.
• Physical relocation: add equipment inventory, rack space, power, cooling, transport, cabling and remote-console access. Preserve a recoverable copy outside the equipment being transported.

Do not mistake a file migration tool for an application installer. Microsoft’s Storage Migration Service FAQ explains exclusions, including operating-system and application directories, and limitations affecting locked files and domain boundaries. Check the exact supported scenario before choosing the tool.

Before server migration: preparation checklist

1. Define scope, responsibility and measurable success

Write down what is moving, what is staying and why. Record the source and target, application owner, technical lead, business approver and escalation contacts. Include vendor support availability during the actual change window, not just ordinary office hours.

Replace “everything works” with specific acceptance criteria. For example: staff can open the shared project folder, finance can post an approved test transaction, a remote employee can connect through the VPN, and an unauthorized user cannot open payroll files. Decide how to handle each failed test before the outage begins.

2. Inventory the dependencies people forget

Record more than CPU, memory and disk capacity. Build a dependency register that answers who connects, how they authenticate, what they read or write, and what happens if the connection fails.

• Server names, IP addresses, DNS records, network routes and firewall rules.
• Operating-system versions, installed roles, application versions and licence arrangements.
• Service accounts, scheduled tasks, database connections and scripts with fixed paths.
• Certificates, private keys, encryption recovery material and renewal responsibilities.
• Printers, scanners, mapped drives, shortcuts and devices that write directly to shared folders.
• Email relays, payment services, reporting tools, imports, exports and third-party integrations.
• Backup agents, monitoring, endpoint protection and management access.

Ask departments to demonstrate their routines. An overnight export may be invisible during a daytime walkthrough. A scanner can keep writing to an old share even after employees have closed their documents. Include periodic tasks such as month-end reporting in the inventory.

3. Check compatibility before purchasing or building the target

Confirm that the application vendor supports the proposed operating system, database version and deployment model. Check required drivers, runtimes, authentication methods and hardware devices. Verify licensing and activation with the relevant supplier, especially when changing hosts, CPU allocation or cloud location.

Separate a necessary migration from optional modernization. Moving the server, upgrading the database and replacing the application in one window increases the number of possible failure causes. Where practical, sequence changes so each can be tested independently. Record any changes that must stay together.

4. Measure performance and size the destination

Collect a baseline during representative busy periods. Useful measurements include application response time, CPU demand, memory pressure, storage latency, free space and network throughput. Include growth, temporary migration files and backup storage in the capacity plan.

Do not equate a larger disk with a faster system. Many small files, competing workloads or storage latency can dominate the transfer and the user experience. For cloud targets, assess recurring compute, storage, backup and network charges as well as the initial move.

Set acceptance thresholds from business needs and observed performance. A report that normally takes two minutes should have an agreed acceptable range; “the new server feels slow” is too vague to drive a cutover decision.

5. Test recovery, including access to encryption keys

Take backups appropriate to the workload and perform a restore to a controlled environment. Confirm that the restored application opens, the required data is present and the team can obtain the credentials and keys needed during an outage. Record the recovery point and elapsed restoration time.

A successful backup job is useful evidence, but it is not the same as a successful restore. For SQL Server, Microsoft explicitly states that RESTORE VERIFYONLY does not restore the backup or fully verify the structure of its contents. Use it within a recovery process, not as proof that the business application can recover.

For a TDE-protected SQL database, plan the encryption material separately. Microsoft’s TDE migration guidance requires the certificate or asymmetric key needed to open the database encryption key at the destination. Protect the required private-key material and test its availability rather than assuming the database backup alone is sufficient.

A VM checkpoint may be useful within a supported procedure, but it should not be your only recovery plan. Scope application-consistent protection, independent recovery copies and retention with the workload owner. Our backup and disaster recovery support covers planning for recovery beyond the migration window.

6. Agree on downtime, RPO and RTO

Recovery point objective (RPO) is the maximum acceptable data loss expressed as time. Recovery time objective (RTO) is the target time to restore the service after disruption. The planned maintenance window is a separate commitment. A backup schedule alone does not prove either objective can be met.

Ask concrete questions: Can finance re-enter any transactions? Can orders queue safely? How long can staff work without shared files? Which service must recover first? Record the answers by workload instead of assigning one optimistic number to the entire company.

7. Rehearse and write a timed runbook

Use a representative test to discover missing steps and realistic timings. Where production data is needed, protect it to the same standard as production and limit access. Prevent test systems from sending real customer emails, triggering payments or writing back to live integrations.

Microsoft’s Hyper-V-to-Azure tutorial includes a test migration before the full migration. Apply the broader principle of proving the destination before the production switch, while following the requirements of your chosen platform.

The runbook should specify an executor, prerequisite, expected result, time budget and recovery action for each step. Keep it accessible if the server or authentication system being migrated becomes unavailable. AWS’s pre-cutover guidance also emphasizes rehearsals, dependencies, testing and time for rollback. Reserve that time explicitly.

During server migration: cutover checklist

8. Hold a go/no-go check before changing production

Confirm all six conditions: the destination is ready; recovery evidence is current; required people are available; the business has approved the outage; critical tests are prepared; and the rollback deadline still leaves enough time to restore service. Pause when a condition fails. Do not silently accept a new risk because a calendar invitation says the migration starts now.

Tell users when work must stop, which services are affected, how to report problems and when to expect the next update. Record the start time and freeze unrelated changes so troubleshooting has a clear starting point.

9. Stop all relevant writers and finish the final transfer

Use the workload’s supported method to pause writes and obtain a consistent final state. Include background services, scheduled jobs, integrations and devices as well as interactive users. Capture the final recovery point and complete the planned synchronization.

Review migration logs and reconcile failed, skipped or excluded items. A transfer can report completion while individual files remain inaccessible. For live databases, use the supported database-aware migration process rather than assuming a copy of open data files is consistent.

Keep one authoritative writable production system unless the application has an explicitly designed and tested multi-writer architecture. Two independently writable copies can create conflicting records that cannot be resolved by switching a DNS entry.

10. Change service identity and connectivity deliberately

Execute the agreed method for names, addresses, routes, load balancers or connection strings. Do not reuse a source identity on the destination while the old machine remains active with the same identity on the network.

Check DNS from the networks users actually use. Reduced DNS time-to-live can help with planned changes, but existing caches and persistent connections may still affect the transition. Some systems use fixed IP addresses or saved connection strings and will not follow a DNS change at all.

Validate certificates, authentication and firewall access together. A service can be reachable but still unusable because its certificate name is wrong or its service account lacks access. Coordinate necessary network changes with network and firewall support, and remove temporary broad access after testing.

11. Test business transactions before releasing all users

Use representative non-administrator accounts. Administrators can pass tests that ordinary users fail, and they cannot prove that confidential folders are properly restricted.

• Open, create, modify and retrieve an approved test document in the right shared location.
• Run a representative application workflow, including a write and subsequent read.
• Check a report or integration against the same agreed data point on source and destination.
• Verify that a user without authorization is denied access to a restricted resource.
• Test remote access, printing, scanning and scheduled jobs where they are in scope.

Use controlled test records and agree on cleanup or reversal with the business owner. Once the destination accepts new production writes, the rollback plan must account for that data. Record the release decision and the person who made it.

After server migration: validation and handover checklist

12. Validate data, security and performance separately

There is no single test that proves the entire migration. Use several forms of evidence and document the limits of each.

For a domain-controller project, include directory replication, DNS, time synchronization, SYSVOL and Group Policy validation in the specialist runbook. Do not treat an ordinary VM snapshot reversal as a universal directory recovery method.

13. Protect the new production environment immediately

Verify that the backup system includes the new machine and the right application data. Check retention, encryption, destination access and alert recipients. Perform a restore from a backup created on the new production environment, not only from the pre-migration source.

Confirm endpoint protection, patch management, log collection and monitoring. Test an alert route so someone receives a failure notification. If using Acronis cloud backup, verify the actual workload protection plan and recovery options rather than relying on agent installation alone.

14. Observe a meaningful business cycle

Schedule enhanced monitoring after cutover. Review application errors, authentication failures, storage growth, backup results and user reports. Track each issue with severity, owner and resolution evidence.

One quiet morning does not cover an overnight import or a month-end process. Either observe the relevant cycle or test it safely and obtain explicit acceptance of any remaining uncertainty. Agree on the observation period based on the service, not an arbitrary universal number of days.

15. Hand over, sign off and retire the source safely

Update diagrams, inventories, recovery instructions, licensing records and supplier contacts. Document the destination, remaining risks, support ownership and escalation route. Ongoing server support should begin with this record, so the next technician does not have to reconstruct the move.

Retire the source only after acceptance, recovery validation and the agreed rollback window. Preserve records and backups according to the organization’s retention requirements. Remove temporary accounts and permissions, old monitoring entries and obsolete network rules after confirming their dependencies.

If hardware or storage will leave your control, use an approved sanitization and disposal process. Keeping an old server powered on indefinitely is not a recovery strategy; it creates another system that needs protection and ownership.

When should you roll back a server migration?

Agree on triggers such as failed critical workflows, unreconciled data, unsafe permissions or a missed decision deadline. A named decision maker should choose between a bounded repair and rollback using the remaining recovery time.

The important dividing line is whether the destination has accepted new data. Before new writes, reversal may be comparatively simple. Afterwards, switching users back can strand or lose transactions unless the plan reconciles them. AWS’s cutover and rollback guidance makes this distinction and calls for an explicit data-handling strategy.

Record how new records, files and queued work will be captured and recovered. Confirm whether the older software can accept data from the newer version; do not assume database downgrade or reverse replication is supported. Sometimes a controlled repair on the destination is safer than returning to a stale source. That choice needs business approval, technical evidence and a time limit.

Example: planning a four-hour migration window

Illustrative planning example, not a customer case study or a promised duration. A 25-person business is moving shared files and an accounting application. The initial bulk transfer happens before the outage. A rehearsal is assumed to have measured these remaining steps:

• Final write freeze, recovery point and synchronization: 45 minutes.
• Service cutover: 30 minutes.
• Critical acceptance tests: 45 minutes.
• Rollback plus recovery validation, if required: 60 minutes.

With a four-hour window and a 30-minute contingency reserve, the latest rollback decision is 150 minutes after the window starts: 240 minus 60 minus 30. The planned forward path reaches acceptance testing at 120 minutes, leaving only 30 minutes for bounded troubleshooting before that decision.

This is why the whole four hours cannot be treated as time available to keep trying the migration. If the final synchronization takes longer than rehearsed, the remaining decision budget shrinks. Change the plan or reschedule when the numbers no longer support safe recovery.

Copyable server migration change record

Copy these fields into your change ticket or project workbook. Keep credentials in the approved password manager, not in the ticket.

• Business service and change ID: purpose, scope and excluded systems.
• Source and destination: names, versions, network locations and responsible owners.
• Migration method: vendor procedure, tool version and compatibility evidence.
• Dependencies: users, applications, identities, jobs and external connections.
• Recovery objectives: RPO, RTO, maintenance window and latest rollback decision time.
• Recovery evidence: backup reference, restore-test date, duration and key-access confirmation.
• Execution steps: sequence, executor, expected result, allotted time and actual completion time.
• Validation: test case, account or role, expected result, actual result and evidence link.
• Rollback: trigger, decision owner, procedure and handling of new destination data.
• Handover: monitoring owner, support contacts, open issues and retirement approval.

Server migration checklist: frequently asked questions

How long does a server migration take?

Separate total project time from user downtime. Discovery, target preparation and initial data transfer may happen before the maintenance window. The outage depends on final synchronization, application changes, validation and recovery allowance. Use a rehearsal to estimate your environment rather than a fixed promise based only on data size.

Can we migrate a server without downtime?

Some architectures and tools support low-disruption moves, but that does not guarantee zero application downtime. The answer depends on replication, consistency requirements, client behaviour and the supported cutover method. Define what “available” means for the actual workflow, including writes and integrations.

What is the difference between server migration and server upgrade?

A migration moves workloads or data to another environment. An upgrade changes software or hardware capability. A project can do both, but the test plan should distinguish relocation issues from version-change issues.

Is copying all the files enough?

No. Services may also depend on permissions, identities, certificates, installed applications, databases, scheduled tasks and fixed paths. Confirm the scope and exclusions of the migration tool and test the business functions that use the files.

Should we keep the old server after migration?

Keep it only within an agreed recovery and retention plan. Prevent conflicting production writes and manage its security while retained. Decommission it after acceptance and recovery checks, with explicit approval for any data destruction.

What information should we give an IT migration provider?

Share the workload inventory, versions, data volume, business hours, application contacts, known issues and recovery objectives. Ask for a written scope, exclusions, cutover plan, rollback conditions, acceptance tests and post-migration support arrangements.

Planning a server migration in Toronto or the GTA?

For businesses in Toronto, Mississauga, Oakville and Vaughan, the practical starting point is a clear inventory and a tested recovery plan. Onsite work may be needed for hardware, cabling or physical moves; remote work may cover discovery, configuration and validation. Agree on the required access and responsibilities before setting a cutover date.

IT Support Hub can help you discuss the scope of a server migration, backup preparation and ongoing support. Contact us to plan a migration assessment and identify the dependencies and acceptance checks for your business.

Research note: This article combines an original operational checklist with the Microsoft and AWS technical documentation linked beside relevant claims, reviewed October 25, 2026. Product support and migration limitations can change. Recheck the documentation for your exact source, target and tool versions before execution. The timing example is illustrative, not a performance benchmark.