The migration is never the expensive part
Most cloud migration proposals get approved on a straightforward pitch: move off aging infrastructure, cut operating cost, gain flexibility. The business case usually looks solid on paper. What tends to go wrong is not the technology decision. It is the assumption that the biggest cost sits in the migration itself.
In practice, the actual move of workloads is usually the smallest line item in the project. The budget gets blown in five places that rarely make it into the original business case.
1. Data migration and validation
Moving data is not a copy job. Legacy systems accumulate years of inconsistent records, duplicate entries, and undocumented business logic buried in stored procedures or spreadsheets nobody remembers building. Before a single workload moves, someone has to audit what is actually in the system, decide what is worth carrying forward, and validate that the migrated data still matches business rules on the other side. Teams that skip this step discover the problem during user acceptance testing, when it is far more expensive to fix.
2. The refactor or lift and shift decision
Lifting an application and shifting it to the cloud unchanged is fast and cheap up front, but it often means paying cloud prices for on premises inefficiencies. Refactoring to use managed services properly, such as replacing a self managed database with a platform service, costs more early but pays back in lower operating cost and less maintenance. Most organizations need a mix: some systems are worth refactoring, others are not close to end of life and do not justify the investment. Deciding which is which, application by application, is real work that is easy to underestimate.
3. Running two environments in parallel
Almost no migration is a single cutover weekend. There is a period, sometimes several months, where the old and new environments run side by side while data is reconciled and users are moved over in phases. That means paying for infrastructure twice, plus the engineering time to keep both systems in sync. This window is where a lot of budgets quietly slip, because it was scoped as weeks and became a quarter.
4. The skills gap
A team that has run on premises infrastructure for a decade does not automatically know how to operate a cloud environment securely and cost effectively on day one. Training, certification, and often bringing in outside expertise for the first few months are real costs that belong in the business case, not treated as an afterthought once the migration is already underway.
5. Governance and security retrofits
On premises environments often accumulate informal security practices that were never written down. Moving to the cloud is usually the moment an organization is forced to formalize identity management, network segmentation, and compliance controls properly, because the cloud provider’s shared responsibility model makes gaps visible. That formalization work is valuable, but it is additional scope that needs its own budget line.
A short example
I worked with a public sector transportation organization on a large scale modernization program that involved migrating a decades old operational system as part of a move to a modern cloud based ERP platform. The original business case focused on the migration timeline and infrastructure savings. What actually determined whether the project stayed on budget was the work upstream of the migration: an early data audit that surfaced years of inconsistent records before they became a testing crisis, and a phased cutover plan that avoided running the full organization on two systems at once. Neither of those show up on a typical project timeline for “cloud migration,” but they were the difference between a program that held its numbers and one that did not.
A short checklist before you commit a number to your board
- Has someone actually audited the data, not just the application inventory?
- Do you know which systems get refactored and which get lifted, and why?
- Is there a realistic budget for running parallel environments, not just a target date?
- Who is building the internal skills to operate this after go live?
- Has security and governance been scoped as part of the project, not assumed to happen automatically?
If you are scoping a migration and want a second opinion on the numbers before you commit a budget to your board, I am happy to have that conversation. You can reach me through the contact page.
If the migration includes containerizing workloads, the patterns that keep a Kubernetes platform reliable in production are covered in this post. And if you want to see how the delivery side of a program like this should be structured to avoid the same budget problems, that is covered in the PMO playbook.
Leave a comment