Colocation vs On-Premises: What Actually Decides It
The decision between running equipment in your own building and placing it in a colocation facility is usually framed as a cost comparison. The costs are real but the constraints are what actually decide it, and they are frequently discovered rather than planned.
What your own building must provide
Five things, and running out of any one of them forces the decision.
Power capacity. Circuits, at the right type, with capacity for the load — and in a redundant design each path able to carry everything alone. Our PDU guide covers why this is the binding constraint more often than space.
Cooling. Adequate for the load, running continuously rather than on an office schedule, with a path for hot air to leave the room.
Physical space with proper access, floor loading and security.
Network connectivity of sufficient capacity and, where it matters, more than one route into the building.
Someone to attend when something needs hands.
Most organisations that move to colocation do so because one of the first two ran out, not because of a cost calculation.
What colocation gives you
Power and cooling designed for the purpose, with redundancy you would not build for one rack. Physical security with access logging. Multiple network routes. And someone in the building at all hours.
Two less obvious benefits. The environment is monitored and problems are noticed — a cooling failure on a Friday evening in your own comms room has until Monday to do damage, as our monitoring guide covers. And capacity is a purchasing decision rather than a building project.
What it costs you
Being direct about the downsides, because they are real.
Distance. Anything requiring hands means travelling or paying for remote hands. That changes how you think about spares, and it makes out-of-band access and remote power control close to mandatory rather than useful.
Recurring cost. On-premises capacity, once built, is largely sunk. Colocation is a monthly cost that continues.
Power billing changes behaviour. In your own building, an inefficient server costs electricity you may not attribute. In colocation you are billed for it, which makes efficiency a line item and can favour newer hardware. Our TCO guide covers this trade-off.
Rack space is metered. Density matters in a way it does not at home — a 4U server that is half empty is being paid for four times over.
What changes in how you operate
Four practical shifts that catch people after a move.
Spares strategy tightens. A failure that needed a walk downstairs now needs a journey or a courier. Holding spares at the facility, or arranging next-day delivery there, matters more than it did.
Rack security becomes yours. The building layers belong to the provider, and others are legitimately in the room. Locking racks stops being optional.
Documentation matters more. Someone else may need to follow it, and you cannot rely on knowing where things are. Our documentation guide covers labelling and conventions.
Remote hands has limits. Facility staff will reseat a cable or press a button; they are not going to diagnose. The clearer your labelling and instructions, the more useful they are.
The hybrid position
Most organisations end up split rather than choosing one, and that is usually correct rather than indecisive.
On premises: anything needing local access, equipment serving local users where a network outage would isolate them anyway, and workloads where latency to the local site matters.
Colocation: anything needing high availability, capacity that exceeds what the building can power or cool, and the disaster recovery environment — which is arguably the strongest case of all, since DR in the same building as production is not really DR.
That last point is worth stating plainly. If your recovery site is down the corridor, it does not survive a fire, a flood or a power event affecting the building.
Before deciding
Measure actual power draw rather than adding nameplate ratings — that number tells you how close your building is to its limit. Check whether cooling runs continuously and whether it was sized for what is in the room now. Establish what an outage costs per hour, which is what availability is worth. Confirm whether you have out-of-band access and remote power control, since colocation without them is expensive in travel. And count what it would take to move — our relocation guide covers why documentation rather than transport decides the outage length.
Common questions
What usually forces a move to colocation?
Power or cooling running out, rather than a cost calculation. Most buildings reach a circuit or cooling limit before they run out of space, and expanding either is a building project rather than a purchase.
What changes operationally after moving?
Spares need to be at the facility or deliverable there, rack locking becomes your responsibility since others are legitimately in the room, documentation matters more, and out-of-band access moves from useful to close to mandatory.
Does colocation change what hardware I should buy?
Somewhat. Power is billed directly, so efficiency becomes a line item, and rack space is metered, so a half-empty 4U chassis is being paid for four times over. Both can favour denser and newer equipment than an on-premises calculation would.
What can remote hands actually do?
Reseat a cable, press a button, swap a labelled component. They are not going to diagnose, so the clearer your labelling and written instructions, the more useful the service is.
Is a hybrid arrangement a compromise?
Usually the correct answer rather than indecision. Local access needs stay on premises; availability-critical workloads and disaster recovery go to colocation — and a recovery site down the corridor from production does not survive a building-level event.
Measure actual power draw before deciding — it tells you how close your building is to its limit, which is usually what forces the answer.
