Migration business cases tend to compare two infrastructure bills. That comparison is the easiest part of the exercise and the least likely to be where the estimate goes wrong.
Lifting and shifting moves the problem
Running the same architecture on rented machines usually costs more, not less. Cloud economics reward elasticity, and an application that cannot scale down does not benefit from being able to.
This is not an argument against migrating. It is an argument for being honest that the saving comes from the architectural work, not the venue change, and for putting that work in the plan.
The operational learning curve is real
Teams need time to become competent with new tooling, new failure modes, and new security models. That period is not free, and pretending otherwise produces the outages that make people distrust the whole exercise.
Budget for it explicitly. A migration where the team is genuinely confident by the end is worth considerably more than one that merely completed.
Data transfer and egress deserve modelling
The charges that surprise people are usually about data movement rather than compute. Analytics that pull large volumes across a boundary, backups written to another region, chatty services in different zones — none of these look expensive until they are running continuously.
Model the data flows, not just the instance sizes, before committing to a design.
Migrate for a reason you can state
Elasticity, resilience, geographic reach, and the ability to stop maintaining hardware are all good reasons. 'Everyone else has' is not, and it produces migrations that deliver a larger bill and no capability anyone asked for.
