Cloud Migration Cost for IT and Finance: Labor Can Reach 55%
A small lift-and-shift migration can land anywhere from a few thousand dollars in labor to six figures once licensing, data transfer, and parallel running are counted, while a multi-wave enterprise program routinely runs into the millions. The biggest swing factor is not compute pricing: it’s labor complexity, how long you run old and new environments side by side, and how much data has to move. Before you trust any number, collect your workload inventory and run it through a provider migration estimator.
TL;DR:
- Labor and professional services typically consume 35% to 55% of total program costs, while parallel running adds 15% to 30%.
- Collect at least seven days of utilization data, rightsize workloads before pricing, and classify applications by migration strategy before using provider estimators.
- Provider calculators estimate cloud costs but omit internal labor, contract penalties, business interruption, and decommissioning, so add these items manually to the business case.
- For each migration wave, start cloud spending one to two months before reducing legacy infrastructure costs, and model both ramps in year one.
- Move simpler rehost and replatform workloads first, defer complex refactoring until its payback is proven, and stagger replication to control bandwidth and cutover risk.
Table of Contents
- 1. What makes up cloud migration cost
- 2. A practical step-by-step method to estimate your migration cost
- 3. Key cost drivers and common hidden expenses to watch for
- 4. Budgeting and timeline: three sample scenarios
- 5. How to build a defensible business case and TCO for stakeholders
- 6. Cost optimization levers during planning and execution
- 7. NULLBIT perspective: how we estimate and manage migration cost for clients
- 8. Author perspective: balancing financial goals and strategic modernization
- 9. How NULLBIT can help: assessment and cost-control services
- FAQ
- Sources
- Authoritative vendor tools and migration guidance to run your estimate
1. What makes up cloud migration cost
Most budgets fail because they price only the destination, the monthly cloud bill, and ignore everything it takes to get there. A defensible estimate covers the full arc from assessment through steady-state operations, not just server costs, which is exactly the shift AWS prescriptive guidance recommends: model on-premises costs, target-cloud costs, migration and modernization work, contract termination, and the timing of each wave together.
The categories that belong in every migration budget:
- Assessment and planning: discovery, inventory, dependency mapping, and wave sequencing.
- Migration labor and professional services: engineers, architects, and project management for each wave.
- Data transfer and replication: bandwidth, change data capture, and egress during cutover.
- Temporary infrastructure: staging environments, test instances, and migration tooling licenses.
- Parallel running (dual-running): paying for old and new environments simultaneously during validation.
- Software licensing: new cloud-native licenses or reconfigured enterprise agreements.
- Testing and rollback readiness: functional, performance, and failover testing before full cutover.
- Training and change management: upskilling IT staff and adjusting operational runbooks.
- Decommissioning: retiring or disposing of legacy hardware and contracts.
- Steady-state cloud bill: the ongoing compute, storage, and network cost once migration ends.
Some of these scale with the size of the environment (steady-state spend, data transfer), while others scale with application complexity rather than raw size (testing, refactor-related labor). A ten-server lift-and-shift and a ten-server application with deep database dependencies can carry very different price tags even though the inventory count is identical.
One cost category dominates almost every budget. Indicative allocations put labor and professional services at 35% to 55% of total migration program cost, with parallel running at 15% to 30%, tooling and licensing at 5% to 15%, and data transfer or egress at 3% to 10%. That means the people doing the work, not the cloud invoice, usually decide whether a migration comes in on budget.
2. A practical step-by-step method to estimate your migration cost
Guessing at a migration budget from a rack count is how projects blow past their numbers. A tool-driven workflow, grounded in real utilization data, gets you much closer to the truth before you sign anything.
- Collect inventory and time-series utilization data. Pull a configuration management database export or an RVTools report, then layer in performance data over time rather than relying on provisioned capacity. AWS guidance recommends collecting seven days or more of utilization data, since provisioned capacity almost always overstates what a workload actually needs.
- Classify each workload by migration strategy. Sort applications into rehost, replatform, refactor, retain, retire, or relocate, and flag the ones with heavy integration or compliance complexity.
- Rightsize before you price. Apply the utilization data to size target instances correctly; skipping this step is the single most common reason estimator outputs run too high.
- Run provider calculators on the rightsized inputs. Tools like Google Cloud Migration Center’s quick TCO estimator and Azure Migrate’s business-case reports produce one- and five-year TCO views with per-workload pricing breakdowns, which you should export for stakeholder review.
- Add migration-program costs the calculators miss. Layer in professional services, temporary infrastructure, and parallel running on top of the steady-state figures, since none of the major provider tools automatically include internal labor or decommissioning costs.
- Factor in retained contracts and training. Add any software or hardware contracts you cannot exit early, plus the cost of retraining operations staff on the new environment.
- Build a multi-year TCO and cash-flow model. Ramp cloud costs up and ramp legacy infrastructure costs down wave by wave rather than assuming a single cutover date.
A few things to keep in mind as you move through that sequence:
- Provider estimators need accurate inputs: inventory and utilization precision drives the accuracy of everything downstream.
- Treat the first calculator output as a starting point, not a final number, since it will not reflect your specific contract terms.
- Revisit the model after each wave, since actual costs from early waves should sharpen the estimate for later ones.
3. Key cost drivers and common hidden expenses to watch for
The costs that blow up a migration budget are rarely the ones on the original spreadsheet. They show up in the gap between what a workload costs to run and what it costs to move.
- Labor and professional services: discovery workshops, wave engineering, and cutover support consistently account for the largest line item in the program.
- Dual-running overlap: running source and target environments at once, often for weeks per wave, to validate before fully cutting over.
- Replication and egress bandwidth: high change rates on source systems increase replication bandwidth, and replication concurrency across multiple workloads can inflate network costs quickly.
- Licensing differences: database, operating system, and enterprise application licenses often need renegotiation or repurchase for cloud terms.
- Testing and rollback exposure: validation environments and contingency plans for a failed cutover carry real cost, even when nothing goes wrong.
- Business continuity during downtime: any planned or unplanned downtime during cutover has an operational cost beyond the IT budget, from lost transactions to support escalations.
- Compliance and data residency work: regulated workloads often require extra security controls, audit trails, or regional data placement that add cost specifically during the transition window.
- Training and change management: new operational runbooks and staff upskilling rarely appear in the original estimate.
- Retained contracts and disposal: leases, support contracts, and hardware disposal fees that outlast the migration itself.
Pro Tip: Stagger replication jobs across waves instead of running them all at once. Limiting replication concurrency reduces both network cost and the risk of a backlog that delays cutover.
Mitigating most of these comes down to sequencing: moving simpler workloads first, limiting how many replication jobs run concurrently, and negotiating contract exit dates before the migration starts rather than after.
4. Budgeting and timeline: three sample scenarios
Seeing how the cost categories above play out in real scenarios makes the abstract numbers concrete. These are illustrative planning scenarios, not quotes, and your actual figures depend on your inventory and vendor pricing.
- SMB lift-and-shift: Say a business with 20 virtual machines and a handful of simple applications runs a straight rehost. Timeline typically runs 2 to 3 months, with labor and parallel running dominating the one-time cost and a modest steady-state increase once rightsized reserved instances are in place.
- Mid-size phased replatform: Say a company with 150 workloads splits the migration into three waves over 6 to 9 months, replatforming a handful of databases to managed services along the way. Costs rise relative to a pure rehost because of database re-engineering and a longer dual-running window across each wave.
- Large enterprise multi-wave modernization: Say an organization with over 1,000 workloads plans a 3 to 5 year program mixing rehost, replatform, and selective refactor. Payback depends heavily on sequencing, since staging simpler rehost and replatform work first and deferring complex refactors to later waves tends to accelerate the point where savings outweigh spend.
Ramp timing matters as much as scope. The recommended approach is to ramp cloud costs up at a constant rate while ramping existing infrastructure down at a constant rate, starting the cloud ramp-up one to two months before the on-premises ramp-down for each wave. Model that offset explicitly or your year-one cash flow will look worse than the program actually performs.
5. How to build a defensible business case and TCO for stakeholders
Executives signing off on a migration budget want more than a cloud bill comparison. They want to see the return, the risk, and the timeline laid out in financial terms they already use for every other capital decision.
The outputs a credible business case needs:
- Net present value and payback period, showing when cumulative savings exceed cumulative migration spend.
- Return on investment or modified internal rate of return, framed against the company’s existing capital thresholds.
- Year-over-year cash flow, reflecting the ramp-up and ramp-down timing discussed above rather than a single before-and-after snapshot.
- Steady-state run-rate comparison, showing the ongoing cloud bill against the legacy infrastructure cost it replaces.
Provider tools generate much of this automatically but not all of it. Azure Migrate’s business-case reports include an executive overview, current versus future cost breakdown, migration strategies mapped against standard cloud migration motions, and year-over-year cash-flow charts tied to migration progress assumptions. What they do not capture automatically is internal labor, business interruption, contract penalties, and decommissioning costs, so those need to be layered in manually before the numbers go to a finance committee.
For reporting cadence, pair an executive summary (the NPV, payback, and ROI headline) with a technical breakdown (per-workload sizing and strategy) and a detailed pricing breakdown (the exportable output from your provider calculator). Refresh the model after each wave rather than treating the original business case as fixed. For authoritative support beyond the free calculators, provider migration centers and partner-led assessments can validate assumptions before a large commitment, which matters most for the multi-wave enterprise scenario above.
6. Cost optimization levers during planning and execution
A handful of decisions, made early, determine whether a migration comes in near budget or well over it.
- Sequence simple workloads first. Front-loading rehost and replatform work and deferring complex refactors shortens the time to positive cash flow.
- Rightsize before committing. Use utilization data, not provisioned capacity, to pick instance sizes, then layer in reserved or committed-use discounts once the sizing is stable.
- Check license mobility. Some enterprise licenses transfer to the cloud at a discount; confirm this before buying new licenses outright.
- Limit replication concurrency. Running fewer parallel replication jobs reduces both network cost and the chance of a stalled wave.
- Set governance early. Tagging standards, cost allocation rules, and IAM guardrails put in place before migration starts make post-migration cost tracking far easier.
- Plan the operational handoff. Savings negotiated during migration disappear quickly without a team responsible for monitoring the cloud bill after cutover.
Pro Tip: Assign one person ownership of cost tagging before the first workload moves. Retrofitting tags after hundreds of resources exist is a project in itself.
7. NULLBIT perspective: how we estimate and manage migration cost for clients
We run cloud infrastructure and migration work across AWS, Azure, and GCP, and we treat cost modeling as part of the engineering work, not a separate exercise handed off afterward. Our typical engagement moves from discovery and inventory, to a proof of concept on a representative workload, to a full wave plan, to execution, with flexible engagement terms depending on project scope. For a smaller-scope pilot, our approach mirrors what we apply in legacy system modernization work, where a contained proof of concept de-risks the bigger commitment before it gets signed.
8. Author perspective: balancing financial goals and strategic modernization
Speed and modernization pull a migration budget in opposite directions, and most organizations default to speed without naming the trade-off. A rehost gets workloads off legacy infrastructure fastest and shows savings sooner, but it carries technical debt into the cloud unchanged. A refactor takes longer and costs more upfront, yet it can lower the steady-state run rate enough to pay for itself within the planning horizon. The right call depends on risk appetite and how much runway the business has before the legacy environment becomes a liability on its own. Keep migration in-house when the scope is narrow and your team already knows the target platform; bring in a partner when the wave plan spans multiple strategies or the business case has to hold up under executive scrutiny. My own read: sequence for speed first, then modernize only where the payback case is proven, not assumed.
— Matija
9. How NULLBIT can help: assessment and cost-control services
We offer cloud assessment services that combine inventory and rightsizing analyses with TCO estimates to support budget discussions with informed figures. Depending on scope, engagements run as a proof of concept, a fixed-price turnkey project, or ongoing time-and-materials support through our Agile Engagement and Fixed-Price Project models.
Reach out through our cloud infrastructure services page to scope an assessment for your environment.
FAQ
How much does 100 GB of cloud storage cost?
Cloud storage pricing depends on the provider, storage tier, and region, and varies enough between standard, infrequent-access, and archive tiers that there is no single reliable figure to quote. Run your specific workload through a provider calculator, such as Google Cloud Migration Center’s estimator, to get a price based on your actual tier and region.
How do you do a cloud migration?
A cloud migration starts with inventory and utilization data collection, followed by classifying each workload into a migration strategy such as rehost, replatform, or refactor. From there, teams rightsize workloads, run them through a provider calculator, sequence the work into waves, and execute with parallel running before full cutover, as outlined in AWS prescriptive guidance.
How much does data transfer cost during migration?
Data transfer costs depend on data volume, replication frequency, and how much the source system changes during migration, with high change rates increasing replication bandwidth and cost. Indicative allocations put data transfer and egress at roughly 3% to 10% of total migration program cost, though your actual figure depends on data volume and concurrency.
What should I check before choosing a migration partner?
Before choosing a migration partner, confirm they can produce a defensible business case with multi-year cash flow, not just a server-price comparison, and that they account for labor, parallel running, and decommissioning alongside the cloud bill. Also check whether they offer a proof-of-concept phase to validate assumptions on a representative workload before committing to the full program, which is how we structure proof-of-concept engagements.
Are Microsoft 365 or SaaS migrations priced the same way as infrastructure migrations?
SaaS and identity migrations, such as tenant-to-tenant Microsoft moves, follow a different cost structure built around licensing, mailbox and data volume, and identity reconfiguration rather than compute rightsizing. For a detailed checklist specific to that scenario, see this Microsoft 365 migration runbook covering tenant-to-tenant planning.
Sources
- Unlock Cloud Savings, A Rehost Migration Playbook (Part 1: Assess – cost components) — AWS
- Creating a directional business case — AWS prescriptive guidance
- Quick TCO Estimator — Google Cloud Migration Center
- Create a data-driven migration business case using AWS Cloud Value Framework — AWS
- How to view a business case — Azure Migrate documentation
Authoritative vendor tools and migration guidance to run your estimate
Once your inventory and utilization data are ready, run them through the tools built specifically for migration estimation rather than relying on generic cloud pricing pages. Use AWS prescriptive guidance when you need a directional business case that models on-premises costs, migration expenses, and multi-year cash flow together. Use Google Cloud Migration Center’s quick TCO estimator for scenario comparisons and one- and five-year TCO views once workloads are rightsized. Use Azure Migrate’s business-case reporting when you need an executive-ready report with year-over-year cash flow tied to migration progress.
If your migration also touches a public-facing web property, cross-check your plan against an SEO migration checklist so ranking signals survive the move alongside the infrastructure. Whichever tool you use, export the technical and pricing breakdowns for stakeholder review rather than presenting a single headline number, since the underlying detail is what finance teams will ask for first.
