Cloud Migration Costs: What to Budget Before You Move

Cloud migration cost is the total cost of moving workloads into a cloud, between clouds, or back out: the one-time cost of the move, the period in which old and new environments run side by side, and the ongoing cost of the new environment once it settles. The last of these is the easiest to model with a pricing calculator; the first two are the easiest to leave out.

One-time costs

• Moving the data. Ingress is free on Google Cloud and Azure, but leaving the source is not: egress from the old cloud or data center is charged. AWS includes 100 GB per month of free transfer out to the internet across all services and regions (except China and GovCloud), and for customers moving off AWS it offers free data transfer out for the migrated data on request through AWS Support, reviewed per account and delivered as credits.
• Transfer tooling. Managed services are priced per unit moved. AWS DataSync, for example, charges a flat per-GB fee for data copied between storage locations, plus a per-execution fee for tasks in Enhanced mode.
• Rework. Changes to make applications run well on the target: configuration, networking, identity, and sometimes re-architecture. This is engineering time, and it belongs in the budget alongside the cloud charges.
• Licensing. Moving licensed software can change what you pay for it; check each vendor’s terms before assuming the current licences carry over.

The overlap period

During migration, both environments run. Source hardware, contracts, and support continue until decommissioning, while the target environment is already billing, and is easy to oversize before production metrics exist. The longer the overlap, the larger this line. Plan decommissioning dates as part of the migration, not after it.

The new steady state

A lift-and-shift reproduces on-premises sizing in the cloud, where capacity is billed by the hour. Three effects follow:

1. Servers sized for peak on-premises run at peak cost around the clock unless they are resized or scheduled.
2. Non-production environments that were free to leave on in a data center now bill every hour they run.
3. Traffic patterns change: services split across availability zones or regions start paying data transfer charges that did not exist on a flat internal network.

Commit after you measure

Commitments such as reservations, Savings Plans, and committed use discounts lower the rate for steady usage, but they bill for the full term whether or not the capacity is used. Buying them against pre-migration estimates risks committing to capacity that rightsizing or scheduling later removes. Measure actual uptime and size first, then commit to the baseline that remains.

A post-cutover checklist

• Tag everything with owner and environment on arrival.
• Put non-production environments on schedules in week one.
• Collect enough utilization history to rightsize, then resize.
• Decommission source systems on the planned date.
• Only then size commitments.

Where ZopNight fits after cutover

ZopNight discovers the new estate across AWS, Google Cloud, and Azure accounts and shows a rack-rate cost for each resource immediately, adding billed cost once billing sync is configured. Its recommendations wait for evidence: schedule recommendations need at least 18 days of recent metrics, and commitment recommendations are priced from measured uptime, reporting savings as unknown rather than assuming 100% uptime when none has been measured. That makes them a reasonable guide to when a migrated workload has settled enough to commit.

Related: rightsizing methodology, cloud inventory, and reserved instances.