Cloud migration / Migration planning
Cloud Egress and Exit Cost: What to Price Before Moving
Short answer: Cloud egress is only one part of exit cost. A serious migration estimate also prices data export, recurring transfer, storage retrieval, rewrites, testing, downtime, rollback, and new operations.
- Move only when repeatable savings survive migration cost and the new operating model.
- Verify current provider pricing directly before buying or migrating.
Quick answer
Short answer
Answer: Cloud egress is one line item inside cloud exit cost, not the entire migration decision.
Decision rule: Price data movement, frequency, destination, testing, rollback, and new operations before moving.
Common trap: The common trap is comparing egress charges to a lower host quote without pricing the rest of the exit.
Best next page: Cloud exit payback frameworkDiagnosis workflow
What to check before changing providers
Use this section to turn a vague bill or quote problem into fields a buyer, engineer, or founder can compare.
What to check first
- Data volume leaving the current provider.
- Destination, region, and transfer frequency.
- One-time export versus recurring data movement.
- Testing, verification, rollback, and replication windows.
- Services that must be replaced after data moves.
When this is not a migration problem
- The data must stay near managed services.
- The transfer is one-time and cheaper than redesign.
- The target provider quote omits storage, support, or observability.
Bad diagnosis vs good diagnosis
| Diagnosis | What it says |
|---|---|
| Bad diagnosis | Egress is expensive, so moving providers is automatically bad or automatically urgent. |
| Good diagnosis | Egress is one input in a payback model that also includes migration work and new operations. |
Example scenario
Hypothetical example scenario
A team can move GPU batch artifacts monthly without moving the application database. Partial placement may capture savings while avoiding a full cloud exit.
This is a hypothetical example, not a provider benchmark. Check your own bill, logs, and provider terms.Fields to capture
Capture these before comparing providers or making a migration call.
| Field | Capture |
|---|---|
| data_to_move | TB exported or replicated |
| move_frequency | One-time, daily, monthly, or continuous |
| destination | Provider, region, or storage target |
| replacement_services | Queues, identity, backup, monitoring, incident ownership |
What to ask before changing providers
- What data must move and how often?
- Can only the expensive workload slice move?
- What breaks if data locality changes?
- What is the rollback plan?
Right fit
- A cheaper provider looks attractive but the data path is unclear.
- A team wants to leave a major cloud after a cost spike.
- The workload may be partially movable instead of fully portable.
Quick checks
- Estimate total data to export and recurring data movement after migration.
- Check storage retrieval, replication, snapshot, and backup assumptions.
- Price testing, downtime, rollback, and provider-specific service replacements.
Rough math
- Exit project cost = data movement + engineering time + testing + downtime risk + rollback buffer.
- Monthly savings = current steady run rate - destination steady run rate.
- Payback period = exit project cost / monthly savings.
Red flags
- The destination quote excludes equivalent backup, monitoring, and support.
- The current workload depends on managed services that must be rebuilt.
- The team prices egress but ignores downtime and rollback.
What to do next
- Use the cloud exit checklist to price the move.
- Consider partial migration if one line item causes most of the pain.
- Run the quiz after the current baseline and target baseline are known.
RunPlacement quiz
Pressure-test this workload
Move only when repeatable savings survive migration cost and the new operating model.
Uses workload type, budget, GPU need, data movement, priority, and ops tolerance.Related resources
Use a worksheet before making the call
These supporting pages turn the decision into fields a buyer, engineer, or founder can actually compare.
A source-backed index of the assumptions to collect before estimating cloud exit payback, partial migration, or workload re-placement.
Cloud migrationCloud Exit Cost ChecklistChecklist / 7 sections / source-linkedA checklist and payback worksheet for pricing the real cost of leaving AWS, GCP, or Azure before migration starts.
Workload placementWorkload Placement WorksheetChecklist / 7 sections / source-linkedA practical worksheet and decision map for deciding where a workload should run before provider choice hardens.
Related decisions
Keep narrowing the placement question
Follow the adjacent pages when the first answer exposes a deeper cost driver or operating constraint.
Bare metal can win when a workload is steady, portable, highly utilized, and operationally owned. Cloud usually wins when flexibility, managed services, or variable demand matter more than unit cost.
AWS bill shockAWS Pricing Calculator Alternative: What to Use for Placement DecisionsTool evaluationFor placement decisions, an AWS pricing calculator is useful but incomplete. You also need workload shape, hidden bill drivers, migration cost, operational tolerance, and whether the problem is AWS itself or one expensive line item.
Workload placementManaged Platform vs Cloud: When Less Control Is the Better PlacementCommercial comparisonA managed platform can be the better placement when engineering focus and reliability matter more than infrastructure control. Direct cloud can be better when the team needs flexibility, deep customization, or lower unit cost at scale.
Framework
Use the underlying decision model
These framework pages define the terms and formulas behind this specific decision.
Cloud exit is financially serious only when steady savings repay migration work, data movement, service replacement, downtime risk, rollback planning, and new operations inside an acceptable window.
Workload placementWorkload Placement Frameworkworkload placementChoose workload placement by matching the workload's cost driver, data movement, performance needs, operational tolerance, and commitment horizon to the right infrastructure category.
FAQ
Is egress the same as cloud exit cost?
No. Egress is a data transfer line item, while cloud exit cost includes the whole migration project. Add engineering time, testing, downtime risk, rollback, managed-service replacement, monitoring, support, training, and new operations before treating a lower destination quote as savings.
When is partial migration better?
Partial migration is often better when one workload slice causes the cost problem and can move without dragging the whole platform with it. GPU jobs, batch work, storage-heavy paths, or isolated services can be candidates if data movement and operations remain manageable.
How long should migration payback be?
Migration payback should be explicit and acceptable to the team before cloud exit starts. There is no universal period; the window depends on risk tolerance, engineering capacity, reliability needs, and savings confidence. Use repeatable baseline cost, not a one-off bill spike, in the estimate.
Sources
RunPlacement quiz
Pressure-test this workload
Move only when repeatable savings survive migration cost and the new operating model.
Uses workload type, budget, GPU need, data movement, priority, and ops tolerance.