Move Without Losing Control: How to Prepare Network Infrastructure for a Data Centre Relocation
- TNS Blogs
- Aug 18
- 7 min read
A data centre relocation can compress months of planning into one demanding cutover window. Servers may be the most visible assets, but the network determines whether applications can communicate, users can connect and recovery teams can reach critical systems.
The greatest risks are often hidden: an undocumented fibre link, a fixed IP address, an expired support contract or a device that has not been restarted for years. Discovering any of these after shutdown can turn a planned move into an extended outage.
In this blog post, we explain how to prepare network infrastructure for a data centre relocation, from auditing the existing estate and preparing the new site to testing circuits, controlling the physical move and validating services. We also explain where early advice from an experienced relocation partner such as TNS Comms can reduce uncertainty, prevent avoidable delays and make the cutover easier to control.
Start with Business Risk, Not Rack Numbers
A relocation is not simply a transport project. It changes network paths, power feeds, security boundaries and the operating environment supporting business services. The plan should therefore begin with acceptable downtime, recovery objectives and business impact.
Before designing the move, agree:
Which business services and physical assets are in scope.
The accountable owner and technical lead for each service.
Maximum acceptable outage and data-loss tolerance.
Whether the move will be completed in one window or phased waves.
Who can approve go-live, stop the move or order a rollback.
How long the old site must remain available as a recovery option.
Some organisations can tolerate a weekend shutdown. Others need temporary replication, parallel operation or newly built equipment at the destination. TNS Comms can advise on the physical infrastructure implications early, when cabinet layouts, cabling routes, hardware handling and migration sequencing can still be changed economically.
Audit the Existing Network Before Designing the New One
Do not assume that old diagrams describe the live environment. Combine records with physical inspection, network discovery and conversations with service owners. Photograph rack fronts and rears, export configurations and trace every cable that supports a critical service.
Your audit should record:
Site, room, cabinet and rack-unit position.
Manufacturer, model, serial number, asset ID and support status.
Equipment dimensions, weight, rails, lifting requirements and A/B power.
Copper, fibre, console, storage and management connections.
Switch ports, VLANs, subnets, routes and gateway locations.
Carrier circuit references, firewall rules, VPNs, certificates and DNS.
Whether each asset will be moved, replaced, retired or left temporarily.
An experienced physical-network team can often spot risks that a software inventory misses: damaged fibre, unsupported optics, blocked airflow, improvised patching, incorrect labels or equipment that cannot be moved safely. Asking TNS Comms to survey the estate can provide a stronger foundation for the rack plan, cable schedule and cutover sequence.
Map Dependencies and Recovery Order
A healthy server can still be unavailable if DNS, identity, storage, routing, load balancing or firewall policy has not been restored. Dependency mapping links physical equipment to the business services it supports and establishes the order in which systems must return.
For every critical service, identify:
Application, database, storage and identity dependencies.
Required internal, internet, cloud and third-party traffic flows.
DNS, DHCP, NTP, certificates and key-management services.
Firewall, NAT, VPN and load-balancer requirements.
Shutdown, replication and restart sequence.
A technical health check and a real business transaction for acceptance.
The manual workaround if recovery exceeds its objective.
This map becomes the backbone of the cutover runbook. It also prevents teams from powering on equipment in an arbitrary order and then losing time diagnosing expected dependency failures.
Make the Destination Ready Before Moving Hardware
The destination should operate as a functioning data centre before production equipment leaves the old site. Cabinets, power, cooling, security, carrier circuits, internal cabling and out-of-band management must be installed and tested.
Confirm that:
Cabinets are positioned, anchored, bonded, labelled and built to approved rack elevations.
Rack depth, rails, power connectors and load ratings match the equipment.
A/B feeds are available and traced to the intended power paths.
Cooling and airflow management can support the expected load.
Carrier handoffs and cross-connects pass agreed acceptance tests.
Copper and fibre links are terminated, labelled and certified.
Secure access, delivery routes and staging areas are ready.
Patch leads, optics, spares, tools and console cables are already on site.
Confirm the facility standards and contractual requirements during design. Relevant references include BS EN 50600-2-4:2023 for data centre cabling and ANSI/TIA-942-C for wider infrastructure.
TNS Comms can install and test new suite cabling, cabinets and associated infrastructure before the move. Its own relocation guidance stresses that infrastructure should be tested before hardware or servers are moved, exactly the sequencing that prevents wasted time during the outage window.
Prepare Cabling, Fibre and Patch Schedules
A relocation is an opportunity to replace confusing cabling with a maintainable design. Produce rack elevations and port schedules using one naming convention from drawing to device.
Specify:
Copper category and fibre type for the required speed and distance.
Connector, polarity, optic, wavelength and optical-loss budget.
Diverse A and B routes where resilience requires them.
Containment, bend radius, pathway fill and spare capacity.
Meet-me-room, carrier and suite demarcation points.
Copper certification, insertion-loss results and OTDR traces where required.
Prepare labelled patch packs by rack or migration wave. TNS Comms can advise on cable types, route diversity, cabinet presentation and test requirements, then reconcile the completed installation with the move schedule. This creates a clearer handover and reduces the risk of engineers improvising under time pressure.
Order Circuits Early and Decide the IP Strategy
Carrier services can control the project date, so order and test internet, WAN, cloud and voice connectivity early. Retain enough overlap between sites for replication and rollback where possible.
For each service, confirm the bandwidth, handoff, demarcation, route diversity, addressing, security, performance limits and cutover escalation contacts.
Decide whether workloads retain their IP addresses or move to new subnets. Layer 2 extension reduces reconfiguration but may enlarge the failure domain. Readdressing requires coordinated DNS, firewall, NAT and third-party changes. Test from real user and partner paths.
Protect the Move with Backups and a Rollback Plan
Back up data and the infrastructure needed to recover it: switch configurations, firewall policy, hypervisor settings, certificates, keys, IP records and current diagrams. A successful backup job is not enough; complete a representative restore before cutover.
The NCSC recommends multiple copies in different locations and describes the familiar 3-2-1 approach: three copies, on two devices, with one off-site.
Before the move:
Confirm backup and replication status for every critical service.
Export and securely store network-device configurations.
Protect credentials, licences, keys and recovery methods.
Define the last consistent data point before shutdown.
Agree objective rollback triggers and the latest safe decision time.
Keep the old environment intact until acceptance is complete.
Rollback is a designed recovery path, not an admission of failure. It must explain how traffic, DNS and data will return to the old site and how transactions created after cutover will be reconciled.
Build and Rehearse the Cutover Runbook
Every runbook action should have an owner, planned time, prerequisite, expected result and recovery step. Replace vague instructions such as “move the network” with small, observable tasks.
Include:
Go/no-go gates before shutdown, dispatch, power-on and traffic migration.
Final replication, application shutdown and infrastructure sequence.
Asset scanning, packing, transport, receipt and rack installation.
Power, patching, configuration and routing activation.
Named technical tests and business transactions.
Rollback decision points and stakeholder communications.
Rehearse the runbook with IT, facilities, application owners, carriers and the relocation team. Ask what happens if a circuit fails, a device does not boot or transport is delayed. TNS Comms’ engineers can help validate whether the physical timings, lifting plan, patching order and resources are realistic before the maintenance window begins.
Control the Physical Move
Network appliances and servers are sensitive, heavy and may contain regulated data.
Track serial numbers and custody from removal through receipt.
Use approved asset lists, suitable packaging, specialist lifting where needed, secure vehicles and authorised personnel. Control storage media separately and reconcile equipment at the destination.
Legacy equipment deserves particular attention. Review disk health, batteries, fans and power supplies before deciding to move a device that may not survive power cycling. TNS Comms can advise on handling requirements and whether replacement or pre-staging is safer than a direct lift and shift.
Validate Services Before Declaring Success
Green link lights do not prove the relocation is complete. Test from user sites, remote offices, cloud networks, the internet and third-party paths where applicable. Confirm that users can authenticate, complete critical transactions and receive expected performance.
Validate:
Switching, routing, VLANs, gateways and link aggregation.
Firewall, NAT, VPN and load-balancer policy.
DNS, DHCP, NTP, identity, logging and monitoring.
Application transactions, data integrity and integrations.
Backup, replication and a post-move restore sample.
A/B power, network and carrier failover.
Out-of-band management and environmental alarms.
Retain the team for an agreed hypercare period and watch for optic errors, stale DNS, asymmetric routing, certificate issues and backup failures. Update rack elevations, port schedules, asset records and diagrams before final sign-off.
Ask TNS Comms for Data Centre Relocation Advice
Early specialist advice can expose physical risks before they become cutover problems. TNS Comms supports data centre relocations and modifications across the UK and Europe, including surveys, new suite infrastructure, cabinets, copper and fibre cabling, network-hardware moves, patching, audits and network upgrades.
Whether you need full relocation support or practical advice on one part of the move,
TNS Comms can help you:
Audit the existing physical network and identify gaps in the records.
Plan cabinet layouts, cabling, fibre routes and patch schedules.
Prepare and test the destination before equipment moves.
Coordinate trained engineers, lifting and physical hardware handling.
Support out-of-hours cutover, patching and network changes.
Produce test evidence and documentation for handover.
Get Advice Before the Cutover Window Is Fixed
The best time to find an undocumented link, incompatible power connector or missing circuit is during the survey—not after shutdown. Involving TNS Comms early gives your team experienced advice on the physical infrastructure, sequencing and practical resources needed for a controlled move.
For our services, get in touch today:
Frequently Asked Questions
When should planning begin for a data centre relocation?
Start as soon as the destination and target date are being considered. Carrier circuits and infrastructure work can have long lead times. Early advice from TNS Comms can help identify survey, cabling, cabinet and hardware-handling requirements before the programme becomes time constrained.
How can downtime be reduced during the move?
Use verified dependency maps, pre-installed cabling, tested circuits, replication or parallel running where appropriate, and a rehearsed cutover runbook. Define measurable go/no-go gates and a time-bounded rollback decision.
What must be tested before equipment is moved?
Test destination power, cooling, copper and fibre links, carrier handoffs, routing, security policy and out-of-band access. Confirm the required optics, patch leads, rack hardware and spares are available and compatible.
Should equipment retain its existing IP addresses?
Not automatically. Retaining addresses can reduce application changes but may increase network complexity. Readdressing may support a cleaner design but requires coordinated DNS, firewall, NAT, monitoring and third-party changes.
Why use a specialist data centre relocation partner?
A specialist can audit the physical estate, prepare and test the destination, manage cabling and patching, provide suitable lifting and handling, support restricted cutover windows and deliver accurate records. This reduces the risk of physical problems delaying technical recovery.
Comments