A colocation migration — moving your equipment into a colocation facility, or from one colo provider to another — shares a logistics surface with a standard data center move but involves a distinct set of decisions, constraints, and coordination requirements that make it its own project type.
The difference shows up in the details: you are not just moving hardware, you are transitioning a commercial relationship, provisioning shared infrastructure you do not own, coordinating with a facility whose operations are not under your control, and maintaining service continuity across a network cutover that involves third-party carriers and cross-connects that take weeks to provision.
Phase 1: Facility Selection and Contract
The most consequential decisions in a colocation migration happen before any equipment moves. Getting the facility selection and contract right creates the conditions for a smooth migration. Getting it wrong creates constraints you will work around for the duration of the contract.
Evaluating the Facility
Beyond the standard Tier classification (I–IV) and uptime SLA, the evaluation criteria that matter for a migration project:
- Cross-connect ecosystem: Which carriers, cloud on-ramps, and network exchanges are available in the facility? Equinix IX, CoreSite One, and similar facilities provide direct access to major carriers and cloud providers. A facility without your preferred carriers means third-party circuits and additional latency.
- Power density: What is the per-rack power allowance, and can it support your equipment's actual draw? Modern compute-dense workloads frequently exceed the 5kW/rack default at many facilities. Confirm the facility's high-density capability before signing a contract that locks in inadequate power.
- Physical access policies: What are the escort requirements? What are the access hours? Some facilities require 24-hour advance notice for physical access, which directly affects your migration timeline and after-hours work options.
- Migration support services: Does the facility offer smart hands, remote hands, or staging space? Facilities that support migrations with on-site technical staff reduce the vendor coordination burden. Those that do not add cost and complexity.
- Network provisioning lead time: Cross-connects at most facilities take 2–4 weeks from order to activation. Diversity routes (for redundant connectivity) can take longer. This timeline dictates when you need to have contracts signed relative to your target migration date.
Contract Negotiation Points
Standard colocation contracts favor the provider. Items to negotiate before signing:
- Staged power commitment: If you are migrating in phases, negotiate power that scales with your footprint rather than committing to full capacity from day one.
- Migration period cross-connect credits: Many facilities will waive cross-connect fees during a defined migration window when both source and destination circuits are active. Ask.
- SLA remedies: Understand what the uptime SLA actually provides — service credits are not compensation for business losses caused by facility downtime. Know what you are and are not protected against.
- Termination rights: What are the exit provisions? A 5-year contract with no exit provisions is a long time to be locked to a facility that is not meeting your needs. Negotiate exit ramps tied to facility performance.
Phase 2: Network Architecture and Provisioning
Network provisioning is the long-lead item in any colocation migration. Most project timelines fail here because orders are placed too late.
Cross-Connect Ordering Timeline
Work backward from your target migration date:
- Day 0 (contract signed): Immediately initiate cross-connect orders for primary and diversity circuits. Do not wait until the physical migration is planned. The circuits need to be active before equipment arrives.
- Weeks 2–4: Standard cross-connect provisioning window at most major facilities. Confirm LOAs (Letters of Authorization) are submitted on both sides of each circuit.
- Week 4–6: Circuit testing and validation. IP routing confirmed, latency baselines established, monitoring configured.
- Week 6+: Equipment migration can begin with active network available.
IP Address Strategy
If you own your IP space (ARIN-registered), you can announce it from the new facility and maintain address continuity. If your current IP space is provider-assigned (from your current ISP or colo provider), you are renumbering — which requires:
- New IP block allocation from the destination provider or ARIN
- DNS updates for every service with an A/AAAA record
- Internal configuration changes for any application that references IP addresses directly
- External partner notification for any whitelisting or firewall rules maintained by clients or vendors
Renumbering is manageable but requires lead time. A 48-hour DNS TTL means it takes up to 48 hours for all DNS-based traffic to shift to new IPs after you update records. Reduce TTLs at least one week before migration.
BGP and Routing
For organizations running BGP with their own AS number, the destination facility needs to be added as a new BGP peer before migration begins. Traffic engineering during the migration — preferring the source facility while the destination validates, then shifting preference to destination — is a clean way to manage cutover without a hard DNS change.
Phase 3: Physical Migration Planning
Once network provisioning is underway, the physical migration plan can be finalized. Colocation-specific constraints that affect physical planning:
Facility Coordination Requirements
- Advance notice: Most colocation facilities require 24–72 hours advance notice for moves-adds-changes. For a migration event, coordinate with the facility's operations team directly — not just through the customer portal. Confirm freight elevator reservations, loading dock scheduling, and escort staffing for the duration of your move window.
- Cage and cabinet access: If you are migrating into a shared colocation environment (multi-tenant cage), confirm access protocols for the installation date. Badged access provisioning for your migration team needs to happen before they arrive on site.
- Weight and floor load restrictions: Colocation facilities are engineered for specific floor load ratings. Heavy equipment (large UPS units, dense storage arrays) may require confirmation that the cage location can support the weight. This is the facility's responsibility to specify — your responsibility to ask.
Sequencing the Physical Move
Colocation migrations typically run in equipment waves:
- Networking infrastructure first: Top-of-rack switches, core routing, and out-of-band management arrive before compute. This allows the network to be operational and validated before servers come online.
- Non-critical compute and storage: Dev, test, and low-criticality workloads that have been migrated (via replication or application-level migration) to temporary cloud or the new facility baseline. Moving these first builds team confidence and validates the install process.
- Production compute in waves: Application-by-application, validated at each step. Roll back is still possible at each stage until source decommission is approved.
- Power infrastructure last: UPS units, PDUs, and power conditioning equipment at the source are decommissioned after all compute has been validated at the destination.
Phase 4: Cutover and Validation
The cutover phase is where colocation migrations earn or lose their success rating. Specific items that make or break this phase:
The Cutover Window
Even for migrations designed to minimize downtime, define a cutover window — the period when the transition from source to destination is finalized — and communicate it to all stakeholders before equipment moves. The window needs:
- A defined start and end time, with stakeholder notification sent at least 48 hours in advance
- A rollback decision point — a time by which you either confirm cutover success or revert to source
- An on-call list covering every application team, network team, and vendor contact needed during the window
- A communication channel (Slack, Teams, or war room bridge) active throughout the window
Post-Cutover Validation Checklist
- All services responding on new IPs and DNS entries resolving correctly
- Latency baselines confirmed against pre-migration benchmarks
- Monitoring and alerting configured for the new environment (do not rely on source-environment monitoring during or after cutover)
- Backup and replication jobs running and completing successfully at the destination
- Security controls validated: firewall rules active, access logs generating, SIEM feeds connected
- Application smoke tests completed by application owners — not just infrastructure teams
Phase 5: Source Decommission
The source environment should remain intact and reachable until the post-cutover validation period is complete and stakeholders have signed off. Premature source decommission is one of the most common causes of post-migration incidents — the one application that did not make it into the validation checklist surfaces three days after you powered down the source.
Standard decommission sequence:
- Validation period: Minimum 72 hours of production traffic at the destination before source decommission begins. Higher-risk environments should extend this to 7–14 days.
- Data sanitization: Every storage-bearing device at the source location receives NIST 800-88-compliant sanitization before it leaves the facility. Certificates of destruction issued per device.
- Asset recovery: Equipment not being reused or transferred to the new facility is either sold, donated, or disposed of through an R2-certified ITAD vendor — not abandoned at the source colo.
- Contract termination: Colocation contracts typically require 30–90 days written notice for termination. Confirm the notice period in your contract and submit notice as soon as you are confident in the cutover — not after the validation period ends, or you pay an extra billing cycle.
Getting the Right Vendors for a Colocation Migration
A colocation migration requires vendors with specific experience: they need to understand facility coordination, not just logistics. General freight companies that have not worked in colocation environments will struggle with access requirements, equipment handling standards, and the precision timing that colo facility coordination demands.
Ask prospective vendors for references specifically from colocation migrations at named facilities. A vendor who has moved equipment into Equinix, CoreSite, or QTS understands the operational environment. A vendor who has only done office-to-office IT moves is learning on your project.
A vendor who has moved enterprise IT equipment across town is not automatically qualified to manage a colocation migration. The LOA process, cross-connect sequencing, cage buildout coordination, and facility-specific access requirements take experience doing it — not just capability in the abstract. PowerRoute matches colocation migration projects to providers with documented colo-specific history, so you are not explaining what an LOA is on equipment day.