Ask most growing businesses why a particular server exists and the answer is a story rather than a design. It was bought for a project that has since ended. It runs three unrelated things because each needed somewhere to live at short notice. Nobody is certain what would break if it were switched off, which is why nobody has switched it off.
This is not incompetence. It is what happens when infrastructure decisions are made under deadline pressure by people solving an immediate problem, repeatedly, over several years. Each decision was reasonable. The accumulated result is an estate whose shape records past urgencies rather than current requirements.
The business cost is paid in three currencies: spend on capacity nobody sized, outages whose blast radius nobody chose, and a growing inability to answer straightforward questions — what happens if this fails, how long until we outgrow it, what would it cost to recover. Planning is largely the discipline of answering those before circumstances force the answer.
Start from what must not stop
Every infrastructure conversation eventually reaches redundancy, and it reaches it more usefully if it starts from business impact rather than from components. The question is not which servers should be redundant. It is what the business cannot do without, and for how long.
| Tier | Description | Typical recovery expectation | What that implies |
|---|---|---|---|
| Critical | Revenue stops, or a regulatory obligation is missed, within an hour | Minutes | Redundancy at every layer, tested failover, monitored continuously |
| Important | Work is significantly obstructed but the business continues | Hours | Fast restore from backup; redundancy where it is cheap |
| Standard | Inconvenient; work continues by other means | A day | Reliable backup and a documented rebuild |
| Deferrable | Nobody notices for a while | Whenever | Backup only. Consider whether it should exist at all |
The exercise that makes this real is uncomfortable and quick: list the systems, and for each one ask what the business does between the moment it fails and the moment it returns. Most businesses find that fewer systems are genuinely critical than assumed, and that one or two nobody had thought about are.
The second finding is the valuable one. Identity, DNS and the network itself rarely appear on a list of business systems, and everything else depends on them. A plan that makes the application redundant while leaving a single domain controller or a single internet circuit has protected the visible thing and left the dependency underneath it.
Recovery time and recovery point are different questions
These are routinely conflated and they drive different spending. Recovery time is how long until the service is working again. Recovery point is how much data you are prepared to lose — the gap between the last usable backup and the failure.
A nightly backup gives a recovery point of up to twenty-four hours. For a document store that is often acceptable. For a system recording financial transactions it means re-entering a day's work from paper, if paper exists. The two requirements are set per system and by the business rather than by IT, because both are ultimately statements about acceptable loss rather than technical parameters.
Sizing without guessing
Capacity is usually chosen by one of three methods: the vendor's recommendation, whatever the previous system had plus a margin, or an estimate that felt safe. All three produce either an expensive over-provision or an outage in eighteen months, and neither outcome is visible at the time.
- 1
Measure current demand before specifying anything
Peak rather than average, over a period long enough to include a busy cycle — month-end, quarter-end, a seasonal peak. An average conceals exactly the moment that matters.
- 2
Identify the constraining resource
One resource limits each workload, and it is frequently not the one being purchased. Databases are usually constrained by disk latency and memory rather than processor cores; file services by throughput; voice platforms by concurrent sessions rather than by anything visible in a hardware specification.
- 3
Establish the growth rate from evidence
How much did storage, users and transaction volume actually grow over the past two years? A measured trend is a defensible planning input. A business plan's aspiration is not, and sizing to it is how over-provision happens.
- 4
Choose a planning horizon and state it
Three years is conventional for owned hardware and often too long for anything else. The horizon should be written down, because it is what makes the eventual replacement a scheduled event rather than a surprise.
- 5
Monitor utilisation against capacity from day one
Saturation is the only forward-looking signal in monitoring. A disk at seventy per cent with a known growth rate has a knowable date, and that date is a planning input rather than an incident.
The last step turns capacity from a periodic guess into a continuous measurement, and it is the difference between replacing hardware on a schedule and replacing it during an outage. It is also nearly free, since the monitoring is usually already deployed and simply not being read for this purpose.
On-premises, cloud, or both
This is usually argued as a cost comparison, which is the least reliable framing available because the two models make costs visible in different ways. Owned hardware concentrates spend at purchase and hides the operational cost inside salaries. Cloud spreads spend monthly and makes it uncomfortably visible. The same workload can look cheaper either way depending on which costs the analysis counts.
| Question | Points on-premises | Points to cloud |
|---|---|---|
| Is demand steady or variable? | Steady and predictable — you are buying capacity you will use | Variable, seasonal or unknown — you are buying only what you use |
| Where is the data required to be? | A specific jurisdiction or facility is mandated | Residency is satisfiable by region selection |
| What does the traffic do? | Large volumes staying local — voice between co-located staff, file access on site | Traffic that is already leaving the building anyway |
| Who operates it? | You have or retain the engineering capacity | You would rather not own patching, hardware and capacity |
| How fast must it change? | Requirements are stable; a three-year horizon is realistic | Requirements move faster than a procurement cycle |
| What is the failure you fear? | Dependency on an internet circuit you do not control | Facility, hardware and power becoming your problem |
The third row is the one most often missed during migration planning, and it applies with particular force to voice. Moving a phone system to the cloud converts calls between two colleagues in the same room into traffic that leaves the building, crosses the internet and comes back. For a distributed workforce that changes little; for a co-located floor it introduces a dependency that did not previously exist.
Most growing businesses end up hybrid, and that is a legitimate destination rather than an indecisive one. The failure is not mixing the two; it is mixing them without deciding which workloads belong where, so that the split records migration history rather than a design.
Virtualisation is a consolidation decision with a concentration cost
Running several workloads as virtual machines on shared hosts is the default for good reasons: better hardware utilisation, faster provisioning, simpler backup and recovery of whole systems, and the ability to move a workload off failing hardware without rebuilding it.
The cost is concentration. A physical host running twelve virtual machines is a single failure that takes twelve services with it, and shared storage underneath a cluster is a single failure that takes the cluster with it. That is an acceptable trade when it is chosen deliberately and the recovery path is tested, and a serious problem when consolidation happened gradually and nobody recalculated the blast radius.
The planning discipline is simply to ask, after each consolidation, what the loss of one host now costs — and to keep systems that must not fail together on hardware that will not fail together. Two domain controllers on the same hypervisor is the classic example of redundancy that is not redundant.
Plan the exit while planning the entry
Every infrastructure decision creates a dependency that will eventually need unwinding, and the cost of unwinding it is set at the moment it is created rather than at the moment it is unwound.
- Data formats and export paths. Can the data be extracted in a usable form without the vendor's cooperation? This is worth confirming before dependence deepens.
- Proprietary features. Using a platform's distinctive capabilities is often the right call and is also what makes leaving expensive. Choose deliberately rather than by default.
- Licensing that scales differently from your growth. Per-core, per-user and per-socket models behave very differently as a business grows, and the difference compounds.
- Contract terms — notice periods, minimum commitments and what happens to your data at termination.
- The knowledge dependency. A platform only one person understands is a single point of failure made of a human being, and it is the one no redundancy addresses.
None of these argues against committing to a platform. They argue for knowing the cost of the commitment while there is still a choice, which is a different exercise from avoiding commitment.
Common mistakes
| Mistake | Why it happens | What to do instead |
|---|---|---|
| Sizing from a vendor recommendation | It is authoritative-looking and requires no work | Measure peak demand and identify the constraining resource |
| Redundancy treated as backup | Both feel like protection against loss | Redundancy for recovery time; separated backup for recovery point |
| Redundant application, single dependency underneath | Identity, DNS and circuits are not thought of as systems | Tier the dependencies, not only the visible applications |
| Redundant pair on one hypervisor | Consolidation happened after the pair was designed | Recalculate blast radius after every consolidation |
| Cloud versus on-premises argued on headline cost | It is the only number both sides produce | Decide on demand pattern, data location, traffic shape and who operates it |
| Capacity reviewed annually | It feels like a procurement activity | Monitor utilisation continuously; saturation gives a date, not a surprise |
| No planning horizon recorded | Nobody asked how long the design should last | State it, so replacement is scheduled rather than reactive |
| One person understands the platform | They built it and it works | Document and cross-train; this is the failure no hardware redundancy covers |
A representative scenario
A composite of situations we see repeatedly; no client detail is included.
A business of around a hundred staff runs eleven servers across two hypervisor hosts, accumulated over six years. The review is prompted by a hardware refresh quote that nobody can evaluate, because nobody can say what the current estate is actually doing.
Tiering by business impact found four systems genuinely critical, three important, and four that could be switched off for a week without anyone noticing — two of which had been running unused since a project ended in 2023. Both domain controllers were on the same host, so the redundancy that existed on paper did not exist in practice. Backups ran nightly and had never been restored, so the recovery point was theoretical. Utilisation measurement showed the estate was substantially over-provisioned on processor and constrained on disk latency, which was the opposite of what the refresh quote proposed to buy.
The remediation cost less than the quote. The unused systems were decommissioned. The second domain controller moved to the other host. Storage was upgraded to address the actual constraint rather than replacing processors that were never busy. A restore was performed and timed, which established the real recovery point rather than the assumed one. Utilisation monitoring was added so that the next capacity conversation would start from measurement.
Planning checklist
- Every system is tiered by business impact, and the tiering was agreed with the business rather than assigned by IT.
- Recovery time and recovery point are stated separately for each tier, and both were set by the business.
- Identity, DNS, network and internet connectivity are tiered as systems in their own right.
- Backups are separated in time and reachable independently, and a restore has actually been performed and timed.
- Systems that must not fail together do not share a host, a storage array or a circuit.
- Current demand has been measured at peak, and the constraining resource for each workload is known.
- Growth rate is derived from measured history rather than from a business plan.
- A planning horizon is recorded, so replacement is a scheduled event.
- Utilisation is monitored against capacity continuously, with alerting before exhaustion.
- The on-premises and cloud split reflects a decision about demand pattern, data location and traffic shape rather than migration history.
- Export paths, licensing scale and contract exit terms were understood before committing to each platform.
- No platform is understood by only one person.
Frequently asked questions
Where should infrastructure planning start?
With what the business cannot do without, and for how long — not with technology selection. Tier each system by business impact, asking what the business actually does between the moment it fails and the moment it returns. Two findings emerge reliably: fewer systems are genuinely critical than assumed, and one or two nobody considered turn out to be. Identity, DNS, the network and internet connectivity rarely appear on a list of business systems and everything else depends on them, so a plan that makes an application redundant while leaving a single domain controller has protected the visible thing and left the dependency beneath it.
What is the difference between recovery time and recovery point?
Recovery time is how long until a service is working again. Recovery point is how much data you are prepared to lose — the gap between the last usable backup and the moment of failure. They drive different spending and are routinely conflated. A nightly backup produces a recovery point of up to twenty-four hours, which is often acceptable for a document store and unacceptable for a system recording financial transactions, where it means re-entering a day of work. Both are business decisions rather than technical parameters, because both are statements about acceptable loss.
Is redundancy the same as backup?
No, and treating them as interchangeable is the most common planning error in this area. Redundancy — a mirrored disk, a clustered pair, a replicated database — protects against hardware or node failure and addresses recovery time. It replicates mistakes instantly: deletion, corruption and ransomware propagate to the replica by design, because faithful replication is exactly what it is built to do. Only a backup that is separated in time and reachable independently addresses recovery point. A business with excellent redundancy and untested backups is protected against the failure mode that is becoming less common and exposed to the one that is becoming more common.
How do you size infrastructure without guessing?
Measure before specifying. Capture peak demand rather than average, over a period long enough to include a busy cycle such as month-end or a seasonal peak, because an average conceals precisely the moment that matters. Then identify the constraining resource for each workload, which is frequently not the one being purchased — databases are usually limited by disk latency and memory rather than processor cores, and voice platforms by concurrent sessions rather than by anything visible in a hardware specification. Derive the growth rate from measured history over the past two years rather than from a business plan, record a planning horizon, and monitor utilisation against capacity continuously so that saturation gives you a date instead of a surprise.
How should a business choose between on-premises and cloud?
Not on headline cost, because the two models make costs visible in different ways and the same workload can look cheaper either way depending on which costs the analysis counts. The questions that actually decide it are: whether demand is steady or variable, since owned capacity suits predictable load and consumption pricing suits variable load; where data is required to reside; what the traffic does, because workloads whose traffic stays local behave badly when the platform moves away from the users; and who is going to operate it. That last question is often decisive for a business without retained engineering capacity. Most growing businesses end up hybrid, which is a legitimate destination provided the split reflects a decision about which workloads belong where rather than the order in which things were migrated.
What are the risks of virtualising everything onto fewer hosts?
Concentration. Virtualisation is the sensible default — better utilisation, faster provisioning, simpler whole-system backup and recovery, and the ability to move a workload off failing hardware without rebuilding it. The cost is that a physical host running twelve virtual machines is one failure that takes twelve services, and shared storage under a cluster is one failure that takes the cluster. That is an acceptable trade when chosen deliberately with a tested recovery path, and a serious problem when consolidation happened gradually and nobody recalculated the blast radius. The specific case to check is a redundant pair sharing a hypervisor, such as two domain controllers on one host, which is redundancy that does not exist.
Conclusion
Infrastructure planning has a poor reputation because it is associated with long documents that describe a future nobody reaches. The version that works is much smaller: know what must not stop and for how long, know what is actually constraining each workload, know the growth rate from measurement, and record the horizon so that replacement is scheduled rather than forced.
Everything else — platform choice, virtualisation, cloud, redundancy design — follows from those four and is difficult to decide well without them. Businesses that skip them do not avoid the decisions; they make them anyway, under deadline, one server at a time.
Sources and further reading
- Infrastructure monitoring that works— saturation as the forward-looking capacity signal
- High availability for business systems— what each additional nine costs, and why RTO belongs per system rather than per estate
- Replacing infrastructure without stopping the business— executing the migrations this planning produces
- The technology stack for a growing business— every layer, and which decisions are hard to reverse
- VMware vs Hyper-V— the virtualisation platform decision, and why it is now a licensing question
- Windows Server: the practices that actually matter— support lifecycle dates, role separation and directory recovery
- Network segmentation for growing businesses— blast radius as a design decision rather than an accident
- Data retention and archiving for growing businesses— why storage grows on a curve nobody planned
- Building reliable call centre infrastructure— a worked example of tiering by blast radius
Services This Relates To
Written by KYCONNECTS Engineering. Client names are withheld under confidentiality.