Server Capacity Planning for SMEs: The Questions That Replace Guesswork

The most common question in server purchasing is admirably direct: "We are fifty people — what do we need?" It is also unanswerable as asked. Without knowing what those fifty people run, how many systems will live on the machine and how fast the data grows, any answer is a guess. Capacity planning starts from workloads, not headcount. This is not a hardware catalogue; it is the set of questions and principles management should hold before sitting down to any purchasing conversation.

Why There Is No Users-per-Server Formula

Picture two fifty-person companies: one uses file sharing and accounting; the other runs an ERP, a camera archive, an e-commerce integration and a reporting server. Their needs differ by multiples. Headcount is just one multiplier — the real driver is the list of systems and each one's appetite for resources.

What must be clear before any sizing conversation:

• Which applications will run on the server: accounting/ERP, files, databases, cameras, mail?
• How many users load these systems at the same time — concurrent, not total?
• How many GB is the data today, and how fast does it grow per year?
• Does load swing during the day or the calendar: month-end, season, shifts?
• Any new systems or locations likely within three years?

The Four Components of Capacity

CPU: Core Count Is Not the Whole Story

Application type drives CPU need: databases and ERP scale with concurrent users, file services are comparatively modest, camera analytics load continuously. In a virtualized environment, total cores are planned against the measured real usage of all VMs — not the theoretical sum of their maximums.

Memory: The Most Common Bottleneck

Underprovisioned memory is the single most frequent cause of "the server is slow" complaints; databases and VMs consume all they are given. Sizing puts a growth margin on top of today's total — memory is relatively easy to add later, but starting short is the most expensive mistake.

Storage: Speed as Much as Space

Storage asks two separate questions: how many terabytes, and how fast? Databases and ERP want fast media (SSD/NVMe); archives and camera footage can live on capacity-oriented disks. A tiered layout — fast tier plus capacity tier — is the balanced answer for most businesses. Backup space is planned separately, outside this calculation.

Network and Redundancy

However strong the server, a network bottleneck defines the experience; plan adequate bandwidth and, where possible, dual links on the server side. Power-supply and disk redundancy (RAID) are decided at purchase time — retrofitting is either costly or impossible.

Component	Driven by	Common mistake
CPU	Application type + concurrency	Judging by core count alone
Memory	Combined VM and database appetite	Leaving no growth margin
Storage	Capacity plus speed tiers	One disk type for every workload
Redundancy	Outage tolerance	Skipping RAID and dual power

The Growth-Margin Principle

Healthy sizing targets year three, not today: data growth, user increase and probable new systems are counted in, with a sensible reserve left in every resource. The opposite extreme also fails — capacity bought "to last ten years" idles until its technology is obsolete, locking up budget from day one. A three-year planning horizon is the common balance between cost and flexibility; in a virtualized environment, an annual review against monitoring data keeps that balance honest.

Real-World Examples

Example 1: The Server Sized by Headcount

A distributor bought a server sold as "enough for forty people" — and watched it lock up every month-end during invoicing. Analysis showed the problem was never headcount; it was the concurrent reporting load at month-end. Memory and the fast storage tier were upgraded against that pattern, and month-ends went quiet.

Example 2: A Refresh Based on Measurement

Ahead of a hardware refresh, a law firm's existing server was monitored for three months: real CPU usage proved low, memory ran permanently near the ceiling, disk growth was steady and predictable. The new machine was sized from those measurements — a more balanced and cheaper configuration than any estimate would have produced.

How Yamanlar Bilişim Supports This Process

Yamanlar Bilişim treats capacity planning as measurement, not guesswork: where an environment exists, its resource usage is monitored for a period; where it does not, the calculation is built from the application list and concurrency. The proposal covers CPU, memory, storage tiers and redundancy options, sized against a three-year growth scenario.

Typical steps in a sizing engagement:

• Application and workload inventory
• Resource-usage measurement on the current environment
• Sizing proposal against a three-year growth scenario
• Storage tiering and redundancy design
• Post-deployment capacity monitoring with annual review

The sizing and deployment service is described on the Server Setup & Virtualization page; the architectural physical-versus-virtual decision has its own companion guide.

FAQ