Most cloud migrations blow their budget. Not because the cloud is expensive, but because nobody modeled costs until it was too late to change anything.
By the time you’re deep into implementation, your architecture is locked. The database choice is made. The region is set. The data transfer patterns are baked in. If you haven’t modeled costs by then, you’re just hoping for the best.
Model early, when you can still steer
The point of cost modeling isn’t to produce a perfect number. It’s to catch the expensive mistakes before they’re cemented.
Building a three-tier app? Model the database first — that’s usually where costs surprise people. Planning multi-region? Model the data transfer. That cross-region replication you assumed was cheap? It might be your biggest line item.
A rough model with obvious assumptions beats a precise model that arrives too late.
What actually matters in a cost model
Current baseline: Export your existing bills. Map them to workloads. Know what you’re spending today before you estimate tomorrow.
Peak vs average: Average utilization is useless if your peaks are 3x higher. Size for peaks, or you’ll be firefighting capacity issues in month two.
Data transfer: This is where everyone gets burned. Egress, cross-region sync, analytics exports, logging pipelines — add them all up. If you only model compute and storage, your estimate is fiction.
Parallel running costs: You’ll run old and new systems side by side during migration. For how long? That overlap period is often the biggest hidden cost.
Be honest about what you don’t know
If a number is a guess, write “guess” next to it. If you’re assuming 20% growth, say so. If you have no idea what egress will look like, estimate high and explain why.
Stakeholders can handle uncertainty. What they can’t handle is surprise bills three months in because someone hid their assumptions in a spreadsheet.
Keep it alive
A cost model isn’t a one-time deliverable. Update it after discovery. Update it after the first migration wave. Update it before cutover.
The model that was 80% right at the start might be 40% wrong by month three if you never touch it again.
The three-tier app example
Simple case: web tier, API tier, PostgreSQL database. Currently runs on three VMs.
Map each to the target cloud:
- Web: CDN + small instances
- API: Two medium instances (or serverless, depending on traffic patterns)
- Database: Managed PostgreSQL, 2 vCPU, 8GB RAM
Now add the non-obvious stuff:
- Egress from API to external services
- Backup storage
- Log aggregation
- Monitoring agent costs
Run three scenarios: base case, 30% growth, and peak traffic. If the numbers vary wildly between scenarios, you’ve found your risk area.
Common mistakes
- Treating the model as a one-time exercise instead of a living document
- Ignoring parallel run costs (they add up fast)
- Using average utilization when peaks are 2-3x higher
- Missing data transfer — especially cross-region replication
- Not tying cost decisions back to architecture choices
The last one matters most. A cost model is only useful if it can change your design. If the managed database is too expensive, what’s the alternative? Document the trade-off. That’s where the model adds value.
XIThing helps teams plan and execute cloud migrations. Get in touch if you want to avoid the budget surprises.
