Few professional experiences generate as much collective anxiety as the sentence "we're moving data centres." It sounds simple: you unplug things at site A, drive them to site B, plug them back in and you're done. In practice, relocating a data centre is a logistics operation on par with a military deployment, with the added complication that every box weighs hundreds of kilograms, is extremely sensitive to vibration, temperature and electrostatic discharge, and is connected to dozens of cables feeding services that real people depend on around the clock.
If you have ever moved house, you know there is always a missing box, something breaks, and you discover mysterious cables whose origin nobody can explain. Now multiply that by a hundred, add an SLA with financial penalties, and start a countdown timer. Welcome to data centre relocation.
In this article we cover the reasons that justify a data centre move, the planning phases, the physical and network challenges, the strategies to minimise downtime, and the most common disasters we have seen (and lived through) over the years. If you are planning a migration, consider this your survival map.
Why Relocate a Data Centre
Nobody moves a data centre for fun. The decision is usually forced by one or more of these circumstances:
- contract Lease expiry: the building owner refuses to renew, raises the price to unsustainable levels, or the colocation contract has a hard end date. This is the most common reason and, frequently, the one that leaves the least time to react.
- expand Capacity shortage: the infrastructure has grown to fill every available slot. No more racks, no more power, no more cooling capacity. You need a bigger facility.
- euro Cost optimisation: a newer facility with better energy efficiency (lower PUE), more competitive electricity rates, or a more favourable colocation model can significantly reduce OPEX.
- gavel Regulatory compliance: regulations such as GDPR, ENS, or sector-specific standards may require data to reside in a specific location, country, or type of facility.
- merge Mergers and acquisitions: when two companies merge, consolidating data centres is one of the first steps to eliminate duplication and reduce costs.
- upgrade Obsolete facility: the current data centre does not meet Tier III/IV standards, has cooling problems, legacy cabling, or structural risks that are no longer acceptable.
The Logistics Nightmare: Moving Servers Is Not Moving Furniture
A server is not a cardboard box full of books. It is a precision electronic device with disks spinning at thousands of RPM (or NAND chips sensitive to electrostatic discharge), delicate connectors, heavy power supplies, and, in the case of enterprise servers, a weight that can exceed 30 kg per unit. A fully loaded 42U rack, with servers, switches, PDUs and cabling, can weigh between 500 and 1,000 kg.
The physical transport of data centre equipment requires precautions that do not apply to a conventional house move:
- vibration Vibration control: HDD drives are especially vulnerable. A jolt during transport can damage magnetic platters in ways that do not manifest immediately but trigger failures weeks later. Air-ride suspension trucks and anti-vibration foam packaging are essential.
- bolt ESD protection: static electricity can destroy electronic components. The entire process of dismounting, packaging and remounting must be carried out with anti-static bags, ESD wrist straps and grounded work surfaces.
- thermostat Temperature control: if the move takes place in summer with 40-degree heat outside, the equipment cannot sit for hours in an uncooled truck. Climate-controlled vehicles or, at the very least, scheduling around the hottest hours of the day are required.
- local_shipping Specialised vehicles: trucks with tail lifts, loading ramps, rack restraints and, for large-scale relocations, security escorts to prevent theft during transport (those servers contain data of immense value).
- shield Specialist insurance: standard transit insurance does not cover high-value IT equipment. A specific policy covering the replacement value of the hardware and, in some cases, the cost of associated downtime is required.
Planning Timeline: No, You Cannot Do It in a Weekend
One of the most dangerous mistakes is underestimating the time required. A typical data centre relocation needs 6 to 12 months of planning, depending on complexity. Trying to compress that timeline is a recipe for disaster. The process breaks down into clearly defined phases:
| Phase | When | Key activities |
|---|---|---|
| Discovery | D-6 to D-3 months | Full asset inventory, dependency mapping, cabling audit, new facility assessment, risk analysis, migration SLA definition |
| Planning | D-3 to D-2 months | Destination layout design, migration wave plan, transport provider selection, insurance procurement, communication plan, rollback definition |
| Preparation | D-1 month | Provision racks, power and network at destination, replicate data with Veeam, lower DNS TTLs, pre-configure BGP sessions, dry run with non-critical equipment |
| Execution | D-Day | Orderly shutdown, disconnection, labelling, packaging, transport, unpacking, racking, reconnection, power-on, hardware validation |
| Validation | D+1 to D+30 | Service verification, intensive monitoring, performance testing, backup validation, alert tuning, incident closure, final documentation |
Golden rule:
Never try to move the entire data centre in one go. Migrating in waves lets you validate each group of equipment before moving the next, reduces the risk of a catastrophic failure, and keeps critical services running throughout the process. If someone tells you "we'll do it all in one weekend," run.
Physical Challenges: Weight, Power and Impossible Spaces
The physical logistics of a data centre relocation present challenges that seem trivial until you face them in the real world:
- fitness_center Rack weight: a fully loaded 42U rack can exceed 1,000 kg. Many building lifts have a limit of 500-800 kg. Loading doors may not be wide enough. The raised floor at the destination must support the load per square metre. All of these details are discovered (badly) on moving day if they are not verified beforehand.
- power Power compatibility: the source data centre may use single-phase C19/C20 sockets while the destination uses three-phase. Or the rack PDUs are rated for 16A and the destination provides 32A outlets. Or the voltage is different. Every rack needs a detailed power spec sheet before the move.
- cable Fibre cabling: fibre optic cables cannot be "moved." Every connection must be re-patched in the new facility, which means new patch leads, new patch panels and, potentially, new fibre splicing. The source cabling map must be immaculate to reproduce connections at the destination.
- ac_unit Thermal transition: when you power on 50 servers in a rack, you generate several kW of heat instantly. The cooling system at the new facility must be fully operational before the first server is switched on, not after.
- dock_to_bottom Loading dock access: coordinating truck arrivals, forklift availability, goods lift access and the presence of technical personnel at both source and destination simultaneously is a logistical puzzle that demands military precision.
Network Challenges: When an IP Is More Than Just a Number
The physical side of the move is complicated, but the networking side can be even worse. Moving a server from one data centre to another is not just changing its physical location: it is changing its identity on the Internet. The main network challenges include:
- language IP address changes: unless you bring your own PI (Provider Independent) blocks, the IPs from the source data centre do not belong to you. Your servers will receive new IPs at the destination, which affects DNS records, access lists, SSL certificates bound to IPs, firewall rules and any system that filters by source IP.
- dns DNS propagation: even if you lower the TTL to 60 seconds weeks before the migration (and you should), many resolvers ignore low TTLs. There will always be a percentage of users still pointing at the old IP for hours or even days.
- route BGP re-peering: if you use your own AS and announce prefixes via BGP, you need to establish new BGP sessions with the upstreams at the destination data centre. This requires coordination with the new facility's NOC and can take days to fully converge.
- vpn_lock VPN tunnels: every site-to-site VPN tunnel has endpoints configured with specific IPs. Both ends of each tunnel must be reconfigured, which means coordinating with customers, partners and remote offices that may be in different time zones.
- security Firewall rules and certificates: ACLs based on source IP, SSL certificates with SANs that include IPs, WAF rules and CDN services pointing to the origin by IP all need to be updated in coordination with the network changeover.
Minimising Downtime: Strategies That Work
The goal of every relocation is for user-perceived downtime to be minimal or, ideally, zero. These are the most effective strategies, as we document in our data centre migration guide:
- waves Migrate in waves: divide equipment into priority groups and move them in successive waves. First non-critical systems (development, staging), then semi-critical, and finally production. Each wave is validated before the next one begins.
- content_copy Pre-replicate data: before physically moving a server, replicate all its data to the destination using tools like Veeam, rsync, or storage-level replication. On moving day only the incremental delta needs to sync, reducing downtime from hours to minutes.
- swap_horiz DNS-based failover: point DNS records to the destination before shutting down the source. With low TTLs and a parallel running period, traffic migrates gradually without users experiencing an abrupt cutover.
- sync Parallel running period: keep services operational at both data centres simultaneously during a transition window. It costs more (you pay for double hosting temporarily), but it eliminates the downtime window entirely.
Practical tip:
Lower DNS TTLs to 60-300 seconds at least two weeks before the migration. If you lower them on the day, resolvers will still have the old TTL cached (which was probably hours or days) and you will not see the effect.
The Human Factor: Coordination, Communication and Pizza
Technology is half of a data centre move. The other half is people. And people get tired, stressed, make mistakes, and need to eat. Managing the human factor is just as critical as managing the technology:
- groups Shift coordination: a large move can last 24-48 hours straight. You need at least two shifts of technical staff, with planned handovers and documented shift notes. Nobody makes good decisions at 3 AM after 16 hours of work.
- campaign Communication plan: customers, partners, internal teams, network providers, the source data centre NOC and the destination NOC. Everyone must know what is going to happen, when, and what their role is. A centralised communication channel (war room, dedicated Slack/Teams channel) is essential.
- undo Rollback triggers: define in advance which conditions trigger a rollback. If server X does not boot within 30 minutes, revert to source. If network latency exceeds Y ms, roll back the DNS change. Without clear triggers, decisions are made in panic at 2 AM.
- restaurant Pizza budget (seriously): this is not a joke. Food, coffee and drinks during a long move are a team performance factor. A well-fed, rested team makes fewer mistakes. Include catering in the project budget. Your future self will thank you.
Common Disasters (That We Have Actually Seen)
After years of accompanying customers through data centre relocations, we have compiled a catalogue of disasters that repeat with surprising frequency. If your migration plan does not account for at least half of these scenarios, it is not complete:
- warning The server that fell off the trolley: it seems unlikely until it happens. A 25 kg server poorly secured on a trolley, a raised floor tile that is slightly loose, and gravity does the rest. Solution: strict handling protocols and always two people per heavy piece of equipment.
- warning The forgotten cable: "that grey cable going to... somewhere" turns out to be the iLO/IPMI out-of-band management connection for 20 servers in the rack. Nobody documented it. Solution: audit and label absolutely every cable before dismounting anything.
- warning Wrong rack position: the server is mounted at U24 instead of U22 and now the cabling does not reach, the PDU ends up the wrong way round and you have to take apart half the rack to fix it. Solution: layout diagrams with exact positions, verified before starting.
- warning Incompatible power: you plug in the rack and the breaker trips because the sockets in the new facility are a different amperage than expected. Or the PDUs are single-phase and the outlets are three-phase. Solution: cross-verified power audits weeks before D-Day.
- warning The DNS TTL nobody lowered: the migration executes perfectly, the servers are up and running in the new facility, but 70% of traffic is still going to the old IPs because the DNS TTL was 24 hours and nobody changed it. Solution: include "lower TTL" on the preparation checklist, not the execution checklist. As we discuss in our article about why a server rack in a cleaning room is not a data centre, improvisation is the worst enemy of IT infrastructure.
Professional Relocation Services
Given the complexity and risk of a data centre relocation, more and more companies choose to outsource the operation to teams specialised in infrastructure migration. A professional team brings:
- check_circle Accumulated experience: they have carried out dozens of moves and know the problems before they occur.
- check_circle Specialised equipment: server trolleys, anti-static and anti-vibration packaging, climate-controlled vehicles.
- check_circle Adequate insurance: policies covering the actual replacement value of the equipment and the impact of downtime.
- check_circle Proven methodology: checklists, planning templates, rollback protocols and communication plans already tested in production.
EasyDataHost: Your Migration Partner
At EasyDataHost we have been helping companies move their data centre infrastructure with minimal impact on operations for years. Our approach combines rigorous planning with the operational flexibility that each project demands:
- check_circle Infrastructure migration: end-to-end planning, wave-based execution, pre-replication of data and post-migration validation.
- check_circle Colocation: if your destination is our Tier III+ data centre in Madrid, we prepare the space, power and connectivity before you arrive.
- check_circle Managed services: once the migration is complete, our team takes care of monitoring, maintenance and operation of your infrastructure in the new facility.
Conclusion
Relocating a data centre is one of the most complex, stressful and risky operations an IT department can face. But with proper planning, a realistic timeline, a coordinated team and a proven methodology, it is perfectly achievable without drama (or at least with controlled drama).
- arrow_right Physical logistics require specialised vehicles, vibration control, ESD protection and temperature management.
- arrow_right Planning needs 6 to 12 months and a phased, wave-based approach.
- arrow_right Network challenges (DNS, BGP, VPN, firewall) can cause more downtime than the physical move itself.
- arrow_right Pre-replication of data and DNS failover are key to minimising impact.
- arrow_right The human factor (shifts, communication, pizza) is just as critical as the technology.
If you are planning a data centre move and need a team to guide you through the entire process, contact our team. We know where it hurts and we know how to stop it hurting more than it needs to.