Most cloud migrations come in near the number. The migration itself is a defined piece of work with a scope, a timeline, and a team, and organizations have gotten reasonably good at estimating it. The surprise arrives later. Somewhere between month four and month nine, the monthly bill settles at a figure nobody modeled, and the conversation shifts from whether the migration succeeded to why the run rate looks like this.
The overrun is rarely one large mistake. It is usually five ordinary ones, none of which is visible during planning because none of them exists until the environment is actually running.
One. Data movement nobody priced
Instances get provisioned against the worst case, which is correct practice during a cutover. Capacity is cheaper than an outage in week one.
What rarely follows is the review. Six months later the environment is still carrying launch day headroom for load that never materialized, and nobody revisits it because nothing is broken. Oversizing produces no alert, no incident, and no complaint. It only produces an invoice, and invoices go to a different team than the one that sized the instances. This is the single largest recoverable cost in most environments, and it is usually the last one anyone looks at.
Three. Licensing that changed shape in the move
Licensing terms that were straightforward on owned hardware often work differently on shared infrastructure. Some products are licensed per physical core, which behaves unpredictably on virtualized hosts. Some restrict the right to run on third party infrastructure without a separate agreement. Some remain compliant but cost more. This is discovered in one of two ways. Either during planning, where it is a line item and an adjustment, or during a vendor audit afterward, where it is a negotiation conducted from a weak position.
Four. Storage that never ages
Cloud platforms offer tiered storage precisely because most data becomes cold quickly. Very few organizations act on that. Snapshots accumulate on a schedule that was set once and never reviewed. Backups are retained well past the policy that governs them because deleting things feels risky and keeping them feels free.
Volumes stay attached to instances that were decommissioned. None of it triggers anything, and all of it bills every month.
Lifecycle rules solve most of this and take an afternoon to configure. The obstacle is not technical. It is that nobody owns the decision about what can safely age.
Five. The environments that were supposed to be temporary
Test environments, the parallel run environment kept during cutover, the sandbox a vendor needed for six weeks, the duplicate built to prove the migration worked.
In a data center, these are constrained by physical capacity, which forces the cleanup conversation. In the cloud there is no constraint, so the conversation never happens. Environments persist for years past their purpose, and because they were created by people who have since moved to other work, no one is confident enough to delete them.
The pattern underneath all five
None of these is a technical failure. Each is a decision that was correct at the time and was never revisited, in an environment where nothing forces a review.
On premise infrastructure had a natural governance mechanism. Capacity was finite, so consumption was a conversation. Cloud consumption is elastic, which is the advantage, and it removes the moment that used to force the conversation.
The organizations that keep spend predictable are not the ones running the most sophisticated tooling. They are the ones where a named person reviews the environment on a set schedule, with authority to shut things down and enough context to know what is safe to touch. That is a governance practice, not a platform feature, and it is the part that gets left out of the migration plan.
System Custom Consultants provides cloud and technology solutions, including migration planning, cost review, and the governance practices that keep spend predictable after go live. If your cloud run rate is higher than the model predicted, that is a reviewable problem. Start a conversation at systemcustom.com
