Sizing a workload before you move it

Why this matters

CompTIA's bullet for this objective is analyzing requirements for workload migrations, and analysis is the word to take seriously. The most common migration failure is not technical: it is a workload moved onto an instance chosen by looking at the old server's specification sheet and picking something similar.

That fails in both directions. The old machine was usually specified for a peak that never arrived, with headroom for a five-year life, so a like-for-like move pays for capacity that was never used. And occasionally it fails the other way, because the old machine had a fast local disk that the default cloud volume does not match, and the workload is slower on "equivalent" hardware.

Getting this right is the difference between a migration that reduces cost and one that becomes the reason people say the cloud is expensive.

The lesson

Baselining the existing system over a period long enough to contain its peak

A baseline is a measurement of what the workload actually does, taken over a window that contains its real variation.

How long is long enough depends on the business, and the answer is always longer than people want:

• A week catches the daily cycle and the weekday/weekend difference. This is the minimum.
• A month catches month-end processing, which for finance, payroll and reporting systems is often the actual peak.
• A year, or last year's data, where there is a genuine season — retail before a holiday, education at enrolment, tax software in its filing window.

Measure, at minimum: CPU, memory, disk IOPS, disk throughput, disk capacity and growth, network throughput, and concurrent users or transactions.

Record percentiles, not averages. An average hides everything that matters. A useful baseline states the 50th, 95th and maximum for each metric, because the gap between them tells you whether the workload is steady (size for near the peak) or spiky (size for the baseline and scale).

Two cautions worth carrying:

• Do not baseline a system that is already failing. If the workload is constrained today, the measurements describe the constraint, not the demand. A CPU pinned at 100% tells you only that it needs more than it has.
• Baseline the business volume too, not just the technical metrics. If transactions grow 20% a year, a size that fits today's peak is wrong within months, and that is the number to design against.

CPU, memory, storage capacity and storage PERFORMANCE as four separate requirements

These are four independent requirements and conflating the last two is the classic sizing mistake.

CPU. Cores are not comparable across generations, so a count from a seven-year-old server means little. Where possible compare on utilisation and throughput rather than core count, and remember that a vCPU is a scheduled thread (objective 1.2) rather than a dedicated core.

Memory. The one requirement with a hard edge. Too little CPU makes a system slow; too little memory makes it fail, swap, or lose its cache. For databases and caches the working set is the number that matters, and it is not visible from outside the guest.

Storage capacity. Gigabytes, plus growth, plus whatever snapshots and backups will hold.

Storage performance. IOPS and throughput, and these are separate from capacity in the cloud in a way they were not on local disks. This is the point people miss. On a physical server, buying more disks bought both space and speed together. In a cloud, performance is frequently a function of provisioned size or of the volume type chosen, so a small volume can be slow purely because it is small, and a database's capacity requirement may not buy the IOPS it needs. Provision for the performance requirement and accept the capacity that comes with it, or choose a volume type where they are set independently.

Network is the fifth, and it is capped by instance size. A workload moving large volumes can hit the instance's network ceiling while its CPU is idle.

Network requirements: bandwidth, latency sensitivity and the chatty application

Bandwidth is the easy half: measure throughput at peak and add headroom.

Latency is the half that breaks migrations. Many applications were built when every component sat on the same switch, and they make many small round trips per user action. On a low-latency LAN a hundred round trips is invisible. Add even a few milliseconds per round trip and the same action becomes visibly slow, with no component showing a problem.

This is the chatty application problem, and it has a specific consequence: a chatty pair of components must move together or not at all. An application server migrated to the cloud while its database stays on-premises is the standard way to produce a migration that is technically successful and unusable.

What to measure and how:

• Round trips per transaction, from application traces or a packet capture.
• Current latency between the components, so you can calculate the effect of adding the new path's latency.
• Whether latency-sensitive traffic can be avoided — caching, batching, or moving the chatty pair together.

Also record any requirement for fixed addressing or specific ports, since cloud networking assigns addresses differently, and any dependency on broadcast or multicast, which most cloud virtual networks do not support at all. That is a genuine blocker and it is better discovered now than during cutover.

Licensing that counts cores or sockets, and the resize that doubles a bill

Software licensing is the requirement most often left out of a sizing exercise and the one most able to make a migration uneconomic.

The models that cause trouble:

• Per-core or per-socket licensing. A vCPU usually counts as a core, and cloud instances often present more cores than the physical server did. The same software can cost substantially more on identical performance.
• Licences tied to physical hardware, which may require a dedicated host (objective 1.2) to remain compliant — a real and expensive constraint, and often the reason a dedicated host is the right answer.
• Bring-your-own-licence rules that restrict which environments a licence may be used in, or require the provider's mobility terms.
• Licence servers that need fixed addressing or hardware identifiers.

The trap in the heading is the resize. Scaling an instance up to fix a performance problem doubles its vCPU count, and if the software is licensed per core the licence cost doubles with it — a change made for technical reasons with a financial consequence nobody modelled. Always check whether a size change is also a licence change before making it.

Check the entitlement documents, not the vendor's marketing. Where terms are ambiguous, get it in writing; audit exposure is a real cost.

Turning a baseline into a target instance size and writing down the assumption

The final step converts measurements into a decision.

A workable method:

1. Identify the binding constraint. Which measurement is closest to its limit? That resource picks the instance family (objective 1.2) — memory-heavy picks memory-optimised, and so on.
2. Size on the 95th percentile plus headroom, not on the maximum and not on the average. Something like 20–30% headroom for a steady workload.
3. Decide the scaling shape. Steady → size for near-peak. Spiky → size for the baseline and scale horizontally, if the workload allows it.
4. Set storage performance explicitly rather than accepting the default that comes with the capacity.
5. Check the licence consequence of the size chosen.
6. Check the network ceiling of that instance size against measured throughput.

Then write down the assumptions — and this is the step that separates a migration you can debug from one you cannot:

• the measurement window, and what it did and did not contain;
• the percentile used and the headroom added;
• the growth rate assumed;
• anything that could not be measured and was estimated instead.

When the workload misbehaves three months later, this document is what tells you whether the sizing was wrong or the workload changed. Without it, every performance conversation restarts from opinion. It is also the input to the first right-sizing review (objective 1.7), which should be scheduled at migration time rather than waited for.

What to take into the exam

• Baseline over a window that contains the real peak — a week minimum, a month for month-end, a year for seasonal. Use percentiles, not averages.
• Do not baseline a constrained system; you measure the constraint.
• Storage capacity and storage performance are separate requirements in a cloud, and performance is often tied to volume type or provisioned size.
• Chatty components must move together. Round trips, not bandwidth, are what latency punishes.
• Broadcast and multicast generally do not work in cloud virtual networks.
• Per-core licensing can make a resize a financial event. Check before scaling.
• Record the assumptions. They are what makes a later performance problem diagnosable.