Colocation scalability: growing from single rack to multi-rack and multi-site strategy

Posted on in

Colocation estates rarely stay static. As workloads grow and hardware refreshes push power density higher, what started as a single rack becomes a more complex question: is the rack genuinely full, or just poorly arranged? Is the next step more cabinets, higher density, or a second site? When does dense power justify the cost, and when is spreading the load the more practical answer?

Scaling colocation well involves a sequence of connected decisions, each one shaping what comes next. What you agree at single-rack stage affects how cleanly you move into multi-rack colocation. What you decide at the multi-rack stage shapes how quickly and safely a second site can follow.

When to move from a single rack to multi-rack colocation

A typical colocation rack carries somewhere between 3kW and 10kW per cabinet, though modern facilities can support significantly higher densities depending on cooling infrastructure. Start by checking the “maximum power draw” or “power allocation per cabinet” clause in your agreement.

Watch for outlet utilisation above 75%, recurring hot-spot alerts from in-row cooling sensors, or deployment delays caused by lack of rack space. If equipment is waiting to be installed because the rack has nowhere sensible to take it, the capacity issue has already arrived.

Smart PDU dashboards, your provider’s customer portal, or lightweight DCIM tools such as Device42 or Nlyte can track utilisation over time. The trend matters more than one busy week.

At some provider facilities, adding another rack can take two to six weeks. Moving to a new facility can vary significantly depending on availability, from a matter of days if space is ready, to several months if new infrastructure is required. The difference often depends on whether electrical capacity is already available in the location or row, whether a new contract is required, and whether the provider needs to make physical changes before deployment.

Cooling can become the limiting factor before power does. As workloads grow and hardware density increases, power draw per rack can climb quickly, and cooling capacity may become the constraint before you run out of physical rack space.

As a broad planning guide: below 10kW, standard rack expansion will often be enough. Between 10kW and 30kW, high-density zones within your existing facility may need to be considered. Above 30kW, you are into more specialist builds, with materially higher per-kW costs.

Start planning the next rack when power use is consistently above 65%, not when it reaches 90%.

Single-rack to multi-rack migration: a practical strategy

Before adding cabinets, it’s advisable to audit power, space and connectivity every month for at least three months. Track peak and average kW draw per rack, used and available U-space, switch port utilisation, bandwidth peaks by time of day, and cross-connect utilisation on each link.

When requesting additional cabinets, ask for adjacent allocation. Cross-aisle or cross-row cabling may look manageable at first, but the operational complexity compounds as the estate grows. Where possible, look to reserve additional rack space at the original contract stage and negotiate a right of first refusal before you need it.

Apply structured cabling standards from the start. TIA-942 or EN 50173-5, the European equivalent, provide a useful framework. For multi-rack tenants, the key disciplines are consistent labelling, physical separation of power and data cable pathways, and a live cable schedule showing both ends of every connection.

Power delivery agreements also need attention when you move into multi-rack colocation. Confirm per-cabinet limits and aggregate capacity in writing. Check whether metering is per cabinet or across the full allocation, whether burst allowances are available, what overage penalties apply, and whether commitment terms are aligned across all cabinets.

Hardware refresh cycles should be in the model. Per-rack power draw has risen by around 15% to 25% per generation across the last three major server platform cycles, so plan for at least 20% to 30% headroom above current requirements over a three-year window. Secure the contractual allocation before you need it.

Carrier-neutral facilities give you access to multiple network providers. Cross-connect costs vary by provider and can exceed £300 per cable, with install fees also payable on top. At Datum, cross-connects are available from £35 per month per five cables. In a single-carrier facility, transit costs per Mbps are often higher and redundancy options narrower.

Colocation power density limits and growth planning

AI, HPC and other high-density workloads can demand up to 100kW per cabinet, well beyond what a standard cabinet is built to support. The facility’s cooling architecture is usually the binding constraint, not the rack itself.

Modern facilities with the latest generation air cooling can support up to 30kW per cabinet. Beyond that, you are likely to need liquid cooling, rear-door heat exchangers, or a purpose-built high-density zone.

When assessing cooling capability, ask the provider:

  • What is the maximum supported kW per cabinet in my row?
  • What cooling method is deployed: raised floor, in-row, rear-door, containment or another approach?
  • What is the process for requesting a higher power allocation, and what are the lead times and costs?

    • If your average density sits between 10kW and 20kW, spreading the load across multiple standard racks is often the more practical route.

    Also ask about the facility’s N+1 redundancy ratio across UPS and generators, and its current electrical capacity utilisation. If the site is already running above 80% electrical capacity, your ability to expand may be restricted even if empty rack space appears available.

    Multi-site colocation deployment: best practices

    Before choosing a second facility, define the job each site needs to do.

  • DR, or active-passive: can tolerate a lower tier rating, asynchronous replication and a lower-cost region. The main constraint is meeting the required RTO.
  • Active-active: needs closely matched power and cooling specifications, low-latency interconnects and comparable provider SLAs.
  • Overflow capacity: similar to DR, but focused on cost and fast provisioning for workload spikes.

    • If your RTO is under 15 minutes and the tolerance for data loss is close to zero, active-active is usually the default. If the RTO is measured in hours, a DR-only design may be enough and will generally be far less expensive.

    Standardise BGP policy, firewall ruleset baselines and monitoring tooling across every site. For smaller multi-site deployments without their own ASN, provider-managed routing or SD-WAN overlays can handle inter-site traffic without the overhead of running your own BGP configuration.

    Use a site-rack-unit naming convention, such as LON1-R04-U12, and keep a shared documentation repository available to every member of staff with site access. Test failover at least quarterly using a structured runbook covering pre-test checks, the failover process, validation of application availability, data integrity checks after failover, and a documented rollback procedure.

    Inter-datacentre connectivity for multi-site colocation

    Dimension Dark Fibre MPLS SD-WAN
    Latency Lowest, because you control the optical layer Low, with SLA-backed performance Variable, internet-dependent
    Cost High upfront, low per-bit at scale Medium-high, based on committed Mbps Lowest, using commodity internet
    Management complexity High, requiring optical expertise Low, carrier-managed Medium, with overlay management
    Best-fit use case Synchronous replication and high-throughput workloads SLA-critical traffic with moderate bandwidth General-purpose, cost-sensitive traffic

    One issue still catches experienced teams: connectivity resilience depends on diverse physical routes, not just diverse logical services. Two MPLS circuits from the same carrier may still share underlying infrastructure. One fibre cut can take out both. Confirm physical diversity in writing and ask for route maps.

    Some UK colocation facilities offer direct private connectivity into major cloud platforms via on-ramp services. For hybrid cloud architectures, these can make cloud interconnects simpler, more controlled and more secure.

    Geographic redundancy and disaster recovery

    For meaningful resilience, separate sites by at least 50km to 100km to reduce shared exposure to power grid issues and flood zones. Synchronous replication usually needs sub-5ms round-trip latency, achievable over dark fibre up to roughly 100km. Beyond 300km, asynchronous replication with an RPO of seconds to minutes is usually the more realistic baseline.

    Document that trade-off clearly. The business should formally accept the RPO for each critical workload, not discover it during an incident.

    A practical selection checklist for second and third facilities should include:

  • Minimum geographic separation, based on regulation and risk
  • Round-trip latency to the primary site, measured rather than estimated
  • Available dark fibre or MPLS routes between sites
  • Provider tier rating and available power
  • Carrier neutrality and network diversity
  • Jurisdictional and data residency compliance
  • Contract flexibility for future expansion

    • The Uptime Institute’s Tier III target is 99.982% availability, or less than 1.6 hours of downtime per year. Tier IV targets 99.995%. Availability figures above Tier IV appear in marketing, but they do not map to formal Uptime Institute tier definitions.

    UK financial services firms also need to consider the FCA’s operational resilience framework, Policy Statement PS21/3, in force since March 2025. It requires firms to set impact tolerances that inform DR architecture. In practice, this often drives multi-region deployments with sub-four-hour RTOs for critical services.

    Compliance, data residency and GDPR in multi-region colocation

    Data residency is a legal obligation. Treating it as a performance consideration is a compliance risk. If a multi-site architecture replicates personal data across jurisdictions, you need a legal basis under UK GDPR. UK organisations with EU customers must assess whether the design creates a restricted transfer. Active-active replication into a facility in a non-adequate country may require Standard Contractual Clauses or another approved transfer mechanism.

    Regulated sectors bring further requirements. Financial services firms operate under FCA operational resilience rules. Healthcare organisations need to align with the NHS Data Security and Protection Toolkit. Organisations serving US public sector or defence clients may need to map controls against NIST 800-53.

    Colocation providers with ISO 27001 and SOC 2 Type 2 certifications can provide independently audited evidence of operational controls and help reduce audit burden. They do not remove it. ISO 27001 covers the provider’s information security management system, not your own. Make sure the provider has an explicit data processing agreement that meets your regulatory requirements.

    Before deploying multi-region infrastructure, document the jurisdiction of each colocation site, the data types held there, and the transfer mechanism in a data flow map. Treat that map as a living document. Review it at every architecture change, because it is often one of the first things an auditor will ask to see.

    Scaling colocation with the right partner

    Growth rarely follows the neat path agreed at procurement. Power densities rise. Second-site requirements appear sooner than planned. A contract signed two years ago can start to constrain decisions your team needs to make now.

    Choosing a colocation partner is a long-term decision. The provider that works for a single rack needs to work equally well when you’re adding high-density zones, establishing inter-site connectivity, and building a DR model your internal stakeholders can scrutinise.

    Datum operates carrier-neutral data centres in London and Manchester, with both regions designed to support workloads from standard cabinets through to high-density AI and HPC deployments. Our in-house engineering and service management teams help clients work through the practical decisions that come with scaling: capacity planning, high-density provisioning, inter-site connectivity and disaster recovery design.

    If you are working through any of the choices covered in this article, talk to us about your growth roadmap, or explore our colocation services to see how Datum can support your deployment

    Back to Insights