A migration business case usually compares the cost of running a workload on owned hardware against the cost of running the same workload on rented infrastructure. Done honestly, that comparison is frequently unfavourable — and organizations that migrate on that basis alone tend to arrive at a higher run rate than they left.
Where the money actually is
Cloud economics do not come from the compute being cheaper per hour. They come from three changes, none of which happen automatically.
Elasticity: paying for capacity only while it is in use. This is real money, but only for workloads with genuinely variable demand. A system running at steady state around the clock is usually cheaper on owned hardware over a three to five year horizon.
Managed services: replacing operational effort with a service. Moving a self-managed database to a managed one removes patching, backup engineering and failover configuration. The infrastructure line goes up and the staff-time line goes down — and the second saving is the larger one, though it rarely appears in the business case because it is not a line item.
Decommissioning: the saving that gets left on the table most often. Migration projects move workloads and then leave the source environment running, either as a rollback path that becomes permanent or because nobody has authority to switch it off. Until the old estate is decommissioned, the organization is paying twice.
The workloads that should stay
Steady-state, high-throughput, latency-sensitive, or subject to data handling requirements that point to a specific location. Those characteristics describe a large share of core enterprise systems, which is why almost every enterprise of scale ends up hybrid rather than fully migrated.
That is a legitimate destination, not a failure to finish. The design question is not how much you move — it is where the boundary sits, how the two sides connect, and which side is authoritative when they disagree.
A practical test
For each candidate workload: does its demand vary by more than roughly double between peak and trough, and will the source environment definitely be switched off? If the answer to either is no, the case needs to rest on capability or resilience rather than cost — which is often a perfectly good reason to proceed.