Every data center relocation has a checklist. Most of them cover the obvious items: rack inventory, network diagrams, cutover window, downtime notification to stakeholders. The items that actually cause relocations to fail are rarely on the standard checklist.
They are the logistics constraints that were not mapped until move day. The vendor who overpromised and underdelivered on-site. The security clearance that was not submitted in time. The staging buffer that was not planned, so equipment arrived before the floor was ready.
This guide is organized around the phases of a relocation project. The items marked with ⚠️ are the ones most commonly skipped — and most commonly responsible for overruns, delays, and incidents.
Phase 1: Pre-Move Assessment (6–12 Weeks Out)
Environment Documentation
- Complete asset inventory: every rack, every device, make/model/serial number/asset tag
- Network topology diagram updated to current state (not last year's Visio)
- Power draw per rack documented — destination facility needs this to provision circuits
- Cooling configuration at source: hot/cold aisle layout, blanking panel inventory
- ⚠️ Weight distribution per rack — destination floor load ratings may differ from source
- ⚠️ Identify assets that cannot be powered down — these require special handling and sequence planning
- Storage media inventory separate from equipment inventory — every drive, every tape, every SSD that will require chain-of-custody handling
Destination Site Assessment
- Floor space allocation confirmed and physically measured, not just on paper
- Power circuit provisioning complete or confirmed on schedule
- Cooling capacity verified for incoming load
- ⚠️ Loading dock availability and hours — many colo facilities have strict delivery windows and dock queuing requirements
- ⚠️ Elevator dimensions and weight limits — a fully loaded rack can weigh 2,000+ lbs. Not every freight elevator handles that
- Floor path from dock to cage: door widths, turn radii, any obstacles that require equipment to be partially de-racked before moving
- ⚠️ Security clearance process and lead time — submit driver and technician clearance requests now, not two days before the move
- Contact at the destination facility confirmed with after-hours escalation number
Phase 2: Vendor Selection and Contracting (4–8 Weeks Out)
- Define whether you need logistics only, rack-and-stack only, or integrated logistics + installation
- ⚠️ Verify vendors are data center specialists, not general movers — ask specifically how many data center rack moves they have performed
- Confirm cargo insurance coverage: does it cover electronics, what is the per-item limit, what is the aggregate limit per load?
- Confirm no transshipment policy for equipment containing storage media
- ⚠️ Confirm whether on-site technicians are direct employees or subcontractors — and what background check process applies to each
- Chain-of-custody process documented in the contract, not just verbally agreed
- Certificate of destruction format agreed in advance if any equipment is being disposed of
- SLA terms defined: on-time delivery, damage claim process, escalation contacts
- ⚠️ Staging plan confirmed — where does equipment go if the destination floor is not ready at delivery time?
Phase 3: Logistics and Sequencing Planning (2–4 Weeks Out)
- Equipment arrival sequence planned in coordination with installation schedule — equipment must arrive in the order it will be installed
- ⚠️ Delivery windows booked with destination facility — do not assume availability on your preferred dates
- ⚠️ Security pre-clearances submitted for every driver, technician, and crew member who will enter the facility
- Transport vehicles confirmed appropriate for cargo: air-ride suspension for sensitive electronics, climate-appropriate for the route and season
- GPS tracking confirmed active on all transport vehicles
- Packing and crating materials staged at source facility
- Rack labeling scheme defined — every rack and component labeled for destination position before packing begins
- ⚠️ Network turn-up schedule confirmed with destination facility and ISPs — circuits being available on paper is not the same as circuits being tested and ready
- Rollback plan documented: if cutover fails, what is the path back to the source environment, and for how long is that option available?
Phase 4: Change Management and Communication (1–2 Weeks Out)
- Maintenance window communicated to all stakeholders — including external dependencies (vendors, partners, customers) who depend on affected systems
- ⚠️ Application owners confirmed that their apps will survive the move — do not assume. Ask each application owner specifically what the migration impact is and what their validation checklist looks like post-move
- DNS TTLs reduced for any records that will change during cutover
- Monitoring and alerting configured for the destination environment before cutover begins
- On-call schedule defined for the move weekend: who is responsible for what, with direct contact numbers, not ticket queues
- ⚠️ Go/no-go criteria defined in writing — at what point in the move does the team call it and execute rollback vs. push through? Decide this before the pressure is on, not during
- War room or command channel established (Slack, Teams, or bridge line) with all stakeholders in it before move day
Phase 5: Move Execution
- Pre-move walkthrough at source and destination sites completed with logistics vendor the day before
- ⚠️ Serial number and condition photos taken at pickup — before equipment leaves the source floor, every component is photographed
- Manifest signed at source confirming equipment count and condition
- GPS tracking confirmed active before transport departs
- ⚠️ Real-time communication channel with logistics vendor active throughout transit — you should know where your equipment is at all times
- Serial number and condition verified at delivery against departure manifest — discrepancies documented immediately
- Installation sequence followed: foundation infrastructure (power, networking backbone) before compute, compute before applications
- ⚠️ Do not close out the source environment until the destination environment is validated — keep access to the source until you have confirmed the destination is operational
Phase 6: Post-Move Validation
- Full asset reconciliation: every item on the departure manifest confirmed received and in position at destination
- ⚠️ Application-level validation by application owners — not "the server is up," but "the application is functioning correctly under production load"
- Network performance baseline established at destination and compared to source baseline
- Monitoring dashboards confirmed active and alerting correctly in the new environment
- Security controls validated: access controls, firewall rules, logging — these sometimes require reconfiguration in a new environment
- ⚠️ DNS propagation confirmed globally — not just from your office
- Any damage claims documented and submitted to carrier within the claim window (typically 5–9 days for concealed damage)
- Post-move retrospective scheduled: what went wrong, what went right, what the next migration should do differently
The Items That Actually Cause Relocations to Fail
After reviewing dozens of data center relocation post-mortems, the failures cluster around a short list of items — most of which are on this checklist but rarely make it onto the standard template:
- Security clearances not submitted early enough — delivery teams arrive at a secure facility without clearance and cannot get in
- No staging plan — equipment arrives before the floor is ready and sits in a truck or an unsecured loading area
- Arrival sequence not coordinated with installation schedule — the first rack to arrive is the last one needed
- Application owners not consulted — systems are physically moved and fail to come up because application-level dependencies were not mapped
- No go/no-go criteria defined — teams push through a failing migration because no one defined when to stop
- Vendor not inspected before engagement — the logistics provider overpromised capabilities they do not have
The checklist does not guarantee a smooth migration. But it eliminates the category of failures that happen because something was not thought about at all.