Right-size before you migrate, not after

The first cloud bill after a migration is usually a surprise, and the surprise is usually the same one. The estate was moved faithfully, everything works, and it costs more than the datacentre did.

Faithfully is the problem.

Two different purchases, sized two different ways

A physical server is a single decision made once. You size it for the worst hour you can foresee, add headroom for three to five years of growth because you cannot come back for more in March, and then round up to whatever the vendor actually sells. All three of those moves are correct under capex. Idle capacity on owned hardware costs nothing after the invoice is paid.

An instance is a decision you make every hour, and the idle capacity is billed every one of them. The same reasoning that produced a sensible server produces an expensive instance, and nothing in a lift-and-shift tool will tell you, because faithfully reproducing the spec is exactly what it was built to do.

What to measure instead

Not the spec sheet. The actual load, over a window long enough to contain the peaks that matter:

• A full business cycle, not a week. A month that includes month-end close. Payroll. Whatever your quarter does to you. A fortnight in the middle of a quiet month will size you beautifully for a month that never happens again.
• The 95th percentile, with the peaks noted separately. The mistake is to size on the mean, which breaks at month-end, or on the max, which is how you got here. Size on p95 and handle the peak deliberately — scale for it, schedule around it, or accept a slower month-end and write down that you accepted it.
• IOPS and throughput, not disk size. Storage is where cloud pricing least resembles a shopping list. A 2 TB volume that has been serving 400 IOPS does not need what the old array was capable of, and a small volume doing sustained writes may need more than its size suggests.
• Memory, honestly. It is the one dimension where the old box is often right — databases and JVMs get given memory and use it — and it is the dimension that drives instance family more than CPU does.

This is a fortnight of measurement on most estates, and it is the cheapest fortnight in the project.

Three things that do not shrink

• Licences. Some are counted per core or per socket. A 32-core box that was licensed as two sockets can become considerably more expensive as 32 vCPUs, or considerably less, depending on the vendor and the edition — and the answer is in the agreement, not in the cloud pricing calculator. Check it before you pick a shape, because it can change which shape you want.
• Data transfer. It did not exist as a line item in the datacentre and it will, reliably, be somewhere between a tenth and a third of the bill afterwards. Cross-zone chatter between application and database, backup egress, and anything replicating out of the region. None of it appears on a per-server sizing sheet, so a migration costed server-by-server will miss it entirely.
• The things nobody owns. Every estate has a handful: a file share, a print server, a scheduled job on somebody’s desktop, one application whose vendor went quiet in 2019. They will not right-size, because right-sizing needs somebody to say what the thing is for. Find them in discovery, not in the cutover weekend.

When one-for-one is the right answer

Sometimes it genuinely is. If the deadline is a datacentre exit, a lease expiry, or hardware that is out of support, then move first and optimise second — arguing about instance families while a lease runs out is a good way to pay for both.

But say so out loud, and put a date on the second half. “We will right-size after go-live” without a date in the plan and a named owner is a sentence that survives the project and outlives everyone who said it. Three months after cutover, when the estate is stable and there is a real month of cloud metrics to work from, is the right window. Book it while people still care.

And one order not to reverse

Do not buy a three-year commitment on an estate you have just lifted unchanged. The discount is real, the arithmetic is unforgiving, and it is the same sequencing mistake that makes waste load-bearing for the length of the term. Right-size, run for a month or two on on-demand pricing, then commit against what the estate actually consumes.

What to ask a migration partner

One question does most of the work: what did you size this on, and over what window?

If the answer is the existing server specification, you are being quoted a copy of your datacentre with a meter attached. If the answer is a month of utilisation data at p95, you are talking to somebody who has done this before and has had the conversation about the first bill.