What Nobody Tells You About Physical Hardware Access During a Colocation Migration

Moving servers is a solved problem on paper. You've got the network diagram, the IP plan, the cutover window, and a spreadsheet tracking every piece of hardware. You've done the pre-migration checklist three times. And then you show up at the data center at 11 PM on a Tuesday and discover the remote hands team has no idea what a DRAC card is, the cage is locked and the person with the key is in another state, and your "four-hour migration window" is now a twelve-hour incident.

This happens more than anyone admits. The technical planning for colocation migrations is usually solid. It's the physical layer — the actual hands-on-hardware reality of moving equipment into a facility — where migrations quietly fall apart. Nobody writes about this part because it's unglamorous and because data centers don't exactly advertise their operational friction. But if you're planning a colo migration, especially moving out of a hyperscaler environment or an existing facility that's failed you, this is the stuff that determines whether your cutover is clean or catastrophic.

The Access Model You Think You're Getting vs. The One You Actually Get

Most colocation providers sell you on "24/7 access." What that means in practice varies wildly. At some facilities, 24/7 access means you can badge in anytime. At others, it means you can call a number and someone will let you in within a two-hour window — and that's considered acceptable by their SLA.

When you're mid-migration and a server won't POST because a DIMM seated wrong in transit, two hours isn't 24/7 access. It's a delay that blows your maintenance window and forces you to either roll back or go live on degraded hardware.

Before you sign a colocation agreement, ask these specific questions:

• What is the actual response time for after-hours physical access, not the SLA language, but the real number?
• Is there an on-site technician during off-hours, or is it a security guard who calls someone?
• What can remote hands actually do? Can they reseat RAM? Reset IPMI? Run a console cable? Or are they limited to power cycling and cable tracing?
• What's the process if you need emergency access outside your scheduled window?

The answers will tell you more about operational reality than any marketing sheet.

Shipping Hardware to a Colo Facility Is Not Like Shipping Anything Else

Your servers are going to arrive at the facility before you do. That's almost always true. The logistics of a migration mean equipment ships days or weeks ahead of the actual cutover, and it sits in receiving until you're ready to rack it.

Here's what goes wrong in that window. Equipment gets received by staff who aren't technical and isn't logged with enough specificity to be useful. Boxes get stacked in ways that violate handling instructions. A 2U server with "THIS SIDE UP" on the box ends up on its side for a week because the receiving dock is full. Rail kits get separated from the servers they belong to and filed in a different location. You show up to rack your equipment and spend ninety minutes finding all the pieces.

The fix is operational, not technical. Label everything with your cage/cabinet number, your company name, and a sequential item number that matches a manifest you carry with you. Don't rely on the facility's receiving system to track your equipment accurately — verify it yourself when you arrive. If you're shipping more than ten items, consider sending someone to the facility to receive the shipment in person.

Also: ship your rail kits separately from your servers, in clearly labeled boxes, and bring spares for at least two of your most common server form factors. Rail kits get lost. It happens on nearly every large migration.

The Console Access Problem Nobody Plans For

You've got IPMI. You've got iDRAC or iLO. You've got out-of-band management. You're fine.

Until you're not. IPMI misconfiguration is one of the most common issues that surfaces during a migration, specifically because servers often get their out-of-band management interfaces configured for the old network and nobody updates them before the move. You rack the server, power it on, and you can't reach iDRAC because it's still trying to pull an IP from the old facility's DHCP scope that no longer exists.

Now you need a console cable. Do you have one? Does the remote hands team have one that works with your hardware? Is there a crash cart in the facility and is it actually functional?

Before any migration, run through this checklist on every server that's moving:

# Verify IPMI/iDRAC/iLO is configured for the destination network
ipmitool lan print 1

# Confirm the IP, subnet, gateway, and VLAN are set correctly
# for the destination facility BEFORE the server ships

ipmitool lan set 1 ipaddr <destination_ip>
ipmitool lan set 1 netmask <destination_mask>
ipmitool lan set 1 defgw ipaddr <destination_gateway>

Do this before the server leaves your hands. Not after it's racked. The thirty minutes you spend on pre-migration IPMI verification will save you hours of console cable debugging at 2 AM.

What a Real Cutover Window Looks Like

Here's a scenario that's closer to reality than most migration guides acknowledge.

A regional healthcare company — about 40 employees, running a mix of physical servers and a handful of VMs — decided to move out of a shared hosting environment into colocation. Their plan called for a Saturday night cutover starting at midnight, with a target of being live on the new infrastructure by 6 AM before Monday business hours.

Equipment arrived Friday. Saturday morning, they showed up to rack everything. Three problems surfaced immediately: two servers had loose drive trays from shipping, one rail kit was missing entirely, and the fiber patch panel in their cabinet had been pre-wired by the facility in a configuration that didn't match their diagram.

The drive trays took twenty minutes. The rail kit required borrowing one from another cabinet in the facility (with permission) and improvising a mount. The fiber took ninety minutes of working with the on-site tech to re-trace and re-patch.

They went live at 8:30 AM Sunday. Not catastrophic, but two and a half hours over window. The difference between that outcome and a full rollback was having an on-site technician who actually understood fiber plant and was willing to work through the problem instead of logging a ticket.

That's not a story about bad planning. It's a story about physical reality. Hardware moves, things shift, pre-wired infrastructure doesn't match diagrams. The variable that determined the outcome was access to a competent human being at the facility who could engage with the problem directly.

The Facility Relationship Is an Operational Asset

This is the part that gets treated as soft and therefore gets ignored in technical planning. The relationship you have with the people who operate your colocation facility is a direct input to your operational reliability.

When you're at a large carrier-neutral facility with thousands of customers, you're a ticket number. Your migration is one of dozens happening that month. The remote hands team is competent but stretched, and their escalation path for anything non-standard runs through a queue.

When you're at a smaller operator-run facility where the people answering the phone are the same people who built and maintain the infrastructure, the dynamic is completely different. You can call and say "I've got a server that won't POST, I think it's a memory issue, can someone pull the DIMM in slot A2 and reseat it?" and get a yes instead of a "we'll need to open a remote hands ticket for that."

We've been running infrastructure since before most cloud providers existed — we ran an ISP with our own ASN and BGP peering at the Seattle Internet Exchange. When a customer calls us about a migration issue, they're talking to someone who has physically racked thousands of servers and troubleshot more weird hardware failures than they can count. That's not a customer service philosophy. It's just what it looks like when the people operating the facility are actual infrastructure engineers.

Building Your Migration Plan Around Physical Reality

The technical migration plan — IP assignments, DNS TTLs, BGP announcements, failover sequences — is the part engineers are good at. Build that plan. Test it. But add a physical layer to it that accounts for the realities above.

Your physical migration checklist should include:

• Pre-migration IPMI/iDRAC/iLO reconfiguration on every server
• Equipment manifest with cage/cabinet/item number on every box
• Personal receipt of equipment at the destination facility, or a trusted contact on-site
• Spare rail kits for your two most common server form factors
• Console cables and a USB-to-serial adapter in your kit bag
• Confirmed remote hands capabilities at the facility before you arrive
• A direct phone number for someone at the facility who can make decisions, not just open tickets
• A rollback decision point with a specific time — if you're not live by X, you roll back, no debate

That last one matters more than people want to admit. Migrations that go sideways tend to go sideways because teams keep pushing forward past the point where rolling back is the right call. Set the decision point before you start. Stick to it.

---

If you're planning a colocation migration to an Idaho data center and want to talk through the physical access and operational realities before you commit to a facility, talk to someone who's actually done this — not a sales rep reading from a spec sheet.