Cloud migration

Cloud Exit Assumptions Index

Short answer: Use this before turning a cheaper provider quote into a migration case.

Estimate only

This is a decision checklist, not a final price quote.
Verify final numbers against provider pricing pages and your own bill or quote.

By Andrew Cooper, Founder of RunPlacement Updated May 2026 Provider-neutral, estimate-labeled guidance Verify current provider pricing

Use this when

A cloud exit, partial migration, or bare metal move looks financially attractive.
A bill shock has triggered migration discussion but the recurring driver is not fully separated.
The team needs a source-backed checklist of fields before using payback math.

Not for

Live provider pricing or provider rankings.
Replacing architecture, security, compliance, legal, or procurement review.
Final migration approval without observed bills, quotes, and owner sign-off.

Assumption map

Cloud exit math is only as good as the assumptions behind it.

Make the evidence visible before comparing providers.

01 Baseline

Observed steady cost, usage, region, and service mix.

02 Target

Equivalent destination cost with reliability and support included.

03 Transition

Data movement, engineering work, testing, downtime, and rollback.

04 Operate

New ownership, monitoring, incident response, and support.

Worksheet Fields

Use this as the working version before copying the decision into a doc, ticket, or vendor email.

Field	Capture	Why it matters
Baseline cost	Current steady run rate from bill exports or cost tools after one-time spikes are removed.	Prevents a temporary spike from becoming a migration business case.
Target run rate	Destination compute, storage, network, backup, observability, support, and reliability equivalents.	Shows whether the new placement is actually comparable.
Exit project cost	Engineering work, data movement, testing, rollback, downtime risk, and training.	Turns migration effort into payback math.
Operating model	Incident owner, monitoring, scaling, patching, procurement, and support after migration.	Keeps the lower-cost option from hiding new work.

Research-ready

Copy Into An Assumptions Sheet

Use this before estimating cloud exit payback. Keep live prices in official calculators, bills, or quotes and label every row by evidence quality.

Field	What to verify	Evidence type	Why it matters
Current steady run rate	Monthly workload cost after one-time spikes and experiments are removed	Observed bill export or cost tool	Creates the baseline.
Largest recurring driver	Service, region, account, tag, and usage metric causing repeatable spend	Observed bill export or cost tool	Prevents migration from hiding a fixable line item.
Target run rate	Destination compute, storage, network, backup, observability, support, and reliability equivalents	Quote, calculator, or estimate	Keeps the comparison like-for-like.
Data movement	One-time export, replication, validation, recurring transfer, and retrieval needs	Official pricing fields plus workload estimate	Prices movement separately from hosting.
Service replacement	Databases, queues, object storage, identity, secrets, observability, backup, and deployment equivalents	Architecture inventory	Surfaces hidden platform work.
Engineering and testing	Build, migrate, test, performance, cutover, and documentation effort	Team estimate	Turns project work into payback math.
Rollback and downtime	Rollback window, source environment overlap, customer impact, and support plan	Migration plan	Avoids one-way savings assumptions.
New operations owner	Incident response, patching, scaling, monitoring, support, and cost review after migration	Named team or provider	Prices the operating model.
Payback confidence	Observed, quoted, estimated, or unknown fields that drive savings	Evidence label	Shows whether the case is ready or speculative.

Field What to verify Evidence type Why it matters
Current steady run rate Monthly workload cost after one-time spikes and experiments are removed Observed bill export or cost tool Creates the baseline.
Largest recurring driver Service, region, account, tag, and usage metric causing repeatable spend Observed bill export or cost tool Prevents migration from hiding a fixable line item.
Target run rate Destination compute, storage, network, backup, observability, support, and reliability equivalents Quote, calculator, or estimate Keeps the comparison like-for-like.
Data movement One-time export, replication, validation, recurring transfer, and retrieval needs Official pricing fields plus workload estimate Prices movement separately from hosting.
Service replacement Databases, queues, object storage, identity, secrets, observability, backup, and deployment equivalents Architecture inventory Surfaces hidden platform work.
Engineering and testing Build, migrate, test, performance, cutover, and documentation effort Team estimate Turns project work into payback math.
Rollback and downtime Rollback window, source environment overlap, customer impact, and support plan Migration plan Avoids one-way savings assumptions.
New operations owner Incident response, patching, scaling, monitoring, support, and cost review after migration Named team or provider Prices the operating model.
Payback confidence Observed, quoted, estimated, or unknown fields that drive savings Evidence label Shows whether the case is ready or speculative.

AI prompt

Prompt To Stress-Test Cloud Exit Assumptions

Paste this with your assumptions to find missing evidence before proposing migration or partial placement.

You are reviewing a cloud exit or partial migration assumptions sheet. Do not assume provider pricing, benchmarks, migration effort, or provider rankings unless I provide source data.

Here are the assumptions:
[Paste current steady run rate, largest recurring driver, target run rate, data movement, service replacements, engineering/testing, rollback, downtime, operations owner, and evidence labels here]

Please:
1. Separate observed facts, quoted inputs, estimates, and unknowns.
2. Identify assumptions that could make the payback case misleading.
3. Flag missing service replacements, data movement, support, observability, rollback, and operations costs.
4. Recommend whether to model full migration, partial migration, or optimize-in-place first.
5. List the next source checks needed before provider comparison.
6. Avoid live pricing, benchmark, legal, procurement, or provider-ranking claims unless supplied in the source data.

You are reviewing a cloud exit or partial migration assumptions sheet. Do not assume provider pricing, benchmarks, migration effort, or provider rankings unless I provide source data.

Here are the assumptions:
[Paste current steady run rate, largest recurring driver, target run rate, data movement, service replacements, engineering/testing, rollback, downtime, operations owner, and evidence labels here]

Please:
1. Separate observed facts, quoted inputs, estimates, and unknowns.
2. Identify assumptions that could make the payback case misleading.
3. Flag missing service replacements, data movement, support, observability, rollback, and operations costs.
4. Recommend whether to model full migration, partial migration, or optimize-in-place first.
5. List the next source checks needed before provider comparison.
6. Avoid live pricing, benchmark, legal, procurement, or provider-ranking claims unless supplied in the source data.

Short Answer

A cloud exit estimate is useful only when the assumptions are explicit.
Collect the baseline, target run rate, migration work, data movement, service replacements, rollback plan, and new operations before provider comparison.
Keep live prices in the source tools or quotes; use this page to decide which fields must be verified.

Assumptions To Capture

Current steady monthly run rate by service, region, account, and workload.
The largest recurring cost driver and the change event that created it, if any.
One-time export, replication, validation, and recurring transfer needs.
Destination compute, storage, networking, backup, observability, support, and reliability equivalents.
Managed services that must be replaced or deliberately kept in place.
Engineering time, testing window, rollback buffer, downtime risk, and training.
The team or provider that owns incidents, scaling, patching, and cost review after migration.

Source Checks

Use bill exports or cost tooling to separate steady usage from one-time spikes.
Check official network and storage pricing pages for the fields that affect data movement and retrieval.
Use destination quotes or official calculators for target run-rate assumptions, then label them as estimates.
Document which assumptions are observed, quoted, estimated, or still unknown.

Decision Criteria

Migrate: savings are recurring, the workload is portable, replacement services are understood, and payback survives risk.
Partially migrate: one expensive slice can move without dragging the whole platform with it.
Optimize in place: one fixable line item explains most of the pain.
Do not move yet: evidence is missing, rollback is unclear, or the target operating model has no owner.

FAQ

What assumptions matter most in a cloud exit estimate?

Start with steady current cost, fully loaded target cost, one-time migration work, data movement, service replacements, rollback, and the new operating owner.

Should egress be modeled separately?

Yes. Egress is one input. The broader exit model should also include engineering work, testing, downtime risk, rollback, and replacement operations.

Can this be used for partial migration?

Yes. The same fields help test whether moving only GPU, batch, storage-heavy, or unusually expensive slices is safer than a full migration.

Sources

RunPlacement quiz

Pressure-test this workload

Compare migration options only after baseline cost, target run rate, data movement, service replacement, rollback, and new operations are visible.

Uses workload type, budget, GPU need, data movement, priority, and ops tolerance.

Use the quiz