Migrating was the easy part. The invoice is what did not add up
An executive guide with the six decisions that separate changing address from changing shape — what to resize before moving, what should never have migrated, and the cycle that stops the bill from growing on its own.
100%
Everything left the datacentre and went up. That is the number that closes the project.
23%
The rest went up at the size it had on-premises — where size was paid for once.
Migrating changes your address. Saving changes your shape — and those are two projects, not one.
The problem
The bill does not rise by mistake. It rises because the server was copied
On-premises, the server was sized once for a peak three years ago, and nobody touched it since — because there was no reason to. The cost was sunk: the machine was already bought.
In the cloud that same server is billed by the hour, at the size it arrived in. The bill did not explode from new waste; it exploded because old waste, which used to be invisible, became a line on the invoice every month.
And the migration business case rarely accounts for that. It compares datacentre cost with estimated cost of a resized cloud, and the migration delivers a non-resized one. The gap between the two is the hole.
There are three places where this arithmetic repeats, and each one appears in the guide with its number attached.
What the invoice charges
Same capacity, no risk of running short.
The peak from three years ago, billed hourly, every month, including Sunday at 3am.
Backup preserved, nothing lost.
An old snapshot keeps charging with no disposal date — and nobody knows which ones are still needed.
A faithful mirror of production.
A faithful mirror running 24/7 for a team that works eight hours on weekdays.
Migrated with no downtime.
A licence carried over from on-premises can cost more in the cloud than the managed equivalent.
What is inside
Six decisions you take before moving, not after
1 · What should not migrate. Not every workload improves in the cloud. The triage criterion — keep, replatform, rewrite or retire — with the cost of each path declared.
2 · How to size with data, not fear. How to read ninety days of real usage and turn it into instance size, without repeating the peak from three years ago.
3 · Where commitment pays and where it traps. Reservations and committed-use discounts pay off handsomely — and become a trap when the workload is still going to change shape.
4 · What to switch off, and who decides. The shutdown schedule for non-production environments, and why it needs a named owner to survive the third month.
5 · The monthly cycle that holds the bill. Four questions, one short meeting, and a record of what was decided — which is what prevents the same argument in January and in July.
6 · What changes when SAP is in play. Memory is not sold by the loose gigabyte, and licensing has rules of its own. A separate chapter, because the mistake here is expensive and invisible to the cloud console.
Who for
Written for whoever signs the invoice and has to explain it
- migrated and the bill came in above the business case;
- are planning to migrate and want the right number before signing;
- need to give the board an explanation better than “cloud is expensive”;
- have SAP in the estate and suspect the rules there are different.
- want a step-by-step for a specific migration tool;
- want an AWS vs Azure vs Google comparison — the guide is vendor-neutral;
- expect a guaranteed savings figure: there is method here, not a promise.
Cloud migration guide
The PDF link appears right here as soon as you send. No account, no password, no intermediate step.
- Executive guide, 2026 edition
- The six decisions with effort and return declared
- A dedicated chapter for SAP estates
- Triage checklist and shutdown schedule
Inove Solutions looks after cloud estates in cloud services and FinOps, and handles the SAP case in SAP practices.