AWS Migration Business Case: Who Funds the Overlap?

Build an AWS migration budget that includes dual running, retained commitments, customer effort, acceptance delays and conditional funding before approving a move.

An AWS migration budget should show what the customer pays while both environments exist, when the old bill can stop, and what the new service costs after temporary support ends. Prepare an unfunded case first. Add a funding scenario only when its recipient, permitted use, approval conditions and timing are known.

A lower AWS calculator total can still produce an expensive move. The old contract may continue. Your team may spend three months reconciling data and retraining operators. A credit may reduce a later AWS invoice without paying the implementation invoice due this month. Those are separate entries in a budget.

This guide is for a CTO and finance owner deciding whether to approve a defined migration wave. It provides a fictional 24-month worked case and an approval worksheet. It does not estimate a reader's AWS bill, quote a funding entitlement or report an Ampity customer result. All example amounts are invented US dollars for arithmetic, not AWS prices or typical project costs.

Define the decision before pricing the target

Write down the workload, the reason to act, the deadline and the alternative. A database approaching a support deadline has a different decision from a SaaS platform whose current cloud works well but whose promotional credits are ending. In both cases, the alternative needs a price and an operating plan.

For a dedicated application database, define the application dependencies, required engine behavior, data boundary, maintenance window and recovery requirements. A cheaper database estimate that excludes a required replica or reporting workload is an estimate for a different service. Ask the application owner to confirm which behavior must survive the move before finance compares totals.

Use three candidate decisions: retain and improve the current environment, migrate the defined workload, or defer while resolving a named uncertainty. Deferral has a cost if a renewal or support deadline arrives first. Retention also has costs for patching, capacity and recovery. A fair comparison gives each option the resources required to provide the agreed service.

AWS's detailed business-case guidance calls for a multi-year view covering current costs, new AWS costs and migration costs, including which workloads move and when. The approval method below applies that principle to the period when costs overlap.

Separate avoidable spend from accounting allocation

The amount allocated to a workload is not necessarily the amount that disappears when it moves. If a shared hosting agreement costs the same until renewal, moving one application may free capacity without releasing cash. If an annual software contract remains payable, the migration does not remove its invoice merely because the software stops running on the source.

For every source cost, record the amount, billing period, contract owner, cancellation condition and earliest date it can stop. Split it into avoidable cash, retained obligation and shared allocation. Record any termination fee separately. Do not add a retained commitment again as an exit cost if it is already included in the monthly source bill.

For internal engineering, distinguish cash outlay from capacity consumed. A salaried engineer's migration work can displace a committed product release even if payroll is unchanged. Include that work in the economic comparison, label its valuation, and keep it separate from the cash-flow schedule. Contractor invoices, temporary hires and backfill can create incremental cash costs. Finance should choose the treatment consistently across options.

An approval packet should therefore carry two views. The cash view answers whether the organization can fund invoices and payroll when due. The economic view also includes agreed opportunity costs. A productivity estimate belongs in the second view until an owner explains how it changes cash spending or produces a measurable business result.

Price the service that operators will inherit

Keep a dated target estimate with Region, deployment topology, usage assumptions, storage growth, backup retention, recovery configuration, licenses and pricing terms. Include monitoring, logging, connectivity, support and the people who will operate the service. Record excluded items beside the estimate rather than burying them in a proposal appendix.

AWS's detailed portfolio business-case guidance discusses refining current and future operating costs, licensing, workload-specific migration estimates, decommissioning and parallel running. A monthly compute subtotal does not cover those categories.

If a discount requires a commitment, record its term and purchase authority. Do not use a committed rate in the comparison while assuming the organization can exit that commitment without cost. Separate the expected steady-state bill from the on-demand capacity used during testing. Validate sizing against representative demand before proposing a purchase.

For AI-dependent applications, include task volume, retries, retrieval, embeddings, telemetry, human review and evaluation in the target assumptions where those costs apply. Moving infrastructure does not establish that a model change meets the application's quality requirements. Price any AI experiment separately from the migration wave until its scope and acceptance are agreed.

Show the old-cost stop date as an acceptance dependency

Use distinct dates for target capacity starting, production traffic moving, operational acceptance and source retirement. They may occur in different months. A successful copy or an endpoint switch does not prove that the customer can stop paying for the source.

The source retirement date should depend on named evidence: reconciled data, required application behavior, tested recovery, monitoring and alerts, documented access, an accepted support handover and a decision on retained recovery copies. Set thresholds for the actual workload rather than adopting generic recovery or performance numbers.

Name the person who can accept each result and the person who can terminate the old contract. Give a delayed acceptance a financial consequence in the worksheet. If each extra month keeps a $12,000 source environment payable, a two-month delay adds $24,000 before any change to the AWS bill. This is a stipulated example, not a claim about migration durations.

For technical reconciliation and write authority, use the dual-run reconciliation playbook. This budget does not replace that execution plan. It makes the cost of an unresolved execution gate visible to the approving buyer.

Worked case: a cheaper monthly target with a larger 24-month bill

Assume one fictional workload with equivalent accepted service in both options. The source costs $12,000 per month. The target's fully loaded recurring AWS option costs $11,000 per month from Month 1. Both amounts are held flat for 24 months solely to isolate overlap and transition effects. No growth, taxes, currency changes, financing or discounting are modeled.

The migration needs three months of source operation after target capacity starts. Delivery invoices are $14,000 per month for Months 1–3. Incremental temporary engineering/backfill costs are $6,000 per month over the same period. Data movement costs $6,000 in Month 1. A $9,000 exit charge is due in Month 4. The source then stops completely; there is no additional retained commitment outside the costs listed here.

The target saves $1,000 per month after source retirement, but the 24-month migration case costs $87,000 more. The $24,000 target run-rate reduction over the full horizon is smaller than $111,000 of overlap and transition costs. No assumed incentive is needed to see that result.

Under these simplified flat assumptions, cumulative parity would occur after 111 months from target start: $111,000 divided by $1,000 per month. That extrapolation is much longer than this 24-month decision horizon and does not predict a real payback date. Contracts, demand and operating costs would need a new model for such a long period.

The migration may still be justified by a required customer deployment, support deadline or tested recovery improvement. Put that benefit in a separate, owner-backed argument. Do not manufacture an $87,000 saving by converting every hoped-for hour of productivity into immediate cash.

Compare timing as well as totals

The comparison below is a decision visual for the same fictional case. Each amount is cumulative additional spending relative to retaining the source. A positive value means migration has consumed more cash by that point. It is not an AWS invoice total or a funding forecast.

The $24,000 credit is an invented scenario applied as $6,000 in each of Months 5–8. It assumes eligible charges, available credit and no overlap with another claimed benefit. It is not a MAP amount or an available offer. The peak modeled incremental cash need remains $107,000 because the credit starts after that peak.

This is incremental headroom relative to a fully funded retention baseline. It is not the organization's total bank balance requirement. Add ordinary operating payments, actual payment terms, taxes, reserves and other project commitments to produce a treasury forecast. If the organization cannot fund the overlap, a favorable final total will not pay invoices that arrive earlier.

Put conditional AWS support in its own record

AWS publicly describes MAP's Assess, Mobilize, and Migrate & Modernize phases and financial support for migration. Its public MAP page does not establish a funding amount for this fictional case or any reader's project. The partner funding overview also makes eligibility dependent on partner progression and participation in relevant programs.

Ask for a written benefit record for the actual scope. It should identify the program, applicable terms and date, beneficiary, permitted cost or charge, approved amount, conditions, claim or issuance sequence, expiry and the person handling exceptions. A partner credential, proposed forecast or verbal eligibility discussion does not supply all those fields.

Customer credits and partner delivery support need separate treatment. Under the AWS promotional-credit terms, credits offset eligible service charges, are not redeemable for cash, expire and do not offset transaction-based taxes. Stacking requires authorization under the terms. An unused, expired or ineligible credit cannot reduce the customer's modeled cost. Do not subtract a partner award from the customer's price unless the commercial agreement actually passes that benefit through.

AWS's fund-request workflow distinguishes approvals, claims and invoice steps. For MAP, the Cash Claim stage indicates pre-approval; it does not itself mean money has reached a bank account. Check the program-specific milestones rather than assuming that finishing a first wave triggers payment for an entire migration.

Maintain the unfunded budget alongside the conditional case. If the business case depends on support, make the funding condition part of the go/no-go decision before signing implementation commitments. Assign the risk of delayed, reduced or unavailable support explicitly between the customer and delivery partner. A credit allocation cannot finance delivery payroll as though it were cash.

Stress the assumptions that can reverse the decision

Change one driver at a time before combining a downside case. In the worked case, retaining the source for six months instead of three adds $36,000. Increasing the target bill from $11,000 to $13,500 adds $60,000 over 24 months. Combining both changes increases the migration total to $471,000, or $183,000 above retention. These are deterministic scenarios, not probabilities or confidence intervals.

Other drivers need their own evidence: a license that cannot transfer, a customer acceptance window that misses a renewal notice, more frequent recovery tests, growing data transfer, or a support arrangement that changes staffing costs. Record the exposure, the evidence needed and who will resolve it. A generic contingency percentage does not explain which uncertainty it covers.

Also test scope reduction. Moving one independent workload may reduce initial exposure, but shared contracts may still remain payable. Do not allocate a whole-estate credit or support estimate to a small wave without confirmation that the benefit and its conditions follow the changed scope. A smaller engineering project and an earlier funding payment are different claims.

Use a discount rate and finance-approved tax treatment for an investment decision where they matter. This example uses undiscounted cash deliberately. It cannot establish NPV, tax deductibility, revenue recognition, or a universal acceptable payback period.

The approval packet a buyer can challenge

Keep the packet short enough to review while retaining its supporting records. Give the finance owner the monthly cash schedule, the engineering owner the equivalent-service assumptions, and procurement the source obligations. Resolve disagreements in the same version rather than circulating conflicting totals.

The approval can be bounded. Authorize discovery to resolve a licensing question while withholding the migration commitment. Approve an unfunded first wave only if the buyer accepts its economics and the organization can operate it. Retain the source when the proposed move fails the agreed criteria.

The next step is to assemble this approval packet for one bounded workload. If you want a workload-specific comparison, describe the renewal deadline, migration reason and acceptance constraints through Ampity's AWS migration enquiry. Do not submit invoices, credentials or customer data through the enquiry form. We can agree secure evidence handling, assessment outputs, responsibilities and price separately. Any AWS support is qualified for the actual engagement before it enters a customer proposal.