Cloud Migration Cost: How to Estimate Before You Commit
Cloud migration cost is more than the move itself. There are one-off and ongoing costs, plus a few hidden ones. Here is how to estimate it properly before you commit.
- Cloud migration cost has two parts: the one-off cost of the move itself and the ongoing run cost afterwards. People routinely forget the second, which is the one that lasts forever.
- The migration cost is driven by the number and complexity of workloads, the approach per workload (rehost vs re-architect), and data volume; the run cost is driven by the resources you use and how well they are right-sized.
- An accurate estimate starts with an assessment and a cost model of your actual workloads, not a headline per-server figure.
- The biggest source of surprise bills is copying on-premise sizing into the cloud instead of right-sizing, plus idle non-production environments and egress charges.
"How much will cloud migration cost?" is the right question to ask before committing, but it has two answers that are easy to conflate: the one-off cost of migrating, and the ongoing cost of running in the cloud afterwards. The one-off cost is driven by how many workloads you move, how you move them, and how much data comes with them. The ongoing cost is driven by the resources you consume every month and how well they are right-sized. Get either wrong and the project disappoints. The reliable way to estimate is to assess your actual workloads, model a right-sized target architecture in the cloud provider's pricing calculator, add the migration effort, and budget for optimisation. This guide explains what drives each number, the hidden costs, and how to build an estimate you can trust.
What Cloud Migration Cost Actually Means
Cloud migration cost is the total of two distinct numbers: a one-off cost to move your systems into the cloud, and an ongoing monthly cost to run them there. The one-off cost covers planning, moving, testing and cutover. The ongoing cost is the recurring bill for compute, storage, databases and data transfer. Most disappointing migrations come from estimating only the first number and being surprised by the second. A trustworthy estimate treats them as a pair from the start.
The Two Kinds of Cloud Cost
| One-off (Migration) | Ongoing (Run) | |
|---|---|---|
| What it is | Planning, moving, testing, cutover | Monthly cloud resource bills |
| Driven by | Workloads, approach, data volume | Resources used and right-sizing |
| When it ends | At cutover and stabilisation | Never, it recurs every month |
| Main risk | Underestimating effort | Surprise bills from over-provisioning |
The ongoing run cost is the one people forget, and it lasts forever. A migration that ignores it can move to the cloud and end up paying more than before.
What Drives the Migration Cost
The one-off migration cost is driven mostly by scope and approach. A larger, more entangled estate with tight downtime limits costs more to move than a handful of simple, self-contained workloads.
- Number and complexity of workloads to move.
- Approach per workload: rehost (cheaper) vs re-platform or re-architect (more effort).
- Data volume, since large datasets take planning to migrate safely.
- Dependencies and integrations that must be reconnected.
- Testing and a low-downtime cutover.
What Drives the Ongoing Cost
The ongoing run cost is driven by what you consume and how disciplined you are about it. The same application can cost very different amounts depending on right-sizing and purchasing choices.
- Compute, storage and database resources, and how well they are right-sized.
- Managed services and serverless (pay-for-use) vs always-on servers.
- Data transfer and egress charges.
- Reserved capacity or savings plans for steady workloads.
- Non-production environments left running when idle.
Choosing an Approach per Workload
There is no single right migration approach. The cheapest move upfront is not always the cheapest to run, so the decision is made workload by workload. The matrix below maps the common approaches to when each one fits.
| Approach | Migration Effort | Run Cost Potential | Best When |
|---|---|---|---|
| Rehost (lift and shift) | Low | Higher if not right-sized later | Speed matters and the app is stable |
| Re-platform | Medium | Lower with managed services | Small changes unlock managed databases or scaling |
| Re-architect | High | Lowest for the right workloads | The app is strategic and consumption is high |
| Retire or retain | Minimal | Saves cost | The workload is redundant or not cloud-suited yet |
Rehosting first and optimising later is a valid strategy, but only if you actually schedule the optimisation. A lift-and-shift that is never right-sized is where surprise bills come from.
Qualitative Cost Drivers to Weigh
Precise figures depend entirely on your estate, so treat the factors below as relative drivers rather than fixed numbers. The more of these that point upward, the larger both the migration and run cost tend to be.
How to Estimate It Properly
An accurate estimate follows a repeatable sequence rather than a per-server rule of thumb. Work through the steps below in order and you finish with a total-cost picture that includes the ongoing bill.
- Assess and inventory every workload, its resource needs and its current cost.
- Decide the approach per workload (rehost, re-platform, re-architect, retire or retain).
- Model the target architecture in the cloud provider's pricing calculator using realistic, right-sized resources, not a copy of on-premise sizing.
- Add the one-off migration effort: planning, moving, testing and cutover.
- Layer in the hidden costs: egress, non-production environments, and licensing.
- Budget for post-migration optimisation and ongoing cost management.
- Review the total (one-off plus ongoing) against the business case before committing.
Want a Real Cloud Migration Estimate?
We assess your workloads, model both the migration and ongoing run cost, and recommend the approach that gives the best value, so you commit with a total-cost picture instead of a headline figure.
The Hidden Costs Teams Miss
The costs that break a budget are rarely the obvious compute bill. They are the ones that do not appear until the estate is live in the cloud.
| Hidden Cost | Why It Bites | How to Control It |
|---|---|---|
| Data egress | Charged when data leaves the cloud or crosses regions | Model traffic flows and keep chatty services together |
| Idle non-production | Dev and test environments left on around the clock | Schedule shutdowns outside working hours |
| Over-provisioning | On-premise sizing copied straight into the cloud | Right-size against real utilisation |
| Licensing | Bring-your-own vs cloud-included licences differ | Check licence terms before choosing instance types |
Common Mistakes to Avoid
Most cost overruns trace back to a small set of avoidable errors. Recognising them early is the cheapest optimisation you can make.
- Estimating only the migration cost and ignoring the ongoing run cost.
- Copying on-premise sizing into the cloud instead of right-sizing.
- Re-architecting everything upfront when a phased rehost would be cheaper and faster.
- Leaving non-production environments running around the clock.
- Forgetting egress and data-transfer charges in the model.
- Skipping the assessment and estimating from a per-server headline figure.
Cloud done carelessly can cost more than on-premise. The discipline that keeps it cheaper is right-sizing plus ongoing cost management, not the move itself.
How Acqurio Tech Can Help
We plan, cost and deliver cloud migrations with cost control built in, so the estimate you approve is the one you live with. We work remotely from India with an engineered overlap window with your team.
- Cloud & DevOps: migration planning, delivery and cost optimisation.
- Azure and AWS: accurate, platform-specific cost modelling.
- Hire DevOps engineers: pre-vetted cloud migration talent.
- Not sure where to start? Talk to us about an assessment.
Conclusion
Cloud migration cost is two numbers, not one: the one-off cost to move and the ongoing cost to run, and the second is the one most often underestimated. Estimate by assessing your workloads, choosing an approach per workload, modelling a right-sized target architecture, adding the migration effort, and budgeting for optimisation. Do that before you commit and you avoid the classic trap of moving to the cloud only to pay more than before.
Frequently asked questions
How much does cloud migration cost?
There is no single figure for cloud migration cost. It has two parts: the one-off cost of migrating (planning, moving, testing, cutover), driven by the number and complexity of workloads, the approach and data volume; and the ongoing run cost, driven by the cloud resources you use and how well they are right-sized. An assessment and cost model give a realistic total.
What is the difference between migration cost and run cost?
Migration cost is the one-off effort to move to the cloud: planning, moving workloads, testing and cutover. Run cost is the ongoing monthly bill for the cloud resources you use afterwards. The run cost lasts forever and is the one most often forgotten, so both must be estimated together.
Why do cloud bills end up higher than expected?
Usually from over-provisioning, that is copying on-premise sizing instead of right-sizing, plus idle resources, non-production environments left running, and data egress charges. Cloud done carelessly can cost more than on-premise, which is why right-sizing and ongoing cost management are essential.
What drives the cost of migrating to the cloud?
The number and complexity of workloads, the approach per workload (rehosting is cheaper than re-platforming or re-architecting), data volume, the dependencies and integrations that must be reconnected, and the testing and low-downtime cutover required.
How do I estimate cloud migration cost accurately?
Assess and inventory your workloads and current costs, decide the approach per workload, model the target architecture in the cloud provider's pricing calculator with realistic right-sized resources, add the one-off migration effort, and budget for post-migration optimisation. This gives a realistic total including the ongoing run cost, rather than a misleading per-server headline.
What are the hidden costs of cloud migration?
The costs teams miss are data egress and cross-region transfer, non-production environments left running when idle, over-provisioning from copied on-premise sizing, and licensing differences between bring-your-own and cloud-included licences. Model these explicitly so they do not surprise you after go-live.
Can I reduce cloud migration cost?
Yes. Rehost simple workloads rather than re-architecting everything upfront, right-size resources instead of copying on-premise sizing, use reserved capacity for steady workloads and pay-for-use services for variable ones, and shut down idle non-production environments. Right-sizing and the right approach per workload control both the migration and run cost.