A better brief before a bigger server

Free server sizing conversation starter.

Turn users, workload shape, live data, growth and recovery needs into a practical requirements brief. You will get a starting direction and the evidence still needed—not a made-up hardware specification.

Build a sizing brief

Starting examples

Describe demand before capacity.

Load the closest example or replace every assumption. “Concurrent users” means people active at the same time, not every account you hold.

01 Workload and demand

Choose the closest workload shape. Real monitoring and a representative peak will make the later specification much stronger.

Use “mixed” when one environment combines several distinct roles.
Plan around the busy period, not the quiet daily average.
active
Estimate the people or sessions doing work at the same time.
This is only a direction; storage latency and throughput still need measurement.
02 Live data and growth

This models live working data. Backups, replicas, snapshots, logs and test copies must be calculated separately.

GB
Use the actively stored application, database or file data today.
GB
Use a cautious estimate from history or a stated business forecast.
Longer horizons increase uncertainty as well as capacity.
%
Applied after forecast growth; it is visible so you can challenge it.
03 Service and recovery

Availability is an architecture and operating question. A larger machine does not remove a single point of failure.

Say when users genuinely need the service, including weekends and overnight work.
Your recovery time objective: how quickly service should return.
Your recovery point objective: how far back recovered data may be.
The final design should map this choice to real failure scenarios.
04 Delivery constraints
Non-production environments may be smaller or temporary, but they still need an explicit allowance.

Flag anything that needs specialist validation

Evidence before purchase

Close the gaps the form cannot see.

These are the measurements and decisions that should turn an early brief into an accountable specification.

    What the tool does

    Capacity is a range you verify.

    The workload band combines the type of system, concurrency, peak shape, data profile and recovery pressure. It deliberately stops short of vCPU, memory or a provider SKU because those require application evidence.

    Current datawhat is live todayGrowth × monthsforecast demandHeadroomvisible allowance
    01

    Baseline

    Use monitoring from a representative busy period whenever an existing workload is available.

    02

    Forecast

    Plan for expected growth and known peaks without treating every possible surge as permanent demand.

    03

    Design

    Choose a scale and recovery route that matches the application, business impact and operating team.

    04

    Test

    Load-test the important flows, monitor bottlenecks and revise the specification from evidence.

    Official architecture guidance

    Measure, forecast and right-size.

    The method follows a provider-neutral pattern: understand demand, forecast scenarios, identify resource limits, test, monitor and revise.

    Microsoft capacity planning guidanceGather data, forecast demand, align objectives and validate resource limits. AWS right-sizing guidanceMatch compute resources to workload performance requirements and re-evaluate them over time.

    Server sizing questions

    Use the brief to begin—not end—the decision.

    Why does this not recommend exact CPU and memory?

    The same user count can create very different demand depending on the application, query patterns, code, integrations and peak behaviour. Exact capacity should be tested against measurements and current platform limits.

    What is the difference between RTO and RPO?

    Recovery time objective describes how quickly service should return. Recovery point objective describes how much recent data the business can tolerate losing. Both should come from business impact, then be proven with recovery tests.

    Does the live-data allowance include backups?

    No. It covers current live data, forecast growth and the selected headroom. Backup copies, retention, change rate, snapshots, replicas, logs and non-production data need their own capacity model.

    Can I use this for cloud and physical servers?

    Yes, as an early requirements brief. The later design must account for the chosen platform’s instance types, quotas, storage performance, licensing, redundancy options and scaling behaviour.

    Need a specification you can defend?

    Turn the brief into a tested server design.

    ACA can review workload evidence, dependencies, recovery needs and operating responsibilities, then map them to a managed server design with clear assumptions and room to change.

    Explore managed servers