A public agency reaches this question from one of two directions. Either the server room is a problem, because it is full, or because it is a converted office with a domestic air conditioner and a building manager who wants the space back. Or somebody has proposed moving everything to public cloud and the answer came back that some of it cannot go.
Colocation is the option in the middle, and it is the one people know least about.
What colocation actually is
Colocation is renting space, power and cooling in somebody else's building for computing equipment that remains yours. You buy the servers. You own them, you configure them, you patch them, and you decide when they are replaced. What you are renting is the room they sit in and everything that keeps that room fit for them.
The unit of rent is the rack unit, written U. One rack unit is a slot in a standard equipment rack, a little under two inches tall. A typical single server occupies one or two. A rack holds roughly forty. So a requirement expressed as "four U" means four slots, and an agency consolidating a small server room usually needs somewhere between two and ten.
Each unit comes with power and with a share of network capacity, and the contract states how much. Beyond that the arrangement is deliberately plain: the facility provides the conditions, and you provide the computers.
What you get, and what stays yours
What the facility supplies is the part that is expensive to build and dull to run. Conditioned power with redundancy behind it, so a utility failure does not become your failure. Cooling sized for equipment rather than for people. Physical access control. And staff on site continuously, which is the part agencies underestimate: a person who can look at a machine at three in the morning is worth more than most of the equipment in the rack.
Connectivity is usually the deciding feature. A carrier-neutral facility is one where more than one network provider is present and you choose which to buy from. That matters because it keeps a commercial decision in your hands that would otherwise be made for you, and because it is what lets you change provider later without moving the equipment.
What stays yours is everything above the rack rail. The operating systems, the applications, the data, the backups, the licensing and the decision about when any of it changes. Nobody at the facility patches your servers unless you have separately bought that as a service. This is the single most common misunderstanding, and it is worth being blunt about: colocation is a landlord relationship, not a managed service. If you want somebody else to run the machines, that is a different purchase, and it can sit alongside this one.
What colocation is not
It is not cloud. The definition of cloud computing published by NIST turns on characteristics colocation does not have: on-demand self-service, rapid elasticity, measured service. Rack space does none of that. You cannot double your capacity at lunchtime and halve it in the evening, because capacity is a physical object you bought. The distinction is not pedantry; it decides whether a workload with unpredictable demand belongs there at all.
It is not dedicated hosting either, though the two are often sold side by side and are easy to confuse. With dedicated hosting the provider owns the server and rents it to you as a monthly line item, so replacement, warranty and hardware failure are their problem. With colocation the machine is yours and so are all three. The trade is capital against control: hosting removes an asset from your books, colocation keeps it under your governance.
And it is not a backup strategy. Putting equipment in a professionally run building reduces the chance of a power or cooling event taking it out. It does nothing about deletion, corruption, ransomware or a mistake. Those need copies somewhere else, and the fact that the room is well run has no bearing on it.
Who actually needs it
Four situations account for most public sector colocation, and it is worth checking whether yours is one of them before going further.
The building is the problem. The equipment is fine and the room is not: no redundant power, cooling that was never designed for the load, a door that does not lock properly, or a lease ending. Moving the same equipment to a facility built for it solves the whole problem without touching a single application.
Something genuinely cannot move to public cloud. A licensing model that does not permit it, an appliance with a hardware key, a system whose vendor supports only on-premise deployment, or a dataset with a residency condition attached to it. Colocation gives that workload a proper home while the rest of the estate goes wherever it should.
The capital is already spent. An agency that bought servers two years ago has years of useful life left in them. Re-platforming into a subscription discards that value. Housing them properly preserves it and defers the decision to a point where the hardware is due for replacement anyway.
Recovery needs a second site. A continuity plan that names one building is not a plan. A rack in a different city, holding a copy and enough compute to run the systems that must not stop, is one of the cheaper ways to make it real.
Against that, colocation is the wrong answer where demand is genuinely unpredictable, where the application was written to be elastic, or where nobody on staff can administer a server. In that last case you are not looking for space, you are looking for somebody to run things, and you should buy that instead.
What it changes for your team
The day to day change is smaller than people expect and lands in two places.
You stop being a facilities operator. Nobody on your staff is responsible for a cooling unit, a battery, a generator test or a door contact any more. For a small team that is a genuine recovery of attention, because those tasks arrive unpredictably and always at the worst moment.
You start scheduling physical work. Swapping a disk is no longer a walk down the corridor. It is either a drive, or an instruction to somebody on site, and both need a little notice. Teams that adapt well write down in advance who is authorized to give that instruction and what they are allowed to authorize. Teams that adapt badly discover the question during an outage.
What does not change is everything above the hardware. Patching, monitoring, backup verification and capacity planning remain exactly as they were, and any expectation that moving the equipment improves them is misplaced. It improves the conditions the equipment runs in, which is a real benefit and a narrow one.
One further change is worth anticipating because it is cultural rather than technical. Equipment in a rack somewhere else stops being visible, and things that are not visible stop being thought about. Agencies that run this well keep a standing item somewhere, quarterly is enough, that asks what is in the rack, whether it is still needed and whether anything in it is approaching end of life. Out of sight is exactly how a forgotten server survives three budget cycles.
Getting out again
The question worth asking before signing is how the arrangement ends, because it is the question nobody asks while enthusiastic. Three answers matter: the notice period, what happens to your equipment at the end of it, and how your data is handled on any media that stays behind. A provider who answers all three plainly is telling you something useful about how they operate. A provider who has not thought about it is telling you something too.
Where this sits in a purchase
Colocation is bought as a monthly recurring service, by the rack unit, usually alongside a one-off piece of professional work to move the equipment in. Public agencies can buy both through an awarded cooperative contract rather than running a separate solicitation for either. What a cooperative contract is, and what it does not settle, is set out in the guide to TIPS cooperative purchasing.
LABUSA operates a carrier-neutral facility in Houston with a network operations center staffed continuously, and its operations are covered by SSAE 18 SOC 1 and SOC 2 reporting, which is the document a procurement officer should ask any provider for. Service commitments for hosted infrastructure are published in the service level agreement. The awarded vehicle is TIPS Contract 260302, and what it covers, along with the published monthly ceilings, is set out on the contract LABUSA provides colocation under.
If you are weighing a room you already have against a rack you would rent, send us what you are running and where it sits today.