A surprising number of mid-sized companies run production workloads out of a converted closet. There is a rack, a wall-mounted air conditioner that was added after the first heat-related outage, a single internet circuit, a consumer UPS that has never been load-tested, and a door that stays propped open in July. The mop bucket lives in there too.
Nobody planned this. It accreted. And it usually works — right up until the moment it does not, which tends to be a holiday weekend, a storm, or the afternoon the building's power gets cut for maintenance nobody told IT about.
Colocation moves that equipment into a facility built for it. But the facility is only half of what makes it worthwhile. The other half is who manages what is inside the rack, and that distinction is where most of the value — and most of the disappointment — actually lives.
What a data center gives you that a closet cannot
These are not luxuries. They are the baseline assumptions your business already makes about its systems, whether or not anything currently guarantees them.
| Capability | What it means |
|---|---|
| Redundant power | Utility feeds, UPS capacity that is actually load-tested, and generators with a fuel contract. Power events become non-events. |
| Purpose-built cooling | Redundant units sized for the load. A single failed compressor does not become a thermal shutdown. |
| Carrier diversity | Multiple providers entering the building by separate paths. One cut fiber does not take you offline. |
| Physical security | Controlled access, logged entry, cameras, and a documented visitor process — often the fastest way to close an audit finding. |
| Fire detection and suppression | Systems designed for electronics rather than a sprinkler head above your storage array. |
| Staffed around the clock | Someone is physically present when something needs a set of eyes at 3am. |
| Environmental monitoring | Temperature, humidity and power draw watched continuously and alerted on. |
Building the equivalent yourself means construction, generators, redundant HVAC, access control and ongoing maintenance — for a room that produces no revenue. Colocation converts that capital project into a predictable monthly cost, and spreads the cost of the infrastructure across every tenant in the building.
One honest caveat: colocation is not automatically cheaper than a closet on a line-item basis. It is cheaper than building the same resilience yourself, and the comparison most companies make is against a closet that provides none of it. Compare like with like, including the outages you have absorbed.
This is not an argument against cloud
Public cloud is the right home for a great deal of workload, and we will say so when it is. But there remain sound reasons to keep owning hardware:
- Steady, predictable load. Cloud economics favor variable demand. A workload that runs flat all year is often cheaper on owned hardware.
- Licensing. Some vendor licensing is punitive in public cloud and reasonable on dedicated hardware.
- Legacy systems. Applications that cannot be re-platformed without a project you have no appetite for still need somewhere dependable to live.
- Data residency and control. Knowing exactly which machine your data sits on, in a facility you can walk into, still matters in some regulatory conversations.
- Cost predictability. A fixed monthly figure is easier to budget than a consumption bill that moves with usage.
In practice most environments end up hybrid. The useful question is not cloud versus colocation — it is which workload belongs where, and why.
The gap: a landlord is not a partner
Here is where colocation frequently disappoints. You have moved your equipment into an excellent building, and you now have a landlord.
The facility guarantees power, cooling and connectivity to the rack. Everything inside the rack is still yours: patching, monitoring, backups, firmware, capacity, hardware failure, lifecycle planning. "Remote hands" exists, but it is metered, reactive, and staffed by people who know the building rather than your environment. They will reboot what you tell them to reboot.
And your equipment is now an hour away. The 2am drive you were trying to eliminate has become a longer drive.
When hosting and management sit with different vendors, every ambiguous incident starts with the two of them establishing whose problem it is. That conversation happens while you are down.
What changes when one partner does both
This is the case for a partner who hosts your infrastructure and manages it.
One accountable party
No seam to fall through. Whether the fault is power, network, hypervisor, operating system or application, the same organization owns finding it and fixing it. There is nobody to point at.
Hands that already understand your environment
The people responding are the people who designed the architecture, monitor it daily and know why it was built the way it was. That context is the difference between a fast resolution and a long one.
Monitoring that informs planning
Capacity and lifecycle decisions come from observed data — actual utilization, actual growth, actual hardware age — rather than from a spreadsheet updated once a year at budget time. That is how you right-size instead of over-provisioning.
Continuity designed in, not bolted on
Backup, replication, failover and recovery objectives get designed alongside the hosting architecture. When the same partner owns the facility relationship and the systems, disaster recovery is a plan that has been tested rather than a document that exists.
Your team stops doing facility work
No driving out to reseat a drive, no waiting for a delivery, no racking, no scheduling downtime around a building's power maintenance. Whatever internal IT you have goes back to work that has something to do with your business.
What to ask any hosting partner
| Question | Why it matters |
|---|---|
| Is the SLA response or resolution? | The two are entirely different commitments. Most agreements promise the first while implying the second. |
| What exactly is managed, and what is still ours? | The boundary must be written down. Ambiguity here produces work both parties assume the other is doing. |
| How is remote hands billed? | Included, or metered by the quarter hour? It shapes behavior more than people expect. |
| When was the generator last load-tested? | A generator that has never run under load is a hypothesis. |
| How often are restores tested, and can we see results? | Backups running is not the same as backups working. |
| Who can authorize physical access, and how is it logged? | You are trusting a building with your systems. The process should be documented and auditable. |
| What does leaving look like? | Data return, documentation, notice, and de-racking. Ask at the start, while everyone is friendly. |
How XOR Services approaches it
Hosting runs through the same CADD methodology as everything else we deliver.
We start by assessing your actual workloads, growth plans and compliance requirements — because over-provisioned hosting wastes budget every month, and under-provisioned hosting causes the outages you moved to avoid. You then review and sign off on the hosting architecture, including capacity, redundancy and security controls, before a single server moves. Migration is executed against that signed design, and we validate performance, failover and security against the criteria in it rather than declaring success once everything powers on.
You keep the documentation — architecture, configurations, dependencies, recovery procedures — throughout, not as something negotiated on the way out.
And consistent with how we work everywhere else: if your workloads genuinely belong in public cloud, or your current arrangement is serving you adequately, that is what we will tell you. Selling capacity somebody does not need is the opposite of what Integrity by Comparison is supposed to mean.
If your production systems are living somewhere you would rather they were not, or you are weighing colocation against cloud and want a straight read, get in touch — or read more about our data center hosting and colocation work.