What Your Colocation Migration Plan Gets Wrong About the First 72 Hours

Most colocation migration plans are thorough right up until the moment things start going sideways. You've got your rack diagrams, your cable labels, your change management tickets. You've done the pre-migration checklist three times. And then hour four of the cutover window arrives, and you're staring at a console that won't respond, your on-call engineer is unreachable, and the data center's remote hands team is telling you they need a work order before they can touch anything.

That's not a hardware problem. That's a planning problem — specifically, a failure to plan for the reality of what the first 72 hours of a colocation migration actually looks like versus what the Gantt chart said it would look like.

I've seen this pattern enough times that it's worth writing down. Not the theoretical checklist version, but the part that bites people.

---

The Cutover Window Is Not Your Biggest Risk. The 48 Hours After It Are.

Everyone spends their energy on the cutover itself. That's understandable — it's the dramatic part, the all-hands moment where you're actually moving traffic and crossing fingers. But the cutover window, if you've done your homework, is usually the most controlled part of the whole operation.

The 48 hours after cutover is where migrations actually fall apart.

Here's what typically happens: you complete the physical move, bring services online, run your smoke tests, and declare success. The team goes home (or to sleep, if you ran a weekend window). Then Monday morning hits. Real users, real traffic patterns, real application behavior under production load. And suddenly you're discovering that your monitoring didn't account for the new network path, your application servers are hitting a DNS TTL that hasn't expired yet, and your backup jobs are failing silently because the storage mount paths changed and nobody updated the scripts.

None of these are catastrophic individually. Together, at 8 AM on a Monday with a full ticket queue, they feel catastrophic.

The fix is to treat the 48 hours post-cutover as a distinct operational phase with its own runbook, not as "we're done, watch for alerts." That means dedicated coverage, pre-written escalation paths, and a list of the ten most likely failure modes specific to your application stack — not generic ones, your specific ones.

---

Remote Hands Access Is a Process, Not a Phone Call

This one surprises people who haven't done colocation before, and it surprises people who have done it at a different facility. Remote hands policies vary significantly between data centers, and assuming you can just call someone to swap a cable at 2 AM is a good way to have a very bad night.

Before your migration window opens, you need to know:

• What's the process for authorizing remote hands work? Is it a ticket, a phone call, a combination?
• Who on your team is authorized to make that request? Is it by name, by role, by a PIN or access code?
• What's the realistic response time for remote hands at 11 PM on a Saturday?
• What exactly can they do versus what requires a licensed engineer?

Some facilities are excellent at this. Some will tell you they need a 4-hour lead time on remote hands requests, which is not information you want to discover mid-cutover.

At IDACORE, we handle this differently because we're operators, not a managed services layer on top of someone else's facility. When you call, you're talking to someone who actually knows the infrastructure. That's not a pitch — it's just a meaningful operational difference when you're three hours into a cutover and need a straight answer about what's happening with a port.

Get the remote hands process documented before your migration window. Test it with a non-critical request a week out. Don't assume.

---

Your Network Assumptions Are Probably Wrong

This is the technical part that gets people, and it's worth being specific about.

When you migrate to a colocation facility, your traffic paths change. That seems obvious, but the second-order effects are where the surprises live.

Latency to your users changes. If you're moving from a hyperscaler region in Oregon to a local Idaho data center, your latency to Boise users likely drops significantly — we're talking sub-5ms versus 20-40ms from Oregon-based AWS or Azure regions. That's a good change, but it can expose timing assumptions baked into your application. Session timeouts, connection pool settings, and health check intervals that were tuned for 30ms round trips may behave differently at 4ms.

Your BGP announcements need time to propagate. If you're bringing your own IP space, expect 15-30 minutes for full global propagation after you start announcing from the new facility. If you're not bringing your own IP space, your DNS cutover is the critical path, and you need to have dropped TTLs to 60 seconds at least 24 hours before the migration window.

Firewall rules that reference source IPs will break. This one gets overlooked constantly. If any upstream service, SaaS vendor, or partner integration has your old IP addresses whitelisted, those connections will fail after cutover. Build a list of every external system that has an IP-based allowlist entry for your infrastructure. Contact them before the migration. Not during.

Here's a quick pre-migration network checklist that's actually useful:

Pre-Migration Network Checklist

[ ] DNS TTLs reduced to 60s at least 24 hours before window
[ ] BGP announcement timing confirmed with facility NOC
[ ] IP allowlist audit completed for all external integrations
[ ] New IP space tested with smoke traffic before cutover
[ ] Reverse DNS entries updated or queued
[ ] SSL certificates validated against new hostnames/IPs
[ ] Monitoring agents reconfigured for new network paths
[ ] NTP sources confirmed reachable from new environment
[ ] SMTP relay IPs updated with SPF/DKIM records
[ ] VPN tunnels re-established and tested end-to-end

Print that out. Go through it with your team the week before, not the night before.

---

The Rollback Plan Nobody Actually Has

Ask any engineer if they have a rollback plan. They'll say yes. Ask them to walk you through it in detail — the specific commands, the specific sequence, the specific person responsible for each step. That's where it gets quiet.

A real rollback plan for a colocation migration includes:

A hard decision point. At what hour into the cutover window do you stop trying to fix forward and start rolling back? This needs to be decided before the window, not during it, because during it everyone is tired and optimistic and convinced the next thing they try will work. Pick a time. Write it down. Stick to it.

A defined rollback owner. Not "the team." One person who has the authority to call the rollback and whose job it is to execute it. Everyone else supports them.

Tested rollback steps. If your rollback involves failing traffic back to your old environment, that environment needs to still be running and reachable. Don't decommission your old infrastructure until you've run in the new environment for at least two weeks and you're confident in the migration.

Communication templates. Who do you notify if you roll back? What do you tell them? Having a draft email or Slack message ready sounds like overkill until you're writing one at 3 AM.

The rollback plan isn't pessimism. It's what lets you make clear decisions under pressure instead of sunk-cost decisions at 4 AM.

---

What the First Week of Monitoring Actually Looks Like

Your existing monitoring dashboards are tuned for your old environment. After a colocation migration, you're flying partially blind until you rebuild that context.

Expect the first week to surface things like:

• Disk I/O patterns that look alarming but are actually just different hardware responding differently to the same workload
• Network throughput alerts that were calibrated for your old bandwidth constraints
• Application response time baselines that need to be re-established
• Log aggregation gaps from agents that didn't survive the migration cleanly

The right approach is to run your monitoring in "observe, don't alert" mode for the first 24-48 hours on non-critical thresholds, while keeping hard alerts active on the things that actually matter: service availability, error rates, and data integrity checks. Let the noise settle before you tune your thresholds.

Also: set up synthetic monitoring before the cutover. A simple external check hitting your critical endpoints every 60 seconds from outside your network gives you an objective view of availability that's independent of your internal monitoring stack. If your monitoring goes down too, you still know your services are up.

One concrete example: a healthcare SaaS company we worked with migrated their production environment to our Idaho data center and spent the first 18 hours chasing what looked like intermittent database connection failures. Turned out their connection pool timeout was set to 25ms — tuned for the latency characteristics of their previous environment. At 4ms round-trip latency, the pool was cycling connections faster than the application expected and creating a false error condition. Twenty minutes to diagnose, two minutes to fix. But only because someone on their team knew to look at latency-dependent configuration settings, not just the error logs.

That's the kind of thing you find in the first 72 hours. Plan to find things. Give yourself the coverage and the time to find them without panic.

---

If you're planning a colocation migration to an Idaho facility and want to talk through the network architecture before you commit to a cutover window, talk to our infrastructure team — we can walk you through exactly how BGP handoff, remote hands access, and IP space management work at our Weiser facility, with straight answers and no sales process attached.