A risk register for a data center relocation is a live list of the failures most likely to hurt the move, each with one owner, a trigger, and a response agreed in advance. Most projects keep one because a template says they should; it gets filled in at kickoff, reviewed once, and forgotten until something on it happens.
A register that works is a short, live document with owners who check it. Its value is not in listing every conceivable failure. It is in making sure the likely and expensive ones have a named person, a trigger that tells them the risk is materializing, and a response agreed in advance.
What Does Each Risk Register Entry Need?
Each risk needs a clear statement written as a cause and a consequence. "Circuits" is not a risk. "The carrier misses the circuit delivery date, so the destination has no WAN connectivity for move event one" is a risk, because it names what fails and what it affects.
Beyond the statement, every entry should carry the same fields:
- Likelihood and impact, each scored on a simple scale
- An owner: one person, not a team
- A trigger condition that signals the risk is becoming real
- A mitigation that reduces likelihood or impact now
- A contingency to execute if the trigger fires
- A status and date of last review
Keep scoring simple. A three- or five-point scale for likelihood and impact, like the qualitative scales in NIST SP 800-30, is enough. Multiplying them to produce a single score helps with sorting, but the scores are judgments, not measurements, and false precision invites arguments that do not change the plan.
Why Do Triggers Make the Register Useful?
The trigger is the field most registers leave blank, and it is the one that turns a list of worries into something actionable.
A trigger is an observable condition with a date attached. "Carrier has not confirmed a firm order commit date by six weeks before move event one." "Destination power circuits not inspected by T-21." "More than two application owners have not signed off test plans by T-14." Each of these is checkable in a status meeting with a yes or no, and each tells the owner exactly when to stop mitigating and start executing the contingency.
Without triggers, risks are discussed rather than managed. The team notices the circuit is late, agrees it is concerning, and schedules a follow-up. A trigger removes the discussion: the date passed, the contingency starts.
Which Risks Appear on Nearly Every Move?
Drive failures on power-up, hardware-bound licenses, carrier circuit delays, and elevator or dock outages. Every environment has its own risks, but these appear on nearly every move.
Drives failing on power-up
Disks that have spun continuously for years can fail when powered down, cooled, transported, and restarted. Older arrays and servers with spinning media are most exposed. Mitigation includes your IT team confirming recoverable copies of the data and RAID health before shutdown, and holding spare drives on site. The contingency is the replacement and rebuild procedure, with an estimate of how long a rebuild extends the window. Sequencing matters here too; shutdown and power-on sequencing covers the order that limits the damage.
Licenses tied to hardware identifiers
Some software licenses bind to a MAC address, a host ID, or a hardware fingerprint. A move that changes network cards, hypervisor hosts, or virtual MAC assignments can invalidate them at the moment the application tries to start. Mitigation is identifying these applications during discovery and obtaining re-host procedures or temporary keys from vendors in advance. Vendor response times belong in the trigger.
Carrier circuit delays
Circuit provisioning runs on the carrier's schedule, and delivery dates move. Mitigation is ordering early and escalating through the account team. Contingencies include temporary connectivity, a later cutover for dependent systems, or re-sequencing move events so the circuit-dependent group moves last.
Elevator or dock outage
A freight elevator out of service on move night, whether from a fault or a scheduled ASME A17.1 safety inspection, can stop the entire event. Mitigation is confirming building access in writing, scheduling elevator maintenance around the move, and knowing whether a second route exists. The contingency may be rigging, a reduced scope, or a postponement decision made before the trucks are loaded.
Other entries worth considering include key staff unavailability, destination cooling not commissioned, vendor support contracts not transferred, and change freeze conflicts with the business calendar.
Who Owns Each Risk, and How Often Is It Reviewed?
Every risk needs a single owner who has the authority to execute the contingency, or a direct line to someone who does. Assigning risks to "the network team" guarantees that everyone assumes someone else is watching.
Review the register on a fixed cadence. Weekly works through most of the project; daily in the final two weeks before a move event. Reviews should be short: check each trigger, update status, close retired risks, add new ones. A register that takes an hour to review is too long and will stop being reviewed.
Keep it next to the plan, not in a separate tool. Many teams run the register as a tab in the migration workbook so risks sit beside the inventory, move groups, and schedule they relate to.
Feeding the Register Into the Plan
The register should change the plan, not just describe it. A high-likelihood, high-impact risk with no workable contingency is a signal to redesign: split a move group, add a rehearsal, move a date, or change the method.
This is where migration planning strategy and risk management meet. Decisions about sequencing, phasing, and outage windows are largely decisions about which risks to accept.
For teams running a move for the first time, it helps to start the register during discovery rather than after the plan is drafted. The earliest risks, such as incomplete inventory, unknown dependencies, and long-lead procurement, are the ones that shape everything that follows, and they are cheapest to address while the plan is still flexible. Specialists in planning a data center relocation will usually bring a starter register from previous moves; treat it as a draft and make every entry specific to your environment before relying on it.