Cloud migration cost and cutover risk

Summary

A migration business case should include the cost of moving, the cost of running two environments, the work required to prove equivalence, and the cost of operating the target state. Compare unit cost and service behavior before and after migration. Keep benefits, estimates, and verified results as separate records.

Define the unit of migration

Count work in units that match the delivery plan. A unit can be an application, pipeline, table, report, model, interface, tenant, or business process. For each unit, record: Google Cloud's migration guidance starts with workload discovery, dependencies, requirements, total cost of ownership, and performance baselines. This inventory also supports migration-wave planning. Unit size drives model quality. A unit too large to fit in one wave hides variance and makes estimates untestable. A unit too small multiplies bookkeeping without improving the forecast. Pipelines that share a source system, an owner, and a cutover window usually belong in one unit, because they will move together whether the plan says so or not.

Source and target
Dependencies
Data volume and change rate
Availability requirement
Security and compliance requirements
Migration pattern
Test and reconciliation method
Cutover window
Rollback boundary
Source decommission condition

Separate six cost groups

The first group is assessment and design: discovery, dependency mapping, target architecture, security design, network design, capacity planning, and proof-of-concept work. The second group is build and conversion: infrastructure, pipelines, schema conversion, code changes, model conversion, automation, observability, and operational tooling. The third group is validation and reconciliation: test-data preparation, row and aggregate checks, semantic comparisons, model evaluation, performance tests, security tests, and business sign-off. The fourth group is parallel operation: source and target infrastructure, duplicate software licenses, data transfer, monitoring, support coverage, and delayed decommissioning. The fifth group is cutover and stabilization: rehearsals, change freezes, data catch-up, operator coverage, incident response, rollback capacity, and post-cutover correction. The sixth group is target-state operation: consumption, licenses, support, platform engineering, security, monitoring, backup, recovery, and ongoing improvement work. Most underestimated budgets share a pattern: the first two groups are staffed and priced, the third is treated as a testing afterthought, and the fourth and fifth appear in no spreadsheet at all.

Use a transparent cost equation

For each migration wave, calculate: total migration cost = assessment + build + validation + parallel run + cutover + stabilization + target transition Then calculate benefits over an agreed period: net benefit = avoided source cost + productivity value + risk reduction + business value - total migration cost - target operating cost change Keep each term traceable to an owner, source, period, and confidence level. Label assumptions as assumptions. A small worked example keeps the model honest. Consider a hypothetical wave of 40 pipelines. The build estimate is 20 engineer-months. If validation finds defects in 25 percent of pipelines, and each defect takes three engineer-days to fix and recheck, the rework alone adds about 7.5 engineer-months, which is more than a third of the build estimate. A model with no defect-rate term will underprice the wave by that amount. The right inputs come from the first wave's measured defect rate, which is why the model must be re-estimated after each wave.

Measure unit economics

Infrastructure cost alone can fall while cost per business outcome rises. Select a unit that represents the service. Examples include: The FinOps Framework recommends connecting technology cost to resource-efficiency and business units. Track the unit before migration, during parallel operation, and after stabilization. Collect the source baseline with the same care as the target estimate. A source cost built from one quiet month misprices the comparison. Use at least one full business cycle, include the peak, and record the measurement window next to the number. Feed the model from systems rather than opinions where possible. Billing exports give source run cost. Query and job logs give volumes, runtimes, and failure rates. The project tracker gives conversion throughput and defect counts. A model rebuilt weekly from these inputs drifts toward reality on its own, and a variance between the model and the actuals becomes a planning signal rather than an argument.

Cost per query
Cost per pipeline run
Cost per million records processed
Cost per report delivered
Cost per active tenant
Cost per model prediction
Cost per order or transaction supported

Price the reconciliation work

Data and application migrations need an explicit proof plan. Define acceptance thresholds before conversion begins. For data, compare: For models, compare the evaluation dataset, metric, tolerance, feature behavior, prediction distribution, runtime, and downstream decision. For reports, compare semantic definitions and business totals. Matching SQL text is insufficient when the source and target engines use different behavior. Timestamp handling, division by zero, null ordering, and string collation differ across engines, and each difference can move a business total while every query still runs. The reconciliation plan should name the engine behaviors that matter for each unit and test them directly.

Row counts and keys
Null and duplicate behavior
Aggregates by business segment
Late-arriving data
Historical restatements
Access and masking behavior
Runtime and freshness

Model parallel-run cost by time

Parallel operation is often a material cost. Create a weekly burn-down that shows: Assign an owner to every decommission condition. A migration can finish technically while the organization continues to pay for the source platform. The burn-down exposes the failure mode early: units awaiting business sign-off pile up while the technical team declares the work done. Sign-off capacity is a real constraint. If the business can review four units a week and the plan finishes eight a week, parallel run extends by the difference, and the model should price that extension before the migration starts.

Remaining units
Units awaiting business sign-off
Open reconciliation defects
Source and target run cost
Duplicate license cost
Support effort
Planned decommission date

Treat cutover as a controlled decision

Define the cutover gate with observable criteria: Google Cloud recommends a rollback strategy for each migration step, tested procedures, and maximum execution times that trigger rollback. Rehearse the cutover on a copy of the live path, and time every step. The rehearsal usually finds that the plan's silent steps, such as waiting for a final incremental load or re-pointing a connection string that lives in a forgotten configuration store, consume the window. A rollback that has never been executed is a hope, so run the rollback at least once before the gate that depends on it.

Data catch-up is within tolerance.
Functional and nonfunctional tests pass.
Security controls are active.
Monitoring and alerts are operating.
Operators have the runbook and access.
Rollback remains possible inside the agreed window.
Business and technical owners approve the change.

Failure modes in migration economics

Four failure modes account for most broken business cases. The first is unit undercounting. Discovery finds the pipelines everyone knows, and the report that a finance analyst refreshes from a spreadsheet macro appears at cutover. Continuous discovery, fed by query logs and dependency scans, reduces the surprise count. The second is the frozen target estimate. The target cost is priced once, early, at list prices and guessed volumes. Re-price the target at each wave boundary using measured consumption from units already migrated. The third is benefit double counting. The same infrastructure saving appears as avoided source cost and again as capacity for a new initiative. Each benefit needs one owner and one line. The fourth is the un-retired source. The target runs, users moved, and the source platform still bills because no one owned the decommission condition. Tie the final payment milestone to decommissioning evidence.

Track benefits after stabilization

Measure benefits after the workload has reached a stable operating period. Compare like-for-like periods and volumes. Report: Avoid attributing every later improvement to the migration. Record the architecture, workload, volume, pricing, and operational changes that influenced the result. A price change by the cloud provider and a seasonal volume change both move unit cost, and neither one is migration value. Separating them keeps the next business case credible.

Unit-cost trend
Reliability and latency
Engineering effort
Release frequency
Data freshness
Support incidents
Source cost retired
New capability delivered

Lessons from delivery

Measure the first wave, then re-estimate the program. The defect rate, conversion throughput, sign-off rate, and parallel-run duration from one real wave are worth more than any workshop estimate. Put the finance partner inside the delivery review. A model that finance inspects weekly stays honest. A model presented quarterly drifts toward the answer someone wants. Keep the evidence. The reconciliation reports, cutover timings, and rollback tests from one migration become the estimating baseline for the next one, and organizations that discard them pay to relearn the same lessons.

Migration review checklist

Is the workload inventory complete enough to plan waves?
Does every unit have a reconciliation method?
Does the model include parallel-run and decommission cost?
Are target costs based on representative load?
Are licenses, support, and engineering labor included?
Is the unit metric tied to a business service?
Does each cutover step have a tested rollback path?
Who approves acceptance and decommissioning?
When will the business case be measured again?