Cloud migration
Cloud Exit Cost Checklist
Short answer: Use this when cheaper infrastructure looks attractive but migration risk is not priced yet.
- This is a decision checklist, not a final price quote.
- Verify final numbers against provider pricing pages and your own bill or quote.
Payback pass
Use This Before Calling A Move Savings
A lower destination run rate only matters if it survives migration work, risk, and the new operating model.
Copy the payback rows
Start with current steady run rate, target run rate, migration work, data movement, and rollback.
Separate spikes from steady cost
Do not justify migration from a one-time bill event.
Calculate payback months
Compare migration cost against recurring savings after equivalent reliability and support are included.
Filled example
Example: Payback Reality Check
Hypothetical migration math, not a procurement recommendation.
| Input | Hypothetical value |
|---|---|
| Promising signal | Target run rate appears lower than the current steady run rate. |
| Missing costs | Engineering work, data movement, rollback window, monitoring, and new on-call ownership. |
| Next move | Price the migration project before presenting monthly savings as real. |
What it flags: The page should help decide whether the savings repay the move, not just whether another platform looks cheaper.
Use this when
- A smaller cloud, GPU provider, bare metal host, or managed platform looks cheaper than the current cloud.
- A team wants to leave AWS, GCP, or Azure but has not priced migration work.
- The workload may only need a partial move rather than a full platform migration.
Not for
- Compliance, legal, or procurement sign-off.
- One-week experiments where migration cost is intentionally ignored.
- A provider-by-provider price calculator; this is a payback worksheet.
Exit payback map
A cheaper host only matters if the payback survives the move.
Migration is a capital project hiding inside a monthly bill decision.
What does this workload cost when the weird one-off month is removed?
What will the new platform cost after equivalent reliability and support?
What will data export, rewrites, testing, downtime, and rollback cost?
How many months until recurring savings repay the move?
Worksheet Fields
Use this as the working version before copying the decision into a doc, ticket, or vendor email.
| Field | Capture | Why it matters |
|---|---|---|
| Current run rate | Steady-state bill after removing one-off spikes and experiments. | Creates a fair baseline. |
| Target run rate | Compute, storage, network, backup, observability, support, reliability equivalents. | Prevents undercounting the destination. |
| Migration cost | Engineering time, data export, rewrite, testing, downtime, rollback, training. | Prices the project hidden inside the monthly bill decision. |
| Payback window | Migration cost divided by expected monthly savings, adjusted for confidence. | Shows whether the move is financially serious. |
Payback-ready
Copy Into A Payback Sheet
Paste this into a spreadsheet before treating a cheaper hosting quote as savings. The examples are placeholders, not a migration business case.
Field What to enter Hypothetical example Why it matters Current steady run rate Current monthly workload cost after removing one-time spikes $12,000/month placeholder Creates a fair baseline. Target run rate Destination monthly cost including equivalent reliability and support $7,500/month placeholder Prevents undercounting the new platform. Monthly savings Current steady run rate minus target run rate $4,500/month placeholder Shows recurring savings before project cost. Data movement Export, replication, verification, and recurring transfer work 20 TB one-time export Prices the move itself. Service replacement Queues, databases, object storage, identity, secrets, monitoring, backup, or managed services to rebuild Replace managed queue Surfaces hidden platform work. Engineering work Build, test, deploy, performance, runbooks, and training 160 engineer hours Turns migration effort into a cost. Downtime risk Cutover risk, customer impact, rollback window, and support plan Weekend cutover with rollback Keeps risk visible. Rollback plan How to return to current placement if the target fails Keep source environment 30 days Avoids one-way migration assumptions. New operations Who owns incidents, patching, monitoring, scaling, and support after migration Infra team owns on-call Prices the new operating model. Payback months Migration cost divided by expected monthly savings 6 months placeholder Shows whether savings repay the move.
AI prompt
Prompt To Review A Migration Payback Case
Paste your draft migration numbers into this prompt before presenting the case. It should test whether savings survive migration work and new operations.
You are helping me review a cloud migration payback case. Do not assume provider pricing, migration cost, or benchmark results unless I provide them. Here are the migration assumptions: [Paste current run rate, target run rate, data movement, service replacements, engineering work, downtime risk, rollback plan, and new operations here] Please: 1. Calculate directional monthly savings and payback months if enough inputs exist. 2. Identify migration costs or operating costs that are missing or undercounted. 3. Separate full migration from partial workload placement options. 4. Flag assumptions that depend on one-time bill spikes rather than steady run rate. 5. Recommend what evidence I need before approving migration work. 6. Avoid current pricing, benchmark, provider-ranking, legal, or procurement claims unless I supplied source data.
Short Answer
- A lower monthly hosting quote is not the same as lower total cost.
- Price the exit work and the new operating model before moving the workload.
- The cleanest migration candidates are portable, expensive, steady, and not deeply tied to managed provider services.
Costs To Price
- Data export, transfer, replication, and verification.
- Managed service replacements for queues, databases, object storage, identity, secrets, and observability.
- IAM, networking, DNS, TLS, backup, monitoring, and incident response rebuilds.
- Application changes, deployment changes, and new runbooks.
- Performance testing, load testing, rollback window, and downtime risk.
- New provider support, SLA, compliance, and procurement work.
- Training cost for the team that will operate the new placement.
Migration Decision Table
- Migrate: workload is portable, expensive, steady, and savings are repeatable.
- Optimize in place: one or two AWS line items explain the pain.
- Hybrid placement: only GPU, batch, or storage-heavy pieces need to move.
- Do not move yet: workload depends on managed services the team cannot replace safely.
- Revisit later: bill is noisy but not yet understood.
Rough Math
- Monthly savings = current steady-state cost - target steady-state cost.
- Migration cost = engineering time + data movement + testing + downtime risk + new tooling.
- Payback period = migration cost / expected monthly savings.
- Risk-adjusted savings = monthly savings x confidence level.
- If payback is long or confidence is low, optimize in place first.
Questions To Ask Before Leaving
- Which services are truly workload requirements and which are provider conveniences?
- Can the workload run somewhere else without a rewrite?
- What data must move, and how often?
- What breaks if latency or region placement changes?
- Who owns incidents after migration?
- What is the rollback plan if the target placement underperforms?
Red Flags
- The workload depends heavily on provider-specific managed services.
- The team cannot describe the rollback plan.
- The savings estimate ignores engineer time.
- The target quote omits observability, backup, or support.
- The migration is motivated by one unexplained bill spike.
When To Use The Quiz
- Use the RunPlacement quiz when you can describe the workload pattern, data movement, current provider, pain point, and ops tolerance.
- The quiz helps separate full migration from partial re-placement.
FAQ
When is leaving a major cloud worth it?
Leaving a major cloud is worth considering when the workload is portable, expensive, steady, and not deeply dependent on managed provider services. The recurring savings must beat data movement, engineering work, downtime risk, rollback, replacement services, support, and the new operations model.
What cloud exit costs are easy to miss?
Cloud exit costs that are easy to miss include data movement, managed-service replacements, observability, backup, incident ownership, testing, downtime risk, rollback plans, support, team training, and procurement. Also price the reliability work needed to make the new placement equivalent enough for production.
Is partial migration better than full cloud migration?
Partial migration is often better than full cloud migration when one workload slice causes the cost problem and can move cleanly. GPU, batch, storage-heavy, or unusually expensive pieces may move first while core services stay put. This only works if data movement and operations stay manageable.
Sources
RunPlacement quiz
Pressure-test this workload
Only migrate when repeatable savings beat data movement, rewrite, downtime, and ops complexity.
Uses workload type, budget, GPU need, data movement, priority, and ops tolerance.