Cloud migration costs: line items, surprises, and how to estimate any infrastructure move

Key takeaways

• Cloud type and architecture are the largest line items in enterprise estimates.
• The migration pattern you choose sets your cloud migration price.
• The costs that break budgets sit outside the invoice: labor, running both environments at once, data egress, training, and 20-30% early cloud waste.
• Public cloud is not automatically the cheapest destination for a business with steady, predictable usage.

What cloud migration costs in 2026

In 2026, industry standards put cloud migration costs for a single workload at roughly $3,000 to $8,000 to move, all in. That number covers discovery, replication, network and security setup, identity mapping, application validation, cutover rehearsal, the cutover itself, decommissioning, and program overhead. Tooling is a small part of it, but labor is most of it.

Run the $3-8K estimate against your workload count and you have a starting figure. Twenty-five workloads puts you between $75,000 and $200,000. Then add the environment you are moving into, which prices separately.

Two types of cloud migration costs

There are two types of cloud migration costs.

The first type covers the move itself. Discovery, design, migration work, testing, cutover, and the period where you run two environments at once. These costs are temporary, and they start when the service is activated. 

The second covers running what you moved. Compute, storage, networking, licenses, support, and whoever manages the environment. These costs are ongoing, and they start immediately.

Estimates fall apart when teams build one number out of both stacks. Finance approves a migration budget, the project finishes, and then the monthly infrastructure bill arrives. Keep them in separate columns from the first meeting.

Per-workload migration cost, decomposed

Here’s what it might cost to move one workload, line by line. Figures are per workload and assume a rehost or light replatform. Complex refactors price separately.

Line item	What it covers	Typical	Range
Discovery and dependency mapping	Finding all workloads that need to be moved and documenting what it takes to move them	$400	$250 to $600
Migration agent setup	Installing and configuring replication tooling on the source system	$250	$150 to $400
Data replication	Copying the workload across, including repeat syncs while the source keeps changing	$200	$100 to $400
Network and security configuration	Subnets, routing, firewall rules, and access paths in the destination environment	$500	$300 to $800
Identity and access mapping	Recreating accounts, permissions, and service credentials so the right people and systems still get in	$300	$150 to $500
Application testing and validation	Confirming the workload continues working after the move	$800	$450 to $1,300
Cutover planning and rehearsal	Writing the runbook, scheduling the window, and practicing the switch before you do it live	$600	$350 to $900
Cutover execution	The switchover itself, plus the support standing by	$800	$450 to $1,200
Decommissioning	Shutting down the source system and ending the licenses and contracts attached to it	$200	$100 to $350
Project management overhead	Coordination, status reporting, and the meetings that keep a multi-workload move on schedule	$600	$350 to $900
Contingency (15%)	Additional workload found during discovery, [etc, etc]	$700	$400 to $1,100
Total per workload		$5,350	$3,050 to $8,450

Two things this leaves out:

1. The double-run period, when you pay for both environments at once. That cost attaches to your project timeline rather than your workload count. A four-month project and an eight-month project move the same workloads at the same per-workload price, but the second one costs more.
2. The landing zone and environment setup, the work that happens before any workload moves. That prices once, not per workload.

Cost by migration pattern: the six Rs

The six Rs help you decide what happens to each application in a migration. 

1. Rehost, or sometimes called lift-and-shift

$200-$500 per virtual machine.

This is the most common scenario for most workloads. You copy the application to the new environment. No code changes, minimal redesign, fastest calendar time, most economical. Rehosting gets you off the old hardware quickly, which is helpful when a lease expires or a support date lands on you.

2. Replatform

$500-$1,500 per workload.

You make targeted changes without rewriting the application. Moving to a managed database, swapping a file share for object storage, or putting a web tier into containers. More effort than rehosting, lower ongoing cost, and considerably less risk than a rewrite.

3. Refactor, or re-architect

$10,000+ for one complex application.

This is a genuine rewrite. New architecture, new code, and new team. Refactoring produces the best long-term economics and the largest upfront bill. It takes months (rather than weeks) per application.

4. Repurchase

You drop the application and buy a SaaS product that does the same job. The migration cost approaches zero and the subscription becomes a permanent run cost. Data extraction and user retraining become the real effort.

5. Retain

Some systems stay where they are, for now or forever. 

6. Retire

Every environment carries workloads nobody uses: the reporting server from a project that ended, the test environment somebody spun up in 2021, the application two people still have bookmarked. 

Retiring those before you move saves you the full migration price plus years of run cost. Do this first, before you price anything else.

Bonus: Architecture and landing zone setup

$125,000-$510,000 for an enterprise foundation.

Before any workload moves, somebody builds the environment it moves onto: network design, security boundaries, identity, access control, monitoring, tagging, and the governance rules that keep costs from drifting. It’s frequently the largest single line in the estimate.

Smaller businesses pay a smaller version of the same bill. The work doesn’t disappear because the company is smaller.

Hidden costs

Cloud vendors quote what they sell, but hidden costs can break a migration budget. Labor, parallel environments, and data transfer sit in your project budget, not a proposal, which is why they surface after the estimate is already approved. Here’s the rest of what you need to plan for.

Compliance and audit work

Control mapping, evidence gathering, revalidation, and updating the documentation you hand to auditors and insurers all take time, and much of it can’t start until the environment exists.

If your certification renewal falls inside your migration window, move one of them.

Labor and engineering

The largest hidden cost in most migrations is people.

Somebody has to inventory every workload, map which system talks to which other system, and find the undocumented connections. Then testing, then cutover planning, then the cutover itself.

If you run a company with one or two IT generalists, that work lands on the person who already keeps everything running. They do the migration on top of their actual job, and the project timeline stretches to fit whatever hours they have. 

You could bring in outside help, if you’re willing to swap salary hours for consulting hours.

The double-run period

For a stretch of the project, you pay for the old environment and the new one at the same time. Old hardware, old licenses, old support contracts, plus everything you just built.

If a four-month project stretches to eight months, your parallel overhead doubles. Thirty-eight percent of companies see their migrations delayed by more than a full quarter, and those migrations run about 14% over planned spend. 

Budget this window explicitly, with a realistic length, and then add a month.

Data movement and egress

Moving data out of a cloud platform carries a per-gigabyte charge that most estimates miss entirely. Microsoft publishes Azure egress at $0.087 per GB for the first 10 TB each month, dropping to $0.083 and then $0.07 per GB as volume rises. AWS and Google Cloud price in the same neighborhood. That puts a terabyte at roughly $70-$87, so 400 TB of data becomes a five-figure line before anyone touches an application.

Egress also keeps costing after the migration ends. If your new environment regularly sends data somewhere else (like a partner, a backup target, an analytics platform, or another cloud), that traffic bills every month. 

Map the data flows before you pick a destination.

Training and certification

Cloud platform training runs $1,000-$5,000 per technical employee.

Post-migration waste

Flexera’s 2026 State of the Cloud Report puts wasted cloud spend at 29%, and 2026 marks the first year in five that the figure rose rather than fell.

Someone sizes everything for safety during the migration. Then the project ends, the team moves on, but nobody goes back to right-size it. Six months later you pay for capacity you’ve never used.

Decommissioning

Old hardware, contracts, licenses, and vendor relationships keep billing until somebody formally ends them. Decommissioning slips because it feels finished once the workloads move, but the invoices will keep arriving.

Common budget mistakes

Five patterns account for most cloud migration budget mistakes.

Incomplete discovery: You can’t price what you haven’t inventoried. Flexera ranks understanding application dependencies as the top migration challenge, cited by 54%of organizations.

Pricing the move but not the year after it: A migration budget that stops at cutover creates a surprise for finance in month two.

No owner for cost: IT builds the estimate, finance approves it, and then nobody holds the number during the project. 

Under-estimating the double-run period: Every week of delay costs a week of double-run. Slip is the most expensive variable in the entire model. 

Expecting savings on day one: Savings arrive after right-sizing, after decommissioning, and after somebody enforces governance. That means months rather than weeks.

How to build an estimate

There are six steps to building an estimate you can hand to finance with confidence. 

1. Inventory what you run. Every server, application, database, and dependency. Mark what you can retire before you go further, and be aggressive about it.

2. Assign a pattern to each workload. Rehost, replatform, refactor, repurchase, retain, or retire. One pattern per workload.

3. Price the move. Multiply the pattern costs across your workload list, then add the landing zone and architecture work as a separate line.

4. Price the first 12 months of running it. Compute, storage, networking, egress, licenses, support, and operations. This column is permanent, so treat it with care.

5. Add the double-run window. Name a realistic project length, then price the old environment for that period plus a buffer.

6. Model three scenarios. Likely, best case, and the one where the timeline slips by half. 

A worked example

Say you run 25 workloads on hardware approaching end of support:

Line item	Detail	Low	High
Rehost	16 workloads × ~$400	$6,400	$6,400
Replatform	4 workloads × ~$1,000	$4,000	$4,000
Retain in place	1 workload	—	—
Retire	4 workloads	—	—
Workload migration subtotal		$10,400	$10,400
Landing zone and security setup	Network design, compliance config	$25,000	$60,000
Project labor	Discovery, testing, PM, cutover (~200 hrs)	$15,000	$30,000
Double-run	4 months parallel environments	$20,000	$40,000
Total project cost	Before first month of run cost	$70,400	$140,400

The workload migration line is less than 15% of the total.

Cloud type and migration costs

There are different types of clouds, and the one you land on changes what a migration costs. Most cost guides on this topic assume you’re moving to a hyperscaler, but that assumption deserves more scrutiny.

Public cloud

Public cloud pricing rewards demand that spikes and collapses. You pay a premium for the ability to scale up in minutes, and that premium makes sense if you  scale up in minutes.

If your business runs roughly the same load every day, you’re paying for flexibility you never use. On top of that, consumption billing means the invoice moves month to month even when your usage doesn’t, and explaining why takes somebody who understands the billing model in detail.

To be clear about where public cloud genuinely wins: unpredictable demand, seasonal businesses, rapid experimentation, and anything that needs to be in 12 regions next quarter. If that describes you, hyperscalers are the right answer.

Buying your own hardware

Buying hardware means capital you spend now, a procurement cycle, and five more years of owning equipment that must be managed by one or more engineers.. The useful question for a finance lead is what the equipment costs once you include the person who maintains it.

Hosted managed cloud

A hosted managed cloud could be single- or multi-tenant, but either one gives you an isolated environment on hardware somebody else operates, patches, and monitors, billed at a predictable monthly figure.

You get the control that comes with having your own environment. You skip the capital, procurement cycle, and ownership. Steady workloads, older software, and data that needs to sit apart from other companies fit this model well.

	Public cloud	Hosted managed cloud (multi-tenant)	Hosted private cloud	Your own hardware
Also called	Hyperscaler, IaaS	Virtual private cloud	Single- tenant	On- premises, colo
Who owns the hardware	Your provider	Your provider	Your provider	You do
Who else is on it	Thousands of unrelated customers	A few other customers, each isolated	Nobody	Nobody
Isolation boundary	Hypervisor and virtual network	Hypervisor, dedicated network, separate storage	Physical hardware	Physical hardware
Who operates it	You do	Your provider	Your provider	You do
How it bills	By consumption, varies monthly	Fixed monthly, plus overages	Fixed monthly	Capital, then power, space, and salary
Best for	Demand that spikes and collapses	Steady workloads needing isolation	Steady workloads where separation is required	Businesses with capital, space, and staff

Who runs your cloud after you move?

Don’t forget to figure out who is in charge of daily cloud operations after the migration. Right-sizing after migration stops 20-30% waste, decommissioning ends the double-run, patching, monitoring, backup verification, incident response, and producing evidence when an auditor asks all land on a named human being.

For a business with no IT department, or one or two generalists who handle everything from the phone system to the firewall, that can be a problem. The hardware is affordable. The person who can build, secure, patch, monitor, and prove  to an auditor is not, and at that company size the role often doesn’t exist as a job anyone can reliably fill. What Nexcess does

Nexcess Managed Cloud gives you dedicated, isolated infrastructure, built on Nutanix, that we design, migrate, operate, patch, and monitor. When something breaks, you call us and we answer. One contract, one team, one number.

You get the control and predictable monthly cost of having your own environment, but nobody at your company has to become a sys admin.

Three best things about how we handle the migration.

1. We own the network part of the move. For customers already with us, the move never leaves our network and existing connections carry through untouched. For customers coming from outside, we handle the heavy lifting of mapping standard network configurations to your new environment.
   
2. The move is built to happen once. Your systems keep running while we copy them across. The switchover is a short planned window. Your old environment stays intact, so if something needs putting back, we put it back.
   
3. The same team stays after cutover. No handoff between an agency that designed it, a vendor that migrated you, and the support team who picks up the phone six months later.

Cloud migration cost FAQs