Cloud migration strategy: the decisions that set the final bill

Most cloud migrations do not blow their budget during execution. They blow it months earlier, in a planning document, when someone decides to treat two hundred applications as one problem. A cloud migration strategy is a set of per-system decisions with a price attached to each: which of the six Rs applies to which workload, in what order the moves happen, who operates the result, and what it will cost to leave. This article walks through those decisions in the order they should be made, because that order is what the final bill is made of.

The bill is set before the first workload moves

By the time an engineer opens a console, the shape of the total cost is already fixed. What remains variable in execution is small: a delayed cutover here, a re-run data load there. The large numbers were locked in earlier, in four decisions:

• The disposition of each system. Rehost, replatform, refactor, repurchase, retire, or retain. Each carries a different upfront cost and a different monthly cost for the next decade.
• The sequence. It determines how long the company pays for two environments in parallel, and whether the migration produces evidence early enough to keep its funding.
• The run model. Who operates the migrated estate, with what skills and what cost discipline, decides whether the projected savings survive contact with the first twelve monthly invoices.
• The exit terms. Egress pricing, proprietary services, and data gravity are set at design time. They surface as a number only years later, when someone wants to move.

Treat these as strategy and the execution becomes largely mechanical. Skip them, and execution becomes the place where the gaps get discovered at daily rates.

Six Rs, decided per system, never globally

The 6R framework (rehost, replatform, refactor, repurchase, retire, retain) is well known. The failure mode is not ignorance of the framework. It is applying one answer to the whole portfolio because a per-system assessment looks slow.

A global "lift and shift everything" mandate is the common version. Rehosting is the cheapest move per system and the most expensive way to run one. A virtual machine that was sized for a 2015 procurement cycle, moved as-is, keeps its 2015 sizing and now bills for it hourly. Industry analyses have repeatedly found a large share of cloud spend is waste, and rehosted estates are where that waste concentrates: idle capacity, oversized instances, licensed software running on hardware profiles it no longer needs. The migration project closes on time and the run budget quietly absorbs the difference, month after month.

The opposite mandate, "we refactor everything to cloud-native," fails in the other direction. Refactoring is the most expensive move per system and only some systems repay it. A stable internal application with a dozen users and no roadmap does not need to become microservices. It needs to be rehosted cheaply, or better, examined for retirement.

The per-system pass is not slow. For a portfolio of a few hundred applications it is weeks of work with the right people in the room: an owner who knows the change frequency, an engineer who knows the dependencies, a number for what the system costs to run today. Out of that pass come the decisions with the highest return of the whole program:

• Retire is the most profitable R and the least used. Every estate we have assessed carried systems that no longer had users, only uptime. Migrating them costs money; retiring them returns it.
• Retain is a decision, and it deserves to be made explicitly. A latency-bound plant system, a regulated dataset with residency constraints, a mainframe workload whose re-platforming case does not close: leaving them where they are is often correct. An honest retain list also shrinks the program to what is worth doing.
• Repurchase questions whether the system should exist as custom software at all. If a maintained SaaS product covers the function, migrating the custom version means paying to preserve a liability.
• Rehost, replatform, refactor then split what remains, ranked by change frequency and value at stake. Systems that change weekly justify refactoring. Systems that change yearly justify a rehost and a calendar note to revisit.

The output is a dispositions table, one row per system, with a cost attached to each row. That table is the strategy. Everything after it is delivery.

Sequencing: how long do you pay twice?

Every migration has a transition period during which the company pays for both environments: the data center that cannot be shut down because half the estate still lives there, and the cloud environment that is already billing. Business cases routinely present the end state and skip this middle, yet the middle is where transition budgets go to die. A data center at 40% occupancy costs almost the same as a full one; the savings arrive when a hall closes or a colocation contract ends, and those events depend entirely on sequencing.

Three rules keep the double-pay window short and the program alive:

• Sequence to empty things, in units that terminate a cost. Moving whichever workloads are easiest scatters progress across the estate and empties nothing. Clustering moves by hall, by rack, by contract renewal date turns migration progress into cancelled invoices.
• Respect dependency clusters. Applications sharing a database or a low-latency link move together or suffer. A chatty application separated from its database by 20 milliseconds of round trip degrades in ways no capacity planning predicted. Discovering these clusters mid-flight is a schedule event; mapping them beforehand is a workshop.
• Put a proof point in the first quarter. A migration that produces a visible result early, a retired contract, a closed hall, a measurable saving, keeps its executive sponsorship. One that spends a year on landing zones and tooling gets renegotiated at the first budget review.

Sequencing is also where the 6R table earns its keep a second time: retirements go first because they are pure savings, retained systems are marked out of scope before anyone builds connectivity for them, and the expensive refactors are scheduled where the transition period does not depend on them.

Who carries the run

The least examined decision in most migration plans is who operates the estate afterward. It is also the decision with the longest financial tail, because the run phase lasts years and the migration lasts months.

Cloud platforms bill for consumption, and consumption is a product of daily engineering behavior: instances left running, environments cloned and forgotten, storage tiers never revisited, egress patterns nobody owns. A team that spent a career operating fixed capacity has no reflex for any of this, through no fault of its own. The reflexes have to be built, and they have to exist at cutover. Retrofitting cost discipline two years later, under the name FinOps, is the expensive route: by then the waste has structure and defenders.

Three questions settle the run model, and they belong in the strategy phase:

• Build or buy the operating capability? Training the internal team, hiring, or contracting a managed service provider are all viable. Deciding by default, meaning the old team inherits the new estate with no preparation, is the one option that reliably fails.
• Who owns the monthly number? One named owner per cost domain, with the authority to change what drives it. A cloud bill reviewed by a committee is a cloud bill that grows.
• Which guardrails exist on day one? Budget alerts, tagging enforcement, automatic shutdown of non-production environments outside working hours. These cost little to install during the migration and a political battle to install after it.

The run model also feeds back into the 6R table. If the operating capability will be thin for the first two years, the strategy should favor managed services and fewer moving parts, even at a higher unit price. A sophisticated architecture the team cannot operate is more expensive than a plain one it can.

Price the exit on the way in

Exit costs are decided at design time and paid at leaving time, which is why they are invisible in most business cases. Three of them deserve a line in the strategy document:

• Egress. Moving data into a cloud platform is free or nearly so; moving it out is billed per gigabyte. For a data-heavy estate, the cost of leaving can reach a figure that turns "we could switch providers" into a theoretical statement. The EU Data Act has pushed providers to reduce switching fees, and several now waive egress for customers leaving entirely, but the day-to-day egress of a multi-cloud or hybrid architecture remains a permanent operating cost that the initial design either contains or does not.
• Proprietary managed services. Every platform-specific database, queue, or serverless runtime trades portability for convenience. Sometimes that trade is right; the convenience is genuine. The strategy should name the trade per service, so the organization knows which parts of its estate could move in months and which would need a rewrite. For European organizations weighing dependence on non-EU providers, this same analysis underpins any credible sovereignty position.
• Data gravity. Analytics platforms, machine learning pipelines, and integrations accumulate around wherever the data lands. After three years, the data platform is the hardest thing to move on the estate. Choosing where it lands, and on which storage formats, open or proprietary, is an exit decision disguised as an architecture detail.

None of this argues against committing to a platform. It argues for committing with the price of the exit written down, so that the commitment is a decision instead of a discovery.

How DNA approaches it

We run the strategy phase as the deliverable it is: a per-system dispositions table with costs attached, a sequence built around terminating contracts and dependency clusters, a run model agreed before cutover, and the exit terms priced in the design. Our teams have carried this through on estates anchored by Oracle and SAP workloads, on billing platforms that could not tolerate downtime, and in transitions where the double-run period was the dominant cost. The pattern across all of them holds: the migrations that land on budget are the ones where the arguing happened in the planning phase. If your estate is heading for the cloud and the current plan fits on one slide, talk to us and we will help you build the table that should be behind it.