Growth Forecasting
Back to Data Center Management · Rack Unit Tracking · Power Circuit Headroom · Cooling Capacity · Service Offerings
Growth forecasting is planning the next expansion before the current space is already full. The distinguishing feature of this work is that its output is a date, and specifically a date earlier than the one everybody is thinking about.
It builds on historical trending, which supplies the slopes. Trending tells you power is rising; forecasting turns that into "power is the binding constraint, it runs out in five months, procurement takes four, so this is decided next month".
1. Four Constraints, Four Different Dates
A data centre does not run out of capacity. It runs out of one capacity, and which one is rarely the one being watched.
| Constraint | Measured by | Typical surprise |
|---|---|---|
| Rack space | Usable contiguous units | Runs out later than feared, and is the one everyone watches |
| Power | Circuit headroom, redundancy-adjusted | Frequently binds first, and the redundancy halving is what does it |
| Cooling | Deliverable load per rack | Runs out locally while the room still has headroom |
| Network ports | Free ports of the right speed, in the right rack | Cheap to fix, expensive to discover late, and routinely forgotten |
The earliest date is the deadline. Forecasting space alone, which is the common practice, produces a date that is comfortably wrong whenever power or cooling binds first — and in a modern estate one of them usually does.
2. Lead Time Moves the Decision, Not the Deadline
The date capacity runs out is not the date you need to act. Subtract everything between the decision and working capacity:
- Procurement and approval, which for an electrical change can be the longest part.
- Equipment lead times, which have been volatile and are not reliably short.
- Installation work, and the outage window it may require.
- Commissioning and testing before the capacity can actually be used.
In the illustration above the constraint exhausts in five months and procurement takes four, so the decision point is next month — not in four months, and certainly not in five. Teams that track only the exhaustion date reliably discover they needed to act a quarter ago.
3. Capacity Arrives in Steps, Demand Arrives Smoothly
Demand grows a server at a time. Capacity does not: you cannot buy 3 kW of cooling or half a rack. You add a cooling unit, a circuit, a rack, a whole row — each a lump, each with a cost and a lead time.
Two consequences worth planning around:
- There is a right moment, and it is not the last moment. Adding capacity while the room is still working is a planned project; adding it when full is an emergency with the same cost and worse options.
- Bundle the steps. If power, cooling and space all run out within a few months of each other, one coordinated expansion is cheaper and less disruptive than three. Seeing that requires forecasting all four constraints together, which is the argument for section 1.
4. What You Know Beats What You Extrapolate
A trend line assumes the recent past continues. It is a reasonable default and it is routinely wrong, because the things that change capacity demand are usually known in advance by somebody.
- Planned projects. A migration, a new product, a customer going live. Ask the people running them rather than inferring from history.
- Hardware refresh. Replacement equipment is usually denser: fewer units, more power and heat per unit. A refresh can relieve the space constraint while tightening the power one, which no extrapolation will predict.
- Decommissioning. Capacity being released is as real as capacity being consumed, and is the cheapest capacity available.
- Workload leaving. Anything moving to cloud changes the slope. See physical, cloud or hybrid and growth projections.
Forecast with a range rather than a line: a base case from the trend, and a high case including the known projects. Two dates with stated assumptions are far more useful to whoever approves the spend than one date with a false air of precision.
5. Make It a Standing Review, Not a Document
A forecast produced once is out of date within a quarter and will be quietly ignored. What prevents an emergency is the cadence.
- Monthly or quarterly, depending on how fast the estate moves.
- Same four constraints every time, so the dates can be compared and a constraint that suddenly moved forward is visible.
- Track your own accuracy. Compare last quarter's projection against what happened. A forecast known to run optimistic can be corrected; an untested one cannot.
- One page, with the dates and the decision points, aimed at whoever controls the budget rather than at the people who produced it.
How We Approach It
- Establish current usable capacity for all four constraints — space, power, cooling, ports — using the real figures rather than nominal ones.
- Derive the growth rate per constraint from history, with seasonality accounted for.
- Collect what is known rather than inferred: planned projects, refreshes, decommissioning, workload moving out.
- Project base and high cases and identify the binding constraint in each.
- Subtract lead times to produce decision dates, which are the actionable output.
- Lay out the options — consolidate, densify, add capacity, move workload — with cost and lead time against each, and set the review cadence.
What You Get
- Exhaustion dates for space, power, cooling and network ports, with the binding constraint named.
- Decision dates, derived by subtracting real lead times from those dates.
- Base and high scenarios, with the assumptions behind each written down.
- The options at the next step change, costed, including the free ones: consolidation, decommissioning and rebalancing.
- A one-page review you can run yourselves on a cadence, and a record of how accurate the last one turned out to be.
The whole purpose is to convert a vague unease about filling up into a specific sentence with a month in it — because the first version gets deferred at every budget meeting and the second one does not.