Cloud Migration Costs: Budgeting an On-Prem → AWS Move Without Surprises

01 · The six categories

Where cloud migration money actually goes

1. Target-state cloud spend. The steady-state AWS bill: compute (EC2, containers, serverless), storage (EBS, S3, databases), and data transfer. This is the only line most estimates include — and it's the one most likely to be wrong, because it's estimated from on-prem utilization without accounting for cloud pricing dynamics (on-demand vs. reserved vs. spot, right-sizing, managed service premiums).

2. Migration execution. The engineering work: discovery and assessment, landing zone setup, application migration waves, data migration, testing, cutover. Budget as engineering time — internal, partner, or both. This is typically 30–50% of first-year total cost and the line most likely to overrun when discovery was shallow.

3. Dual-running. Operating both environments during transition. Every month of overlap is paid twice: two infrastructures, two monitoring stacks, extended license coverage. This is the hidden line that breaks budgets — explicitly budget dual-run per wave and incentivize teams to decommission fast.

4. Licensing delta. What changes in your license position: BYOL opportunities (SQL Server with Software Assurance on EC2), license-included managed services (RDS SQL Server at roughly 2.6x equivalent PostgreSQL compute — varies by region and instance class; check current AWS pricing before budgeting), and the chance to eliminate licenses entirely (PostgreSQL migrations — see our licensing cost guide). Model this per workload; it swings both directions.

5. Organizational cost. Training, new operational skills (cloud networking, IAM, FinOps), and the productivity dip during transition. Real, budgetable, and almost always omitted. A team learning AWS while migrating to AWS is slower — plan for it instead of being surprised by it.

6. Risk reserve. 15–25% contingency on the execution budget. Migrations discover things — the undocumented dependency, the application that can't tolerate latency, the compliance requirement nobody mentioned. The reserve isn't pessimism; it's the historical average.

02 · The 6 Rs

Your estate needs all six strategies

Rehost (lift-and-shift): fastest, lowest change, highest long-term cost. Use for: workloads with a hard deadline (end-of-support, data center exit) where speed beats optimization. Never the default strategy — it's the emergency one.

Replatform: move with targeted improvements — managed database instead of self-hosted, containers instead of VMs, without re-architecting. The best value-for-effort for most workloads: meaningful operational improvement at moderate cost.

Repurchase: move to SaaS. The email server, the ticketing system, the CI tool you maintain for no strategic reason. Every repurchase eliminates an entire operational domain.

Refactor: re-architect for cloud-native — microservices, serverless, event-driven. Highest cost, highest long-term payoff. Reserve for systems where the architecture is the constraint: the monolith that can't scale, the batch system that needs to be real-time.

Retain: deliberately leave on-prem. Latency-sensitive manufacturing systems, regulatory constraints, the mainframe that works. Retain is a decision, not a default — it gets reviewed, not forgotten.

Retire: decommission. Discovery always finds systems nobody uses. Every retirement is pure savings — the cheapest migration is the one you don't do.

Classify every workload in discovery. The classification is the strategy; migration waves then execute it in priority order.

03 · Estimation

Building a budget your CFO will believe

Start with discovery, not a calculator. Online migration calculators estimate target-state compute from inputs you don't have yet. Real estimation starts with discovery: application inventory, dependency mapping, utilization data (actual CPU/memory/storage/network, not provisioned), and license position. Two to four weeks of discovery saves six months of budget variance.

Model three scenarios. Conservative (lift-and-shift heavy, minimal optimization), expected (balanced 6 Rs mix), and optimized (aggressive replatforming, license elimination, reserved purchasing). Present all three with the assumptions explicit. The CFO doesn't need a single number — they need to understand what moves the number.

Price the steady state honestly. On-demand pricing for the first year (you won't know your steady-state shape yet), then model reserved instances and savings plans for year two. Include data transfer — egress is the classic surprise — and managed-service premiums. Compare against the true on-prem TCO: hardware refresh cycles, data center costs, license renewals, and staff — not just the server invoices.

Separate one-time from run-rate. Migration execution is one-time; cloud spend is run-rate. Conflating them produces the "cloud is expensive" narrative when the execution budget bleeds into year two. Track them as separate lines with separate owners.

04 · FinOps

Day-two cost discipline (or the bill eats the savings)

Migration without FinOps is a cost transfer, not a cost reduction. From day one in the cloud: tagging strategy (every resource tagged with owner, project, environment — untagged spend is ungovernable), budgets and alerts per workload, rightsizing as routine (the instances sized from on-prem specs are almost always oversized), and commitment management (reserved instances and savings plans once steady state is known — typically 30–40% savings on stable workloads).

The cultural piece: give teams visibility into their own spend and make cost a design constraint, not a finance complaint. Engineers who can see the daily cost of their architecture make different decisions — usually better ones, without being told.

05 · Waves

Sequencing the migration in waves

Migrations execute in waves, each ending in a production cutover with a rollback plan. The sequencing logic:

Wave 0 — Landing zone. Before any workload moves: the AWS foundation — Organizations structure, network topology, IAM baselines, logging and monitoring, CI/CD paths, and the FinOps tagging and budget scaffolding. Two to four weeks with experienced hands; this is the foundation everything else stands on, and rushing it creates security and cost debt that compounds.

Wave 1 — Pilot. Two to four low-risk workloads: internal tools, dev/test environments, the reporting system nobody will miss for a day. The goal isn't savings — it's validating the landing zone, the migration tooling, the runbooks, and the team's operational rhythm. Every lesson from wave 1 is cheap; the same lesson in wave 3 is expensive.

Wave 2 — The bulk. Standard business applications via rehost or replatform. This is where the 6 Rs classification pays off — each workload already has its strategy, so wave 2 is execution, not decision-making. Run multiple workloads in parallel once the patterns are proven.

Wave 3 — The hard ones. Complex, coupled, or regulated workloads: the monolith that needs refactoring, the system with data residency constraints, the database migration that runs as its own project. These get dedicated plans and timelines, not wave slots.

Each wave has the same exit criteria: cutover complete, validation passed, old environment decommissioned (not "kept just in case" — decommissioned, on a date, with an owner), and lessons captured into the runbook. Waves without decommissioning aren't migrations; they're expansions.

06 · Mistakes

The five budget mistakes everyone makes

1. Estimating from provisioned capacity, not utilization. On-prem servers run at 15–30% utilization; cloud bills on what you provision. Right-size from measured utilization data — or better, from a pilot wave's actual cloud consumption. Provisioned-capacity estimates routinely overshoot by 2–3x.

2. Forgetting data transfer. Egress pricing is the classic surprise: cross-region replication, internet-facing egress, and multi-AZ chatter add up. Model it explicitly, architect to minimize it, and monitor it from day one.

3. No dual-run budget. Covered above, but it bears repeating: every estimate that omits dual-running is wrong by the overlap period. Make it a line item with an owner incentivized to shrink it.

4. Treating licenses as unchanged. Migration is the best moment to fix licensing — and the worst moment to ignore it. Every SQL Server and Oracle workload should get a license-position review during discovery: BYOL, re-platform, or migrate to open source. The license delta often exceeds the infrastructure delta.

5. No FinOps from day one. The team that migrates without cost visibility, tagging, and budgets will be surprised by the first invoice — and the surprise will be used as evidence that "cloud is expensive." FinOps isn't a phase-two activity; it's part of the landing zone.

07 · Bottom line

The budget is the strategy

A cloud migration budget isn't an accounting exercise — it's the strategy expressed in numbers. The six cost categories force honesty about what the migration really involves. The 6 Rs classification turns a vague "move to cloud" into per-workload decisions. The three scenarios give leadership a real choice instead of a single number to bless or reject.

The teams that migrate without surprises share one trait: they did the discovery before the budgeting, not after. Two to four weeks of inventory, dependency mapping, and utilization analysis is the highest-ROI phase of any migration. Everything downstream — wave plans, license decisions, FinOps guardrails — gets easier when it's built on facts instead of assumptions. Start there, budget honestly, and the cloud delivers what it promises: not automatic savings, but a platform whose costs you understand and control.