AWS Migration Cost: What to Budget Before You Move

Most migration budgets fail because they compare one number with another: the current server bill against the target monthly AWS estimate. A migration costs more than the steady-state environment you end up with. You also pay to find out what you have, to run old and new environments side by side, to move the data, to test, to cut over, and to tune the result once real traffic arrives.

Quick answer: budget the migration as a project with phases, not as a monthly run rate. Include discovery, the target environment, a period of parallel running, data movement, migration tooling, engineering time, testing and cutover, and post-cutover optimization, then hold a contingency for dependencies you have not found yet.

The cost categories at a glance

Phase	What you are paying for	Common blind spot
Discovery and assessment	Inventory, dependency mapping, performance baselines, security and licensing review	Treated as free because it is "just analysis"
Target environment	Compute, storage, databases, networking, backups, monitoring, security services, support	Pricing one server instead of the full architecture
Parallel running	The old environment and the new one at the same time, plus test and staging copies	Assuming the overlap is a few days
Data movement	Transfer, replication, and the network path used to move it	Large databases and file stores that take weeks, not hours
Migration tooling	Replication infrastructure and test or cutover instances	Charges that continue while servers replicate
People	Your engineers, a partner or vendor, project management, change windows	Counting only external invoices
Testing and cutover	Functional, performance and failover tests, rollback capacity, out-of-hours support	Cutting the test budget when the schedule slips
Optimization	Rightsizing, cleanup, savings commitments after usage stabilizes	Ending the budget at cutover

Start with two honest baselines

Build the current cost per workload, not per server: hosting or hardware, licences, bandwidth, backups, monitoring, support contracts, and the staff time spent keeping it running. Then build the target cost for the same workload on AWS, using the full architecture rather than the one instance that replaces your server.

The AWS Pricing Calculator is the right place for the AWS side, and our cost calculator can give a quicker first estimate for common services. For a sense of what a small environment costs to run, see How Much Does AWS Cost for a Small Business?.

Discovery: pay for it before you commit

You cannot price what you have not inventoried. Discovery covers servers and databases, what depends on what, how much traffic and storage each workload really uses, which software licences move with you, and which security and compliance obligations apply. Skipping it moves the cost into the migration itself, as surprises. A structured migration readiness assessment is a sensible first line in the budget, and the pre-migration checklist shows what it should cover.

The target environment is more than compute

A common mistake is to price the instance that replaces your server and call it the target. A realistic target estimate includes:

• compute and storage, sized from measured use rather than from the old hardware
• the database service, its backups, and any standby or replica you want
• networking: load balancers, NAT, endpoints and data transfer. NAT charges are easy to miss, so see NAT Gateway vs NAT Instance
• logs, monitoring and alerting storage
• backup retention and disaster recovery if you are adding it for the first time
• security services, support plan and any tooling you will need to operate the environment

Parallel running costs real money

During a migration you usually run the source environment, a target environment under test, and the target environment that carries production after cutover. The longer you keep the source as a rollback option, the more you pay twice. Budget the overlap using a realistic schedule and ask what happens to the estimate if cutover slips by two weeks. Plan the rollback capacity too: a rollback you cannot afford to keep available is not really a rollback.

Data movement and migration tooling

AWS generally does not charge for data transferred in from the internet, but charges apply for data moving out, between Regions, and between Availability Zones, and the path you use to move large volumes (a VPN, Direct Connect, or a physical transfer device) has its own costs. Confirm the current rules on the AWS pricing pages for the services you will use. For large databases or file stores, estimate how long the initial copy and the final synchronization will take, because that sets how long you pay for the overlap.

If you use AWS Application Migration Service (MGN), which AWS now brands as AWS Transform MGN, note how it is priced. AWS describes a free period for the service, but charges continue for the replication infrastructure it provisions in your account, and launching test and cutover instances incurs normal EC2 and EBS charges. Check the current terms for the length of the free period. Other tools, such as database migration services, have their own pricing, so list every tool you plan to use and price it individually.

People, testing and cutover

Engineering time is usually the largest line item that nobody writes down. Include your own engineers, any partner or vendor, project management, and the out-of-hours work that cutover windows require. Add the testing you actually want to run: functional checks, performance tests against production-like load, and a rehearsal of the cutover and the rollback. Testing is the first thing cut when a schedule slips, and it is the thing that protects the migration.

Optimization starts after cutover

Do not buy long commitments such as reserved capacity or savings plans on the first estimate. Usage rarely matches the plan in the first weeks, and you will usually find oversized resources and leftover test environments. Budget time and money for a post-cutover review: rightsize, remove temporary resources, tune storage and data transfer, and only then commit. The AWS cost audit checklist is a good structure for that review.

Contingency

Every migration has dependencies nobody mentioned: a hard-coded IP address, an undocumented scheduled job, a licence that does not transfer. Hold a contingency line, and size it by how many unknowns remain after discovery rather than by habit. The more complete your discovery, the smaller the contingency you can defend.

Common mistakes

• Comparing one server price with a complete target architecture.
• Buying commitments before migration behaviour is known.
• Assuming parallel running lasts days when the data copy takes weeks.
• Leaving out internal engineering time.
• Ending the budget at cutover instead of funding stabilization.

Verify with AWS

• AWS Pricing Calculator
• Migration portfolio assessment
• AWS Application Migration Service pricing
• Amazon VPC pricing

The practical takeaway

A credible migration budget covers the whole project: discovery, the full target architecture, the overlap, the data, the tools, the people, the testing, and the tuning afterwards, with a contingency sized to what you still do not know. Present it as a range tied to stated assumptions and revisit it after discovery. If you want help scoping a migration, see our AWS cloud migration service, and you can book a free AWS audit to review your current environment first.

Related reading: AWS Cloud Migration Checklist, AWS Migration Readiness Assessment, AWS Cost Audit Checklist