Data Centre Migration and Relocation Security Guide: Moving Hardware, Circuits and Data Without Losing Control

A data centre move is the one time your servers, disks and backups leave locked halls, sit in vans and loading bays, and are handled by people who are not your staff. It is also the time when firewall rules are rebuilt in a hurry, temporary links bridge two sites, contractors get broad access and nobody is quite sure which inventory is current. This guide covers the security of physical data centre migrations and relocations: moving to a new owned site, into or between colocation providers, or consolidating rooms. It addresses hardware in transit, circuits and IP addressing, data replication, cutover and the exit of the old site. Moves into public cloud are covered by the Cloud Migration Security guide, and steady-state site controls by the Data Centre Security Guide.

Key takeaways

• Encrypt before anything moves: drives that leave the building encrypted, with keys held elsewhere, turn a lost box from a reportable breach into an equipment loss.
• Custody is a record, not a feeling: serial-level manifests, tamper-evident seals and signed hand-offs at every stage are how you prove nothing went missing.
• Network moves create quiet exposure: temporary inter-site links, rebuilt firewall rules and re-announced IP prefixes are where unintended access and route hijacks appear.
• Migration access must expire: contractor accounts, temporary admin rights and replication credentials created for the move are removed on a fixed date.
• The old site is still a risk until it is empty: sanitise or retrieve every disk, cancel circuits and access badges, and get a signed exit inspection.

Choosing a migration method

The method decides where the security risk sits. Most programmes mix methods by application group.

Decision guidance: replicate data where bandwidth allows and move only empty or encrypted hardware. A physical move of unencrypted disks should be the exception, approved by the data owner with a recorded risk acceptance. Smaller organisations moving one server room can often rebuild at the target and ship nothing sensitive; large estates usually need all five methods and a programme-level security lead.

Plan and inventory: what you are moving

1. Reconcile inventories: compare the CMDB, DCIM, virtualisation and backup inventories with a physical audit of every rack. Record serial numbers of chassis and every removable drive. See the Asset Inventory and CMDB Security Guide.
2. Classify by data: tag each device with the highest classification of data it holds, including drives in arrays and spares on shelves.
3. Map dependencies: list network flows, authentication dependencies (domain controllers, PKI, HSMs, key managers) and external circuits for each application group. Security infrastructure moves first or is duplicated, so applications are never stranded without directory, logging or key services.
4. Set the encryption status: for every device record whether data at rest is encrypted, by what method, and where the keys live. Devices whose keys travel in the same vehicle are effectively unencrypted.
5. Define the move groups and freeze: agree change freezes, the order of moves and the go or no-go criteria, including security criteria such as "logging confirmed at target".

Hardware in transit and chain of custody

NIST SP 800-53 Rev. 5 covers this ground in MP-5 Media Transport, PE-16 Delivery and Removal and PE-20 Asset Monitoring and Tracking. In practice:

• Manifest: a serial-level manifest per vehicle and per crate, generated from the reconciled inventory, signed at departure and arrival.
• Seals: numbered tamper-evident seals on cases, rack doors and vehicle doors, with numbers recorded on the manifest and checked on arrival.
• Escort and route: two-person rule for high-classification loads, direct routes, no overnight stops, vehicle tracking, and a named contact at each end.
• Movers: use a specialist mover under contract with vetting, insurance, subcontracting limits and incident notification terms. Subcontracted couriers are where custody chains have broken in the past.
• Loading bays: staging areas at both sites are inside the access-controlled perimeter and covered by CCTV. Equipment does not sit in a public corridor waiting for a lift.
• Drives travel separately or not at all: for unencrypted systems, consider pulling drives and moving them as separate, sealed and escorted consignments, or replicating the data and moving empty chassis.
• Arrival check: count, scan serials, verify seals and record discrepancies before signing. A missing item starts the incident process the same day.

Use the Chain of Custody Form Template as a starting point for manifests.

Lesson from an incident: in 2011 US health insurer Health Net reported that its IT services provider could not locate nine server drives after servers were moved to a new data centre, affecting records of up to 1.9 million people. The public reporting did not confirm whether the drives were encrypted; either way, the custody record could not account for drives holding personal data. The fix is encryption before the move and serial-level custody, both on the customer side.

Circuits, IP addressing and routing

• Cross-connects and carriers: new circuits need letters of authorisation and cross-connect orders. Verify each order against the design so an unexpected port is not patched into your cage. See the MPLS and Carrier WAN Security Guide and the Dedicated Cloud Connectivity Security Guide for the links themselves.
• Prefix moves: if your IP prefixes move to a new upstream or a new origin AS, update Route Origin Authorizations (ROAs, RFC 9582) and IRR route objects before you announce from the new site, and remove old ones after cutover. A stale ROA either breaks reachability or leaves an authorisation an old provider could still use. See the BGP and Routing Security Guide.
• Temporary inter-site links: the link joining old and new sites during migration is often a flat layer 2 extension or a wide-open firewall rule. Encrypt it (MACsec or IPsec), filter it to migration flows and give it an end date in the change record.
• Firewall rule migration: translate rules from documented intent, not by copying everything. Rules carried over "to be safe" outlive the move by years. Review with the Firewall Rule Review Checklist.
• DNS and certificates: lower TTLs ahead of cutover, track every DNS change, and reissue or redeploy certificates and keys rather than copying private keys around on removable media.
• Management plane: build the out-of-band management network at the target before production arrives, so BMCs, PDUs and switches are never temporarily exposed on a production VLAN.

Data replication and keys

• Transport encryption: storage and VM replication traffic should be encrypted end to end or carried only over an encrypted link. Check the product setting rather than assuming.
• Replication credentials: replication and migration tools need privileged accounts on source and target (hypervisor, array, database). Create them for the migration, scope them to the systems in scope, store them in a vault and delete them at the end. See Credential Rotation at Scale.
• Key managers and HSMs: plan the move of external key managers and HSMs as its own workstream with the vendor's documented backup and restore or cluster-join procedure. Never ship a key backup with the encrypted data it protects. See the Cryptographic Key Management Guide.
• Integrity: verify replicated data with checksums or application-level reconciliation before decommissioning the source.
• Backups during the move: keep backup schedules and offsite copies running throughout; the move is a high-risk period for loss. Shipping backup media adds its own custody needs, covered in the Tape Backup Security Guide.

People and access during the move

Moves bring in movers, cablers, carrier engineers, vendor field engineers and temporary project staff, often with broad access. Treat migration access as a time-boxed privilege:

• Create named, time-limited accounts for each contractor; no shared "migration" logins.
• Grant site badges for the move window only, with escort rules for data halls.
• Route remote vendor access through a bastion with session recording.
• Record every temporary admin right, firewall rule and service account in a single migration access register with an expiry date, and review it weekly.
• Remove everything in the register at programme close, and rotate any credentials contractors saw.

These temporary service accounts and API keys are non-human identities that tend to be forgotten once the project team disbands. See the Non-Human Identity (NHI) Guide.

Cutover and rollback

1. Security go criteria: logging and EDR active at the target, vulnerability scan clean of new critical findings, firewall rules reviewed, backups running, monitoring dashboards showing the new site.
2. Cutover window: a named security contact on the bridge, with authority to stop the cutover.
3. Post-cutover checks: external attack surface scan of the new address space within 24 hours, review of any new internet-facing services, confirmation that old-site exposure is withdrawn.
4. Rollback: the old site stays intact and monitored until the rollback window closes. Do not sanitise source systems or cancel circuits until sign-off.

Exiting the old site

• Sanitise: every drive that stays, is sold, returned to a lessor or disposed of is sanitised to NIST SP 800-88 Rev. 2 (published September 2025), with verification and a certificate per serial. The UK NCSC notes that on encrypted devices a reset that deletes the keys is usually adequate for re-use, and recommends certified providers such as CAS-S or ADISA when outsourcing. See the Media Sanitisation Guide.
• Sweep: walk every rack, shelf, cage and store room for spare drives, tapes, labelled cables, network diagrams and password envelopes.
• Revoke: badges, keys, PINs, biometric enrolments, colocation portal accounts and API keys for the old site.
• Cancel: circuits, cross-connects, IP transit and any ROAs or DNS records pointing at the old site.
• Sign off: a joint exit inspection with the landlord or colocation provider, recorded with photographs.

Detection and measurement

What to monitor: manifest discrepancies and seal breaks, new internet-exposed services in target address space, route announcements for your prefixes from unexpected origins, logins by migration accounts outside the plan, and replication jobs that run after cutover.

• Percentage of drives moved physically that were encrypted with keys held separately (target 100%).
• Manifest reconciliation: items departed versus arrived, per move wave (target zero discrepancies).
• Migration access register items still active after programme close (target zero).
• Temporary firewall rules and links removed by their end date.
• Sanitisation certificates received versus drives left at or disposed from the old site.
• Time from cutover to first clean external scan of the new address space.

Common failure patterns

• Inventory drift: the move plan uses a CMDB that has not been reconciled, so drives in spare shelves and decommissioned-but-racked servers are never tracked.
• Keys in the same van: encrypted arrays shipped with their key backup or management appliance in the next crate.
• Subcontracted transport: the contracted mover hands part of the job to a courier, outside the custody terms.
• Permanent temporary rules: an any-to-any rule between sites added for replication is still there two years later.
• Forgotten migration accounts: replication service accounts with admin rights on both sites remain after the project closes.
• Old site left warm: circuits, badges and a few servers stay live "just in case", unmonitored and unpatched.

Notification if something goes missing

Treat a missing device holding personal data as a potential personal data breach from the moment it is discovered. Under the UK and EU GDPR Article 33, the controller notifies the supervisory authority without undue delay and, where feasible, not later than 72 hours after becoming aware of a personal data breach, unless it is unlikely to result in a risk to individuals. Article 34(3)(a) removes the duty to tell affected individuals where measures such as encryption render the data unintelligible to anyone not authorised to access it, which is the strongest argument for encrypting before the move. Other jurisdictions and sector rules have their own triggers; agree the decision path with legal before the first wave.

Framework mapping

Practitioner checklist

• Inventory reconciled physically with serials for every chassis and drive before the first wave.
• Every device classified, with encryption status and key location recorded.
• Keys and key backups move separately from encrypted data.
• Serial-level manifests, numbered seals and signed hand-offs for every consignment.
• Mover contract covers vetting, subcontracting limits and incident notification.
• ROAs, IRR objects and DNS updated in sequence with cutover; old entries removed.
• Temporary links encrypted and filtered, with end dates; firewall rules migrated by intent.
• Migration access register reviewed weekly and emptied at close; contractor-seen credentials rotated.
• Security go criteria agreed and a security contact on every cutover bridge.
• Old site sanitised, swept, revoked, cancelled and signed off.

Standards and references

• NIST: SP 800-88 Rev. 2, Guidelines for Media Sanitization
• NIST: SP 800-53 Rev. 5
• NCSC: Secure sanitisation of storage media
• EUR-Lex: Regulation (EU) 2016/679 (GDPR)
• IETF: RFC 9582, A Profile for Route Origin Authorizations
• NIST: Cybersecurity Framework 2.0
• Dark Reading: Health Net Breach Exposes 1.9 Million Records

Related NHI Mgmt Group resources: Data Centre Security Guide · Cloud Migration Security · Media Sanitisation Guide · Security Requirements for Selecting a Colocation or Data Centre Provider