Cloud Migration Cost: How to Estimate It

A cloud pricing calculator can tell you what a server might cost next month. It cannot tell you the full cost of moving your business to the cloud.

The migration also needs discovery, architecture, application changes, data transfer, testing, and a controlled cutover. For part of the project, you may pay for both the old environment and the new one.

Then the migration ends, but the cloud bill continues.

A useful cloud migration cost estimate separates those amounts. It shows the investment required to move, the cost of the transition, and the ongoing cost of running the target environment.

Here is how to build that estimate, with a worked example and a template you can use for your own workloads.

Quick answer

Estimate cloud migration cost in three parts:

1. One-time migration work: assessment, architecture, engineering, data migration, testing, cutover, and handover.
2. Transition costs: temporary environments, replication tools, connectivity, overlapping contracts, and the period when both environments operate.
3. Ongoing cloud costs: compute, databases, storage, networking, security, backups, monitoring, licences, and operations.

Add a contingency reserve for identified uncertainty. Keep it separate from expected spending.

Migration project funding = one-time delivery costs + transition costs + contingency reserve.

Total cost over the decision period = one-time delivery costs + transition costs + ongoing costs during that period.

Include contingency in the funding request, but only count it as spending in a forecast scenario where you expect to use it. Do not count the same cloud resources in both transition and ongoing costs.

There is no useful universal price per server. A standalone application with a documented deployment process differs from a database with tightly connected applications and a short downtime window.

Start with a workload inventory

Before estimating prices, establish what is moving.

Count applications and dependencies, not just machines. Ten virtual machines might support one interconnected business system or ten independent services. Those are different migration projects.

For each workload, record:

Use a measurement period that includes normal activity and relevant peaks. A quiet week can miss a month-end reporting workload or a seasonal sales event.

Record missing information as an assumption with an owner. Missing data should not silently become zero cost.

Choose the migration approach before pricing it

The approach changes both engineering effort and the future operating bill.

Rehost

Move the workload with limited application changes, often to cloud virtual machines.

This can limit changes to the application, but the work still includes networking, identity, backups, monitoring, deployment, and testing. Moving an oversized machine unchanged can also preserve unnecessary capacity costs.

Replatform

Change selected components while keeping much of the application intact. For example, move a database to a managed service or change the deployment platform.

Include compatibility checks, configuration changes, performance testing, and operational training. A managed service can shift work away from your team, but it still has a service bill.

Refactor or rearchitect

Change the application more substantially to meet the target requirements.

Estimate this as software engineering work as well as migration. Define the specific changes and acceptance criteria. “Make it cloud native” does not establish a delivery boundary.

Retain, retire, or replace

Some workloads should stay where they are. Others may no longer be needed or may be better served by a commercial product.

Keep retained costs in the overall business case. Record retirement savings only when the related spending can actually stop.

AWS migration business-case guidance discusses comparing current and target costs, sizing resources from usage, and estimating migration effort by workload complexity.

For the broader application decision, see Modernize or Replace Legacy Software?.

Calculate one-time migration work

Build an effort estimate for each workstream. Assign hours or days, a delivery rate, an owner, and an assumption.

Labor cost = estimated effort × fully loaded delivery rate.

For internal employees, distinguish the value of staff time from additional cash spending. Internal effort still consumes capacity even when it does not require a new invoice.

Discovery and dependency mapping

Include inventory collection, stakeholder interviews, performance measurements, and investigation of undocumented connections.

An application may depend on a shared file path, a fixed IP address, or a scheduled export that no longer appears in current documentation. Finding those connections is migration work.

Cloud foundation and architecture

Include account or subscription structure, identity, network design, permissions, logging, security controls, and cost allocation.

Some foundation work supports several workloads. Estimate it once at the shared-platform level, then allocate it for reporting if needed. Do not add the full amount to every application.

Application and infrastructure changes

Include infrastructure configuration, deployment automation, configuration changes, integrations, and any required operating system or database changes.

List upgrades and refactoring separately. Otherwise, a migration estimate can become an undefined modernization program.

Data migration

Include extraction, cleanup where required, conversion, transfer setup, replication, validation, and reconciliation.

Data migration cost is more than a price per gigabyte. A database engine change can require schema and query changes. A collection of small files can behave differently from the same volume in a few large files.

Testing, cutover, and handover

Include application tests, performance checks, security verification, backup restoration tests, and user acceptance.

Budget for a cutover rehearsal and a rollback plan. Document who approves the switch and what conditions stop it.

Handover should establish operating instructions, alert ownership, access, and support responsibilities.

Estimate data transfer and migration tooling

Map the actual data path before applying a rate:

Source → connection → transfer or replication tool → destination.

For every stage, check which service or supplier charges and what the billing unit means. Include:

• Source-side export or outbound transfer charges
• Transfer service or replication charges
• Temporary compute and storage
• Connectivity and network equipment where required
• Destination storage and request charges
• Validation, repeat transfers, and incremental updates

Do not assume that an inbound-transfer allowance makes the entire migration free. Source providers, transfer tools, storage services, and network paths have separate terms.

For example, AWS DataSync pricing describes per-gigabyte transfer charges, an additional execution charge for Enhanced mode, and other applicable service costs. Check the selected mode and transfer path before building an estimate.

Also estimate duration. Moving 20 TB once differs from transferring 20 TB and keeping a busy database synchronized for six weeks.

A useful planning formula is:

Data migration cost = engineering effort + transfer and tool charges + temporary infrastructure + validation effort.

Use a pilot transfer to measure throughput and operational effort before committing to a large migration window.

Budget for running two environments

During transition, the source environment may remain available while the cloud environment is built, tested, and synchronized.

The old environment does not become free when the new one starts.

AWS describes this temporary spending increase as a migration “double bubble.” Its guidance includes overlapping environments, migration tools, transfer costs, and existing infrastructure commitments.

Build a calendar showing when each cost starts and ends. Record:

• Cloud environments used before production cutover
• Source infrastructure that remains active
• Replication and testing tools
• Contracts that cannot end immediately
• The rollback period
• Decommissioning and secure data disposal work

Avoid a common accounting error: adding the full old monthly bill as an extra migration expense when it already appears in the transition-period forecast.

For the full cash forecast, include both environments during overlap. For incremental migration funding, separate existing baseline spending from new spending caused by the migration.

Estimate ongoing cloud costs from the target design

Price the environment you intend to operate, with the availability and performance the business requires.

A single virtual machine is not a fair comparison with a target architecture that includes database redundancy, tested backups, and disaster recovery.

Microsoft's cloud cost-estimation guidance ties estimates to architecture, service selection, workload usage, and operational requirements. The principle applies when evaluating any provider.

Use a cost model that includes these categories:

Check the region, currency, taxes, discounts, and licence eligibility. Record them beside the estimate.

Do not apply a generic discount across every line. A commitment may cover only eligible usage, while storage, transfer, or supporting services remain separately billed.

Use calculators for service costs

Provider calculators help estimate the bill for a defined architecture. They do not replace an effort estimate or a transition plan.

Useful starting points include the AWS Pricing Calculator, Azure Pricing Calculator, and Google Cloud Pricing Calculator.

Save the configuration and the estimate date. Record service sizes, usage assumptions, region, availability options, and purchase terms so another person can reproduce the result.

For existing workloads, compare the calculator inputs with measured usage. For a new architecture, validate important assumptions through a pilot or load test.

Treat credits as temporary funding support. Show costs before and after credits so the operating budget remains useful when they expire.

A worked cloud migration cost estimate

Consider a constructed example: a business moves one web application, its database, and 2 TB of files to a cloud provider.

Assume the application needs configuration changes and a database compatibility check, but no major rewrite. The estimate includes two months of preparation and overlap, followed by ten months of normal cloud operation.

All figures below are hypothetical planning inputs in USD. They are not market averages, provider quotes, or Corpvance prices.

One-time delivery costs

Transition and ongoing costs

Assume the following amounts come from separately documented planning allowances:

The temporary cloud allowance covers the cloud resources used before cutover. The $600 line covers transfer and tooling charges only. Engineering and reconciliation effort already appear in the delivery table.

Total first-year funding

The first-year period starts when migration work begins. It contains two transition months and ten months after cutover.

• One-time delivery: $38,000
• Transition costs, including existing hosting and the exit fee: $8,000
• Cloud services and operations after cutover: $20,000
• Expected first-year spending: $66,000
• Separate contingency reserve: $6,000
• First-year funding allowance: $72,000

The $6,000 reserve is an example allocation, not a recommended percentage for every project. Set your reserve against specific unresolved risks.

After the first year, the assumed ongoing run rate is $2,000 per month, or $24,000 per year, before growth or price changes. A full twelve months after cutover is a different reporting period from this example's first project year.

Compare migration with the cost of staying

A migration estimate does not establish whether migration is a good investment. You also need a comparable forecast for keeping the current environment.

Use the same period, workload volume, support scope, and availability requirements on both sides.

For the example above, assume staying costs $2,000 per month with no planned capital purchase. That gives a three-year baseline of $72,000.

Migrating produces expected spending of:

• First project year: $66,000
• Second year: $24,000
• Third year: $24,000
• Three-year expected total: $114,000, excluding unused contingency

Under those assumptions, migration costs $42,000 more over three years. It does not produce a direct cost-saving case.

The decision might still depend on capacity, service reliability, or another business requirement. Present those benefits separately and support them with evidence. Do not invent infrastructure savings to justify a preferred architecture.

For projects with lower ongoing costs after migration, a simple payback estimate is:

Payback months = incremental transition investment ÷ monthly operating savings.

This assumes savings begin at the chosen starting point and remain constant. Use a month-by-month cash flow when the migration is phased, contracts end at different times, or savings change over time.

For a broader investment framework, see How to Build the Business Case for Legacy Modernization.

Cloud migration cost estimation template

Copy this structure into a worksheet or project brief.

For each cost line, add the quantity, unit, rate, duration, source, and owner. Mark whether the amount is an observed cost, a supplier quote, a calculator result, or an assumption.

That distinction makes the estimate easier to update after discovery and pilot testing.

Test the assumptions that can change the budget

A single total hides uncertainty. Build a base case and a higher-cost case around specific changes.

Examples include:

• The overlap period extends by one month.
• Data volume or daily changes exceed the inventory.
• A database requires application changes.
• A required service tier costs more than the initial choice.
• A licence cannot transfer to the target environment.
• Network traffic is higher than expected.
• A contract renewal occurs before decommissioning finishes.

In the worked example, an extra overlap month at the assumed rates adds $3,200 in hosting and temporary cloud use, before additional labor or tooling. That is a sensitivity calculation, not an automatic charge.

Assign someone to resolve each material assumption. Update the estimate when the evidence changes.

Common mistakes that make migration estimates unreliable

Pricing only production compute

The operating environment also needs data services, networking, protection, monitoring, and supporting environments. Start from the architecture rather than a single server price.

Assuming the migration removes existing contracts immediately

Leases and software agreements may continue after cutover. Put their actual end dates into the forecast.

Mixing migration with an undefined rewrite

Separate mandatory migration changes from optional modernization. Give each its own acceptance criteria and budget.

Counting staff time as immediate cash savings

Reduced operational work may create capacity for other tasks. It only reduces spending when the relevant cost can actually be removed.

Omitting decommissioning

The migration is financially incomplete while unused resources and avoidable contracts remain active. Assign an owner to verify retirement and billing changes.

Treating a forecast as a fixed bill

Usage, service configurations, exchange rates, and supplier terms can change. Keep the estimate date and assumptions visible, and compare the forecast with actual spending after launch.

Planning a cloud migration with Corpvance

A useful scoping conversation starts with your workload inventory, the reason for moving, the required service levels, and the costs you already pay.

From there, define the smallest migration scope that meets the business requirement. Separate application modernization from infrastructure movement, and connect each migration phase to a clear acceptance decision.

Explore Corpvance's Cloud & Infrastructure and Software Engineering services, or talk to the team about reviewing your migration requirements.

Frequently asked questions

How much does cloud migration cost?

The cost depends on the workloads, migration approach, data movement, application changes, transition period, and target architecture. Estimate delivery effort and temporary costs separately from the ongoing cloud bill. The worked example in this guide shows the calculation, not a standard project price.

What is included in a cloud migration cost estimate?

Include discovery, architecture, cloud foundation, application changes, data migration, testing, cutover, handover, and decommissioning. Also account for temporary tools, overlapping environments, continuing contracts, ongoing cloud costs, and a separately stated contingency reserve.

How do you estimate data migration cost?

Measure the data volume, file or record characteristics, change rate, transfer path, and available migration window. Estimate engineering and validation effort, then add applicable source, tool, network, storage, and request charges. Validate key assumptions with a pilot transfer.

Is moving to the cloud always cheaper?

No. Compare total costs over the same period with equivalent workload and service requirements. Migration can increase spending when transition work is substantial, existing contracts continue, or the target architecture provides capabilities the old environment did not have.

Does a cloud pricing calculator include migration labor?

A service calculator estimates selected service consumption. It does not automatically capture your discovery work, application changes, testing, training, or cutover effort. Add those items through a separate project estimate.

How do you reduce cloud migration costs?

Remove unnecessary scope, measure actual resource usage, test uncertain integrations early, and plan contract exits. Reuse shared foundation work, control temporary environments, and verify that retired resources stop generating charges. Assess commitments only after understanding the usage they cover.

Estimate the transition as carefully as the destination

A credible cloud migration budget shows what moves, how it moves, how long the transition lasts, and what the business pays afterward.

Build the estimate around those inputs. Then test the assumptions with the largest financial impact before committing to the full migration.

Talk to Corpvance about scoping a cloud migration around your applications, data, and operating requirements.