A data centre migration can look straightforward on a project plan: shut down the equipment, move it, reconnect it, and bring the services back online.
The real migration risk sits in the dependencies between those steps.
Applications rely on networks, storage, identity services, external connections and other systems that may not be obvious from a rack inventory. At the destination, having enough physical space is not enough if power, cooling, connectivity or access arrangements have not been tested against the equipment that is actually arriving.
A practical data centre migration checklist should reduce that uncertainty before the cutover begins. It should show what is moving, what each service depends on, whether the destination is ready, how recovery will work and who can stop the migration if an agreed condition is not met.
The physical move may happen over a weekend. The work that makes it controlled starts much earlier.
Define success before choosing the migration date
Start with the services the organisation needs to protect, not the racks you intend to move.
For every business-critical workload, establish what a successful migration means. That includes acceptable downtime, important dependencies, recovery expectations, and the person who can confirm that the service is working normally after cutover.
This prevents the technical team from treating "server powered on" as the definition of success.
Document:
business and technical ownership
acceptable outage window
application and storage dependencies
network and external connections
authentication requirements
recovery objectives
validation tests
rollback criteria
Some systems will need to move together. Others may be able to remain temporarily at the source site.
Those dependencies should determine the migration sequence.
Verify what is actually running
Migration planning often exposes a gap between what documentation says exists and what is really operating.
The NCSC's asset management guidance recommends maintaining an accurate and authoritative understanding of technology and information assets. That becomes particularly important before physically relocating infrastructure.
Your discovery work should cover hardware, virtual machines, storage, switches, firewalls, software licences, external connections, power requirements and the owners of critical services.
Where practical, compare documentation with the physical racks, monitoring systems, network configuration and asset records.
This is also the right time to decide what does not need to move .
Unused circuits, obsolete appliances, unsupported systems and redundant hardware introduce extra work and dependencies. Retiring them before migration reduces the number of variables the team has to control during cutover.
Data centre migration checklist
Before setting the final cutover date, confirm that you can answer yes to each of these.
Critical services, technical owners and acceptable downtime are documented.
Hardware, virtual infrastructure, storage and network assets have been verified.
Application, storage, authentication and network dependencies are mapped.
Obsolete or unnecessary infrastructure has been identified for retirement.
Destination rack space, equipment fit, power and cooling have been confirmed.
Required carrier circuits, cross-connects and network routes are ready.
Firewall, VLAN, DNS and addressing changes have been prepared.
Backups, replication and recovery procedures have been tested.
Workloads are grouped into an agreed migration sequence.
The cutover runbook gives every action a named owner.
Go/no-go conditions and rollback thresholds are documented.
Post-migration infrastructure and application tests are agreed.
Escalation contacts and decision-makers are available during cutover.
The source environment will remain available through the agreed rollback period where practical.
Decommissioning will begin only after formal migration acceptance.
Treat these as migration gates rather than boxes to tick on the day.
If a critical dependency remains unresolved, a recovery procedure is untested, or a destination connection is incomplete, that workload may not yet meet the agreed go-live criteria.
Prove the destination before production arrives
A new data centre should be considered ready only when the infrastructure required by the incoming workloads has been checked.
Do not wait until migration night to discover that a server does not fit the cabinet, a PDU has the wrong connector, or a rack needs more cooling than the assigned location can provide.
Confirm the expected power draw and density rather than simply recreating the old rack layout.
Consider:
contracted power allocation
rack-level power requirements
PDU capacity and connector types
A/B feeds where required
expected thermal load
air or liquid-cooling requirements
future capacity headroom
If the migration includes hardware consolidation, AI infrastructure, or higher-density equipment, reassess the target environment around the new configuration.
At Carbon-Z, we assess air-cooled deployments individually to confirm that rack positioning, power draw, and airflow requirements are matched to the appropriate part of the facility. The same principle applies to migration planning: the destination should be matched to the hardware rather than assuming the existing layout can simply be reproduced.
For standard compute, storage and networking infrastructure that remains within conventional cooling requirements, our air-cooled colocation service provides a hosted environment built around those workload requirements.
When the destination itself is still being evaluated, our guide to where to colocate in the UK covers the wider power, cooling, connectivity and capacity questions worth resolving before committing to infrastructure.
Prepare rack elevations in advance.
Account for the server hardware as well as PDUs, switching, patching, cable routing, airflow clearance, liquid-cooling equipment where applicable, and maintenance access.
Rails, brackets, and associated components should also be matched to the equipment they belong to.
A box of unlabelled rails has derailed more than one supposedly straightforward installation.
Treat connectivity as its own workstream
A correctly installed server is still unavailable if the production network path is incomplete.
Connectivity planning should begin early because carrier circuits, cross-connects and third-party changes may take longer than the physical move itself.
Before cutover, verify that required circuits are live and that routing, VLANs, firewall rules, DNS changes, remote management and monitoring have been prepared.
Private connections and external partner routes should be tested wherever possible before production workloads move.
Where resilience matters, the migration can also be an opportunity to remove an existing network single point of failure. Our guide to improving network resilience in data centres explains why carrier and path diversity should be considered alongside bandwidth.
Where new network routes are needed, Carbon-Z's data centre connectivity services include carrier-neutral access, dedicated internet and private cross-connects. These connections should be scoped before the cutover date is fixed rather than after the equipment arrives.
Write the runbook backwards from rollback
A migration runbook should not begin with shutting down the first server.
Start with the point at which the team would stop the migration and recover the service using the agreed fallback plan.
For each workload, define four things:
Go condition: What must be true before the migration starts?
Validation condition: What proves the workload is operating correctly at the destination?
Rollback trigger: Which failure or delay means the migration stops?
Rollback deadline: At what point is there no longer enough time to recover the original service within the agreed window?
Those thresholds give the migration team agreed decision points before the cutover window starts.
Uptime Institute's Annual Outage Analysis 2026 reports that failure to follow established procedures remains the leading driver of human-error-related outages. Unclear or inconsistent processes also continue to contribute.
A migration runbook should therefore specify actions, owners, timings, and evidence of completion rather than rely on instructions such as "move server" or "test application".
Move workloads in deliberate waves
Not every environment should move in one large cutover.
Where the architecture allows it, phased migration allows the team to prove the new environment and refine the process before the most critical systems move.
A typical order might be:
Foundation services needed to manage or monitor the destination.
Lower-risk workloads that can prove rack, network, and operational procedures.
Related application groups that should remain together.
Critical production systems once the process has been demonstrated.
Specialist or residual equipment requiring additional handling.
Dependencies take priority over a neat project schedule.
Do not split closely connected systems simply to create tidy migration waves if doing so introduces unacceptable latency, operational complexity or additional failure points.
Test the recovery route before shutdown
"Backup completed" is not the same as "service can be recovered".
Before moving a critical workload, establish whether the planned recovery process works within the available time.
The NCSC guidance on resilient networks and systems recommends maintaining secured and accessible backups while routinely checking that restoration processes work.
For migration purposes, confirm:
the timing of the final recoverable copy
whether configuration data is included
whether recovery data remains accessible if the source environment is unavailable
how long restoration has taken during testing
how changes made during cutover will be handled
who can authorise rollback
For workloads with very short recovery requirements, replication or temporary parallel operation may be more appropriate than relying entirely on restoration from backup.
That decision should be made during planning, not after a cutover fails.
Keep migration day deliberately boring
The migration window should be the execution of decisions already made.
Before shutdown begins, freeze unrelated infrastructure changes, confirm recovery status, verify that both sites are ready, and make sure the people responsible for power, network, applications, and escalation are available.
Physical equipment should also remain traceable through removal, transport, and installation.
Label hardware, rails, cabling and associated components clearly. Where infrastructure or stored data is sensitive, transport and site-access controls should reflect the organisation's security requirements.
Most importantly, record deviations from the runbook as they occur.
If the first migration wave exposes a wrong assumption, later waves should benefit from that information.
Power-on is only the start of validation
Once the hardware has been installed, test the service rather than just the equipment.
Validation should cover four levels:
Infrastructure: hardware health, storage, interfaces and monitoring.
Network: routing, DNS, firewall behaviour, remote management and resilience.
Application: services, databases and external integrations.
Business: the agreed user or service-owner acceptance tests.
Backup jobs and alerts should also be checked after the move.
Where performance matters, compare the migrated service with an agreed pre-migration baseline rather than assuming that a running application is performing normally.
Decommission only after formal acceptance
The old environment should not disappear simply because the new one has powered on successfully.
Once the destination has passed its technical and business validation and the agreed rollback period has ended, the source environment can be retired in a controlled way.
That may include removing old DNS records and firewall rules, closing redundant circuits, updating diagrams and asset records, removing old monitoring targets and sanitising storage before disposal or reuse.
Closing the original environment too early removes recovery options.
Leaving it indefinitely creates duplicated cost and additional infrastructure to maintain and secure.
The retirement date should therefore be part of the migration plan from the beginning.
Leave very little to decide during cutover
A useful data centre migration checklist cannot guarantee that every change will go exactly to plan.
Its purpose is to expose foreseeable problems while there is still time to resolve them.
By the time the migration window begins, the team should understand the dependencies, know that the destination has been validated, have working network paths, know how each service will be tested, and have agreed thresholds for stopping or rolling back the change.
The physical move is only one part of the project.
The real risk reduction comes from proving as much as possible before the first production system is switched off.