What to include in a cloud migration cost estimate beyond server pricing

What a TCO calculator shows is the steady state

If a cloud migration estimate compares only monthly VM, Database and Storage charges, it can answer one question. How much will it cost each month to run the target environment once the migration is over. It cannot answer the next question. How much will it take in total to actually stop the current environment and switch over to the target one.

The total cost of a cloud migration is the steady-state operating cost of the target environment plus the costs of assessment, design, Refactoring, data movement, Dual Run, validation, Downtime risk, training, remaining existing contracts, Rollback and stabilization. As a formula it reads: Migration TCO(H) = target environment recurring cost(H) + retained source environment cost + one-time transition cost + temporary duplicate cost + risk-adjusted cost. H is the common evaluation period used for the comparison, such as 12 months or 36 months. Keeping the current environment and migrating must both be compared over the same period at the same service level.

The TCO tools that Cloud Providers offer are a useful starting point for discovering current assets and calculating the right size and expected operating cost of the target environment. Google Cloud Migration Center compares costs based on the Memory and Storage usage of asset groups and the target products,^[13] and Azure Migrate explicitly separates current environment and Azure costs as TCO (steady state).^[9]

The problem is that the actual migration is not a steady state. During the migration period the source and target environments exist at the same time, data is copied more than once, and new security, monitoring and deployment systems are built. If Cutover fails you must be able to return to the original environment, and even after it succeeds the Migration Team has to support the operations team for a while.

AWS's detailed Business Case guidance likewise directs you to calculate, beyond the target Cloud's operating cost, the costs of Migration and Modernization, asset retirement and early contract termination, and the Parallel Run of the existing and target environments.^[7] It is therefore safer to use the TCO calculator as the basis for the target environment's steady-state operating cost and to supplement the actual migration budget with a separate transition-cost ledger.

Separate costs into four kinds

The same cost is judged differently depending on when it starts and when it ends. A single item can span several classes. In Monitoring, for example, building the new environment's Dashboards and Alerts is One-time, but Log collection and retention fees are Recurring. Writing and rehearsing a Rollback Runbook is One-time, but the extra staff, re-synchronization and business disruption when a Rollback actually happens are Risk-adjusted costs.

The FinOps Foundation also does not limit the cost inputs for Workload Placement to Infrastructure Cost. It includes Support and Run, Modernization, Implementation and Migration Cost, and defines the duration and cost of Transition States such as Parallel Run, Phased Rollout and Decommissioning as something to be managed separately.^[6]

The 16 cost areas a Migration TCO must include

The table below rebuilds activities scattered across the official Migration Guidance of AWS, Microsoft and Google into a single cost ledger.^[7][10][14] Each area reappears as one row in the Worksheet later on.

Discovery does not end with a server list

A list of servers and Databases alone does not tell you in what order things must move. A single Application may depend on central authentication, internal DNS, File Shares, external APIs, Batch Jobs or a particular License Server.

Google's Assessment Guidance also does not limit the Workload Inventory to Applications. It includes Databases, Message Brokers, Configuration Stores, Source Repositories, CI/CD, Artifact Repositories, Runtimes and even physical Network and Security Appliances. It also explains that building the Inventory itself takes considerable effort, all the more so when no automated Catalog exists.^[14]

Assessment cost can be estimated with the following formula. Assessment Cost = automated Discovery Tool cost + owner Interview hours + Dependency verification hours + compiling current cost and contract records + POC and Benchmark cost. The less you know about the current environment, the wider the uncertainty range should be, rather than skipping the Assessment.

Architecture Change and Refactoring are not the same item

Architecture Change is changing the operating structure of the target environment. Network, IAM, Account structure, deployment Pipelines, Monitoring, Secret management and high-availability configuration belong here. Refactoring is modifying the Application itself. It arises when Runtime compatibility, Local File dependencies, Sessions, Authentication, Database features, external integrations or the deployment method change.

If the two items are merged, it is easy to miss the state where the infrastructure design is complete but Application changes are not, or conversely where the Code has moved but the operating foundation is not ready. AWS likewise distinguishes Replatform, Repurchase and Refactor targets, for which Migration and Modernization costs are to be estimated in more detail per Workload.^[7]

Separate Data Transfer from Data Synchronization too

Data Transfer is moving the current data to the target environment once. Data Synchronization is continuously catching up with data newly created or modified at the source while the copy is in progress.

Moving large volumes of data can incur not only Network Egress but also Read Operations on the source Storage, extra circuits and Bandwidth, Transfer Tools or Appliances, and temporary Staging Storage. Transfer staff and approval procedures, retries of failed files, and Checksum and Data Integrity validation are costs as well.

Google's official guidance explains that data transfer includes Network, Storage Operation, Transfer Product and staff costs, and that planning and testing may take as much time as the transfer itself. It also lays out the sequence of resolving and validating Data Integration issues after the initial copy, and retiring the source only when it is no longer needed as a Fallback.^[15]

Data costs are therefore split at least as follows. Data Migration Cost = Initial Bulk Transfer + Incremental Synchronization + Validation + Failed Transfer Retry + Rollback Re-synchronization Risk.

Count the Dual Run period in dates

Dual Run is not simply the cost of keeping two sets of servers switched on. Along with the Compute, Database and Storage of both the source and target environments, Monitoring, Security, Licenses, Support, Network connectivity and operations staff on both sides may be kept in place at the same time.

Microsoft's current Migration Plan example distinguishes Cutover approaches as Big Bang, Phased and Blue-green.^[11] Blue-green keeps two environments in parallel, so its cost impact is large but it can reduce Downtime and Rollback risk, while Big Bang has low direct cost but high Downtime and Rollback difficulty. This does not mean one approach should always be chosen. It shows that the Cutover approach itself is a trade-off between cost and risk.

Dual Run cost is tied to duration like this. Dual Run Cost = (monthly retained source environment cost + duplicate Licenses, Monitoring and Support + inter-environment Network and Synchronization + additional operations staff) × actual months of overlap. The most important input here is not the planned Cutover date but the approved Decommission date of the source environment. If validation after Cutover is unfinished and the source is kept running, Dual Run keeps running too.

Draw the monthly cash flow before the total

If the migration cost is recorded only as a single-line total, you cannot see when costs overlap. Which costs overlap in each phase is shown in the table below.

Azure Migrate's Future-state Cash Flow also does not assume that every server disappears at once. It calculates the remaining current-environment cost and the Azure cost together according to the Migration percentage per year.^[9] AWS likewise builds into its Business Case a structure in which the Cloud cost Ramp-up starts before the source environment Ramp-down, to secure time for testing and Decommissioning.^[7]

If there are several Workloads, do not calculate the whole company against a single migration date. Give each Wave its own dates. There are eight of them: Target Build Start, Replication Start, Cutover Date, Acceptance Date, Rollback Window End, Hypercare End, Source Decommission Date and Contract End Date.^[8]

Do not mix cash cost, accounting cost and opportunity cost

A Migration TCO brings in financial items of different kinds. For example, writing off the full book value of existing servers as a loss and then adding the same amount again as a contract termination cash cost can double-count it.

Internal full-time staff are similar. Their salaries are paid regardless of the migration, but the hours spent on the Migration can delay other development. In that case it is more accurate to report the incremental cash spend for accounting purposes and the opportunity cost for decision-making purposes separately.

Cash Cost

Money actually spent, such as CSP Invoices, Consultants, Tool Licenses, Egress, extra circuits and overtime. Recorded when the spend actually occurs.

Accounting Cost

Costs with no cash outflow, such as depreciation of remaining equipment book value or disposal losses. Shown separately from cash outflows.

Opportunity Cost

Time existing developers spend delaying the Product Roadmap because of the Migration. If their labor is already entered as Cash Cost, do not count it twice.

Do not replace Downtime and Rollback with a contingency percentage

Risk cost is calculated per risk event rather than applied as a flat "some percent of the total budget". Risk-adjusted Cost = probability × financial impact if it occurs.

For example, Cutover overrun, data consistency errors, missed performance targets, missing Application Dependencies, DNS and Routing errors, data merge after Rollback, extended Hypercare and delayed termination of source contracts are each kept as separate items. For each risk, record the Low, Base and High impact values, the probability, the mitigation and the accountable owner.

A small expected cost, however, does not mean that a high-impact risk may be tolerated. Events that exceed the tolerable outage duration or data loss should not be diluted into an average cost but kept as separate design and approval conditions.^[5] Google recommends creating a Rollback strategy for each phase of the Migration Plan, verifying that it actually works, and defining the condition under which Rollback begins once a phase's maximum execution time has passed.^[14]

The migration project does not end when Cutover ends

Just because DNS points to the target environment and users can connect does not mean the Migration Team should be disbanded straight away. AWS's Wave Planning keeps a separate Hypercare phase after Cutover in which the Migration Team supports the operations team and performs optimization. A Wave is closed only after the operations team has taken over the Workload and Cutover issues have been resolved.^[8]

During stabilization, costs may remain for performance bottlenecks and Configuration fixes, filling in missing Alerts and Dashboards, adjusting Log Volume and Cloud Cost, and correcting permissions and security policies. User inquiries and data reconciliation, updating operations Runbooks, expanded On-call and Support, approval to retire the source environment, and cleanup of remaining temporary resources and Licenses are also costs of this period.

Google likewise describes post-migration Optimization as an iterative activity and states explicitly that optimization has a cost in Resources, Time, Effort and Skill.^[16] It is better to distinguish Post-migration Stabilization from the general cost optimization you will do at some point after the move, and to budget it as a Temporary Cost of the Migration Project itself.

Migration TCO Worksheet

The Worksheet below is duplicated one row per Workload or Migration Wave. Each row has fields for Low, Base and High amounts, the timing and duration of occurrence, and Owner and Evidence.

There are six rules of use. Fix the evaluation period H first. Record both the start month and the end month of each cost. Do not mix committed and uncertain costs into the same value. State whether internal staff were calculated on a cash-cost or an opportunity-cost basis. Link every amount to Evidence such as quotes, contracts, usage data or timesheets, and to an Owner. Do not hide one of Low, Base and High and report only the Base value.

Subtotals by class and the final formula

Once the Worksheet rows are filled in, add them up by class. The nine subtotal items are listed below.

The final formula is three lines. Committed Migration Cash Cost = One-time + Temporary + Recurring(H) + Retained Source + Non-cancellable Contract Remainder. Risk-adjusted Expected Cost = Σ(probability × financial impact if it occurs, for each risk). Migration TCO = Committed Migration Cash Cost + Risk-adjusted Expected Cost.

Accounting Impact and Opportunity Cost are shown alongside in the decision material, but when they are combined with the Cash TCO into a single number, check that nothing is counted twice.

One-time subtotal

The sum of committed one-off costs.

Temporary subtotal

The sum of incremental costs that exist only during the migration period.

Recurring subtotal

Target environment recurring cost × evaluation period H.

Retained source subtotal

The residual cost of the source environment after Cutover.

Risk-adjusted subtotal

The sum of probability × impact if it occurs, for each risk.

Migration TCO — Cash basis

The sum of the cash costs above.

Accounting impact

Non-cash costs such as asset write-offs and disposal. Reported separately.

Opportunity cost

Internal staff diverted and Roadmap delays. Reported separately.

Current-state baseline(H)

What the same period would cost without migrating. Kept for comparison.

Three scenarios are better than one number

A Migration TCO is more practical viewed as three scenarios, Low, Base and High, than as a single correct answer. AWS also directs that the detailed Business Case model minimal change, the most likely case and the case where key assumptions differ as separate scenarios.^[7]

The inputs that are especially sensitive in each scenario are Refactoring Person-days, data volume and Change Rate, the number of Dual Run months and the source environment Decommission date. The Hypercare period, the end dates of existing contracts, tolerable Downtime, and the likelihood and impact of Rollback also move the result substantially. Seeing how much the TCO changes when these values change is often more important than comparing individual server prices to the decimal point.

Low / smooth transition

The migration finishes within the planned period, Dual Run is short and no extra Refactoring is needed.

Base / most likely transition

Includes the expected defect fixes and stabilization plus the approved Buffer.

High / adverse transition

Dual Run is extended, extra Refactoring is required, and re-transfers or a partial Rollback occur.

Questions to check before approving a migration budget

If the following questions cannot be answered, the TCO is still closer to a quote for the target environment. Which Workloads and Dependencies are within the migration scope. Has the Rehost, Replatform or Refactor scope been decided per Workload. Are the initial Data Transfer and the ongoing Data Synchronization separated. Is there a start date and an end date for the overlap between source and target environments. Are the functional, performance, security and business acceptance criteria documented.

Then five more questions. Has the decision-maker for Cutover and the Rollback Trigger been named. Are the source environment Decommission conditions linked to the contract end dates. Are operations team training and the Monitoring and Security handover in the budget. Is there an exit condition for Hypercare. Are there Low, Base and High scenarios and Evidence for each input.

The economics of a cloud migration are not the problem of finding the cheapest server quote. Even if the target environment's monthly cost is low, the cash burden at transition time can grow if Refactoring, remaining contract terms, a long Dual Run and stabilization costs are large. Conversely, a design that costs more in one-off transition spend can be the rational choice if it reduces operational complexity or business disruption risk.

The conclusion should be reached in the following order rather than by Vendor name or discount rate. Workloads and constraints → target operating model → migration strategy → monthly transition cash flow → risk and Rollback → TCO comparison over the same period. The role of the Migration TCO Worksheet is not to prove that cloud migration always saves money. It is to let decision-makers see which costs and risks they are taking on and when the existing environment can be brought to an end.