The traditional colocation product is a cage in a data hall — you lease square footage, you rack your gear, you pay for power and cross-connects. The model is well-understood, has worked for decades, and still serves a meaningful share of the colocation market.
The modular colocation product is different — a defined “suite” with bounded power, cooling, and physical envelope, sold as a unit that scales by adding additional suites rather than by extending into a generic shared hall. The model fits modern AI and HPC workloads in ways the traditional cage doesn’t, and the TCO math is worth understanding before you sign the next multi-year contract.
This article walks the actual economics — not the marketing.
The two models, side by side
Traditional colocation:
- Long lease, fixed square footage
- Power capacity contracted up front (often more than you initially need, to lock in future growth)
- Cooling is shared across the data hall — your gear sits in a mixed-tenant environment
- Adjacent tenants and their workloads are your physical neighbors
- Expanding means either expanding your cage (if space is available) or taking a second cage somewhere in the hall
Modular colocation:
- Defined suite with discrete power, cooling, and physical boundaries
- Capacity sized per suite — you take what you need, add another suite to grow
- Cooling is dedicated or near-dedicated to the suite
- Tenant isolation is stronger by design
- Expansion is a new suite, not a cage extension
The big difference: the unit of capacity. Traditional is “square feet plus power.” Modular is “a suite with everything bundled.”
CapEx vs OpEx
In both models, the customer’s primary spend is OpEx (the recurring lease, power, and service charges). The CapEx is in the customer’s own IT equipment — servers, networking, storage. So in a narrow accounting sense, both look similar from the tenant’s P&L.
Where the CapEx vs OpEx conversation actually matters is in the operator’s infrastructure choices, because those choices shape what you can buy:
- Traditional facilities were built as large undifferentiated data halls. The operator’s CapEx was spread across the hall, and the cost-recovery model assumes the hall fills with a mix of low- and medium-density tenants
- Modular facilities were built as discrete suite units. The operator’s CapEx is sized per suite, and the cost-recovery model assumes each suite carries its own load
For a high-density AI tenant, the modular model usually delivers a cleaner price-per-kW because the operator hasn’t averaged the cost across a hall full of lower-density tenants. You’re not subsidizing the 5kW-per-rack tenants down the row.
Scaling friction — the part traditional gets wrong for AI
Here’s where the model difference matters most. Traditional cages scale poorly for the AI workload pattern.
When an AI tenant grows — and they grow fast — they need more racks (often a lot more, in a single quarter), higher power per rack (because the new GPUs are denser than last year’s), more cooling capacity for that power, and potentially additional cross-connect bandwidth.
In a traditional cage model, all of those are friction points:
- Adding racks requires space that may not be adjacent to your current cage
- Adding power per rack requires the facility to have headroom in your cage’s electrical, which it often doesn’t (because the hall was sized for an average density)
- Adding cooling is shared infrastructure — you can’t unilaterally upgrade your cage’s cooling, you depend on the facility-wide system
- Adding cross-connects ranges from straightforward to multi-week depending on the carrier and the facility
In a modular model, the answer is usually simpler: take another suite. The new suite comes with its own contracted power and cooling. You don’t fight the existing infrastructure — you commission a parallel unit.
Time-to-deploy
- Traditional cage in an existing hall — Days to weeks once the lease is signed, assuming the cage is available and the power is provisioned. For a new build-out (carving cage from raw space), weeks to months
- Modular suite at a facility with available suites — Days. The suite is already built. You move your gear in, the operator energizes the suite per contract
- Modular suite that requires a new unit — Weeks. New modules can be staged and energized faster than traditional new-hall capacity, because the unit is prefabricated and the infrastructure pattern is repeatable
For AI tenants whose growth depends on getting compute live this quarter, not next year, the time-to-deploy advantage of modular is meaningful. Every week the GPUs aren’t drawing power is a week of opportunity cost.
When modular wins
- You’re running high-density workloads (50kW+ per rack) where shared-hall cooling can’t keep up
- Your growth is lumpy (you add 10 racks at a time, not 1)
- You need physical isolation for compliance, security, or workload sensitivity
- You want predictable deployment timelines because your business depends on them
- You’re paying for power, not square footage — modular billing aligns better with the actual cost driver
When traditional wins
- You have low-density gear (sub-15kW per rack) and don’t need the modular envelope
- You’re a small deployment (1–3 racks) where a modular suite is over-provisioned
- You need a specific facility for carrier proximity — and that facility is built traditional
- You’re optimizing for the absolute cheapest price-per-square-foot at low density
The deployment math at 10, 50, and 100 racks
At 10 racks (50kW each = 500kW total): A traditional cage is feasible — you lease a footprint, contract 500kW, and shared cooling handles the load if it was sized for high density (many weren’t). A modular suite is likely one or two suites with dedicated cooling, faster to live, competitive price per kW.
At 50 racks (2.5MW total): A traditional cage is a significant chunk of a hall, straining cooling and power unless the hall was built for high density; deployment stretches and pricing negotiation gets complex. Modular is multiple suites in a row — each a clean, defined, repeatable unit.
At 100 racks (5MW total): Traditional rarely scales this far cleanly without bespoke engineering. Modular scales better at the high end than the low end, because the unit-economic advantage compounds. The modular advantage grows with scale, not shrinks.
Where Data Suites fits
Data Suites is built on the modular suite pattern — discrete suites with high-density power (50kW+ per rack), dedicated cooling, and a buildout model that scales by suite rather than by hall extension. The architecture matches the AI and HPC workload pattern that’s actually showing up in 2026, not the 5kW-per-rack assumption that shaped most of the existing traditional inventory.
For a buyer choosing between modular and traditional, the deciding question usually isn’t “which is cheaper at zero growth?” It’s “which is cheaper across the next three years of growth?” — and for high-density tenants, that answer increasingly points to modular.
Bottom Line
The modular vs traditional choice is not a tie. It’s a workload-pattern choice. High-density, fast-growing, isolation-sensitive workloads belong in modular. Steady-state, low-density, price-sensitive deployments still work in traditional. Pick the model that matches your actual three-year deployment trajectory — not the model your last data center was on.
Data Suites is a Murfreesboro-based Tier 2 colocation operator serving AI, HPC, and high-density compute workloads across Middle Tennessee.
