A hosting or colocation purchase differs from most technology buying in one respect that catches people out: the thing being bought is a place, and the equipment has to physically get there. Everything awkward about the purchase follows from that.
This is what to settle before you ask for a quote, and what the move itself involves.
Before you ask anyone for a price
Four things determine the quote, and if you do not supply them the supplier will assume them.
How much space, expressed in rack units. Count the equipment you intend to move, in U, and then decide whether you are buying for that number or for growth. Buying exactly what fits today is a false economy if you know a project lands next year; buying a whole rack for four units of equipment is the opposite mistake. Include anything that must go with the servers: a switch, a firewall, a console, a backup appliance.
How much bandwidth, and to whom. Bandwidth is sold as an included allowance with an option to burst above it. What decides the number is not the size of your data but the shape of its movement: a nightly backup leaving the rack is a very different profile from steady user traffic arriving at it. If the facility is carrier neutral, decide separately whether you are buying transit through the provider or bringing your own.
Who has hands on the equipment. Somebody has to rack it, cable it, and be there when a disk fails. That is either your staff travelling, or the facility's staff acting on your instruction, and the two cost very differently. Agree it before the quote rather than discovering it at the first failure.
What has to be true about the building. Any condition attaching to your data, your funding or your licensing belongs in the requirement, not in a later conversation. If a system is federally funded, the property and inventory duties travel with it.
What to put in the requirement
A hosting requirement that a supplier can price is short. It states the number of rack units and whether the space is contiguous. It states the bandwidth allowance and whether bursting is expected. It states the power draw, or the equipment list from which the supplier can work it out. It states who performs installation and who performs remote hands. It states the required access arrangements, meaning who from your organization may enter the building and how that is authorized. And it states what evidence you expect: at minimum the facility's SOC reporting, and an asset register that identifies your equipment individually.
Ask three questions that are specific to a facility rather than to a supplier, because the answers vary and none of them is obvious.
How is my equipment identified? You want per-asset tagging and labelling, so that "the server in position 12" is a sentence somebody can act on at three in the morning and so that your own inventory reconciles. LABUSA's stated services include inventory and asset labelling, and it is reasonable to ask any provider to describe theirs.
What happens to a disk when it leaves? Equipment is decommissioned, disks fail and get replaced, and the media goes somewhere. The recognized standard is NIST Special Publication 800 to 88, which distinguishes clearing, purging and destroying and expects the choice to follow the sensitivity of the data. Ask which the provider does, who witnesses it and what documentation you receive.
What does receiving look like? Equipment arrives by freight. Somebody has to accept it, check it against a manifest, and store it until it is installed. A facility offering shipping and receiving has thought about this; one that has not will hand you a logistics problem you did not price.
The move itself
A colocation migration is a project with an outage in the middle, and the outage is the part to design first. Work backwards from the longest interruption each system can tolerate, which you should already have from a recovery statement.
Sequence matters more than speed. Anything that other systems depend on moves first or last, never in the middle. Networking and access control are established and tested before a single server is unplugged, because discovering a routing problem with the equipment already in a truck is the worst possible order. And there is always a rehearsal for the cutover of anything that matters, even if the rehearsal is only a documented walkthrough with the people who will be awake.
Plan the fallback explicitly. For most agencies that means the old room stays intact and powered for an agreed period after the move, which costs a little and is worth it. Deciding in advance what would cause you to use it is what stops a bad night becoming a bad week.
What usually goes wrong
Four failures account for most difficult colocation projects, and all four are avoidable at specification time.
The space was sized for the equipment and not for the cabling. Rack units are consumed by patch panels, cable management and the gap you need to work. Four servers do not fit in four U in practice.
Nobody agreed who may authorize physical access. This surfaces the first time a contractor needs to enter, usually urgently, and it is resolved slowly because it is a security control functioning correctly.
Backups still ran to the old building. The equipment moved and the destination did not, so copies were being written to a room that no longer exists or is no longer yours. This is common enough that it should be an explicit line on the cutover checklist.
The bandwidth allowance was sized on average and the backup window is not average. Everything is fine until the nightly job, which then runs into the working day.
What good looks like
Six months after a well run move, four things are true. Your asset register matches what is physically in the rack, because somebody reconciled it rather than assuming. The recovery statement names the new location and has been tested at least once. The people who may authorize access are named in a document rather than remembered. And the old room has been decommissioned deliberately, with its media handled to a standard you can describe.
None of that is exotic. It is the difference between a migration that finished and one that merely stopped.
The room you left
A migration is not finished when the equipment is racked. It is finished when the old room has been dealt with, and that is the part that gets abandoned once the interesting work is over.
Three things have to happen. Any equipment not moving is disposed of properly, which means the media in it is handled to a documented standard and the disposal is recorded against your asset register rather than against a memory. The room's own services are stood down deliberately: cooling, any dedicated power, and the monitoring that was watching it, all of which continue billing quietly if nobody cancels them. And the space is formally handed back to whoever owns the building, which is what stops it slowly refilling with equipment nobody has approved.
Agencies that skip this end up paying for two facilities while using one, and discover it in a budget review a year later. It is worth putting the decommissioning on the project plan as a phase with a date and an owner, rather than as a task somebody will get to.
One more thing belongs on that plan: telling the people who depend on these systems that the equipment has moved. Not the outage notice, which everybody remembers, but the standing change. Support routes, escalation paths and the answer to "who do I call" may all be different afterwards, and a service desk that finds out from a caller is a service desk that will handle the first real incident badly.
Placing the order
Space, leased servers, installation and the engineering to support them are all available under an awarded cooperative contract, so a public agency does not need a separate solicitation for the move. The purchasing sequence, from confirming eligibility through to issuing the order, is set out in how to purchase IT services through a TIPS contract, and the questions to put to any supplier under that contract are in the supplier evaluation checklist.
LABUSA provides colocation and dedicated hosting from a carrier-neutral Houston facility with a network operations center staffed continuously and SSAE 18 SOC 1 and SOC 2 reporting, together with shipping and receiving, asset labelling, installation and network engineering. The published scope and ceilings are on the contract this equipment would be housed under, listed with TIPS.
If you have a room to vacate or a project that needs somewhere to land, send us the equipment list you are working from.