When colocation deserves a serious look
Colocation becomes compelling when demand is steady enough to plan, specialized hardware matters, data movement is expensive, or the organization already operates a strong platform on owned equipment. It can also provide a controlled landing zone for infrastructure that should sit close to cloud on-ramps without running inside a cloud provider.
- Stable compute, storage, or network demand with a long useful life.
- GPU, high-density, licensed, or appliance-heavy platforms with specific hardware needs.
- Large data sets where recurring cloud storage or egress economics need scrutiny.
- Regulatory or operational requirements that favor direct hardware control.
- Existing equipment with meaningful remaining value.
When cloud keeps the advantage
Cloud is powerful when the team values speed, managed services, global reach, and the ability to scale resources without acquiring hardware. It is often the stronger home for new digital products, variable workloads, data services, development environments, and systems that can take advantage of cloud-native operations.
- Demand is uncertain, seasonal, or highly variable.
- Time to experiment matters more than unit infrastructure cost.
- Managed databases, analytics, AI services, and platform primitives reduce engineering effort.
- The application needs multi-region reach or rapid geographic expansion.
- The team can design, govern, and optimize cloud usage continuously.
Why hybrid is usually the useful comparison
A good hybrid design does not split infrastructure arbitrarily. It places stable or hardware-specific systems in colocation, uses cloud for elasticity and managed services, and connects the two with deliberate bandwidth, routing, security, and failure planning.
A hybrid business case should include cloud on-ramps, carrier circuits, cross-connects, egress, latency, redundant routes, and the operating effort required to manage both sides.
Questions to answer workload by workload
- How variable is demand over a month and over the next three years?
- Does the workload benefit from a managed cloud service, or is it primarily consuming raw compute and storage?
- How much data moves in, out, and between systems?
- What hardware, licensing, latency, security, and compliance constraints exist?
- Does the team have the skills and tooling to operate and optimize the chosen platform?
- What is the cost to exit or move if the original assumption changes?
Compare full lifecycle cost
For colocation, include hardware, support, refresh, facility recurring charges, network, migration, staff, and disposal. For cloud, include committed-use discounts, storage tiers, support, data transfer, security tooling, observability, managed-service premiums, and the labor needed to control architecture and spend. Use the same growth assumptions and service levels on both sides.
What the repatriation data actually says
Cloud repatriation is discussed in two unhelpful registers: an exodus, or a myth. The published survey data supports neither. It describes selective redistribution at very large scale, which is a more useful thing to plan against.
| Finding | Figure | What it means |
|---|---|---|
| Enterprises planning to repatriate some workloads | About 83% | The headline number, and the one most often misread |
| Planning full-scale repatriation | 8% to 9% | A wholesale exit from cloud remains rare |
| Selective redistribution | Roughly 77% to 78% | The actual pattern: specific workloads, not entire estates |
| Top driver, cost | 54% | The dominant reason, by a wide margin |
| Second driver, performance | 31% | Often latency or throughput on data-heavy workloads |
| Third driver, data sovereignty | 27% | Regulatory placement rather than economics |
Sources: Barclays CIO Survey 2024 and CIO's analysis of selective repatriation. Some later coverage cites the headline at 86%. The distinction between moving some workloads and planning a full exit is the important part, and we show both rather than quoting the larger number alone.
If 83% are moving something and only 8% are moving everything, then the correct question is never "cloud or colocation." It is "which workloads, and on what evidence." A business case built on a wholesale migration will not survive scrutiny. One built on three named workloads with measured cost and performance data usually does.
What published repatriation cases actually saved
The named cases are useful because they show both the scale of savings and the kind of workload that produces them.
| Organization | Reported outcome | Workload character |
|---|---|---|
| Dropbox | $74.6M over two years | About 500 PB moved to custom colocation; storage at extreme scale |
| 37signals | About $7M over five years | Predictable, steady-state application hosting |
Sources: Dropbox's S-1 infrastructure optimization disclosure and 37signals' account of its cloud exit. The figures are illustrative of what was achievable in those specific circumstances, not a benchmark you should expect to reproduce. Both cases involved substantial engineering investment that the savings figure may not fully reflect.
Notice what these have in common. Every one is a large, predictable, steady-state workload with well-understood resource requirements. That is the profile where colocation economics win, because you are trading elasticity you do not use for a lower unit cost you do. None of them is a bursty, unpredictable or rapidly changing workload, and that is not a coincidence.
The workload test
Rather than comparing platforms, score each workload against these six characteristics. The answers usually settle the placement without further debate.
| Characteristic | Points to colocation | Points to cloud |
|---|---|---|
| Demand pattern | Steady, predictable, sustained | Bursty, seasonal, unpredictable |
| Growth trajectory | Known and linear | Uncertain or exponential |
| Data gravity | Large volumes, high egress | Small volumes, low egress |
| Utilization | High and consistent | Low average with peaks |
| Managed service dependence | Few, or self-managed | Heavy use of proprietary services |
| Regulatory placement | Specific location required | Region-level control sufficient |
Egress deserves particular attention because it is the cost that most often decides the answer and is most often omitted from the model. A workload that moves large volumes of data out of a cloud provider carries a recurring charge that has no equivalent in a colocation contract, where you buy transit directly. If your estate has high egress, calculate it before anything else.
What the colocation side actually costs
A credible comparison needs a real number for the colocation side, not a placeholder. The published reference points are these.
- Wholesale, 250 to 500 kW: about $196.25 per kW per month across primary North American markets.
- Sub-1 MW deployments: $293 per kW per month, as reported by Digital Realty for the Americas in Q2 2026.
- Above 1 MW: $157 per kW per month, same operator and quarter. Scale matters more than any other single variable.
- Per cabinet: about $2,538 per month average, as reported by Equinix globally in Q2 2026.
Then add what the rate excludes: transit and bandwidth, cross-connects and cloud on-ramps, remote hands, hardware refresh, and the staff time to run it. Full sourcing for every figure above is on the pricing benchmarks page.
Cloud cost is an operating expense that scales with use. Colocation is a largely fixed commitment plus hardware you own and refresh. Comparing a monthly cloud bill against a monthly colocation rate omits the hardware, the refresh cycle and the staffing on one side, and the elasticity you are giving up on the other. Model both over the full term, including a hardware refresh, or the comparison is not meaningful.