A cloud migration strategy is the plan for moving an organization's applications, data, and operations from existing infrastructure (data centers, colocation, older clouds) into cloud platforms: which workloads move, in what order, by which method, to what target architecture, and how the business keeps running throughout. The strategy is a portfolio decision repeated hundreds of times, because every application in the estate gets its own disposition, and the quality of those individual calls compounds into the program's outcome.
The standard vocabulary is the "Rs" framework, which has grown from five to seven over the years. Rehost (lift and shift): move the workload unchanged onto cloud VMs. Replatform (lift and reshape): targeted swaps on the way over (managed database, containers) without touching application logic. Repurchase: retire the custom system for SaaS. Refactor or re-architect: restructure the application to exploit cloud properties. Retire: discover the workload serves nobody and decommission it. Retain: leave it where it is, deliberately. Relocate: move at the hypervisor level (VMware estates shifting wholesale) without even re-imaging. A real migration portfolio uses most of these, and the strategy's first deliverable is the assignment of each application to one.
The motivations have matured since the first wave. The early business cases promised cost savings, which materialized inconsistently and embarrassed a generation of CFO decks; like-for-like rehosting frequently costs more than the data center it left. The durable drivers are different: data center exits with hard deadlines (lease expirations, hardware end-of-life), capacity and elasticity that procurement cycles cannot deliver, access to managed services and AI infrastructure that exists nowhere else, acquisition integration, and the talent reality that infrastructure skills increasingly concentrate in cloud idioms. Cost improvement is achievable, but as a result of post-migration optimization work, not of the move itself.
The strategy's hardest content is sequencing and honesty. Sequencing: which applications move first (the rule of thumb: meaningful but survivable, to build capability before the crown jewels move), what the dependency groupings are (applications that share databases move together or suffer), and when the data center actually closes (the savings arrive at closure, not at first workload). Honesty: about the undocumented dependencies that discovery will surface, about the dual-running costs of the middle period, and about the organizational change (operations, security, finance all work differently in cloud) that the infrastructure project label conceals.
This page covers the disposition framework and how to apply it, the program mechanics from discovery to cutover, the cost realities that surprise at month four, and the patterns that separate completed migrations from the permanent hybrid limbo where many programs quietly settle.
Rehost is the workhorse for deadline-driven programs and the trap for everyone else. Moving VMs as-is maximizes speed and minimizes per-application risk, which is exactly right when a data center lease expires in eighteen months and three hundred applications must move. The trap: a rehosted application keeps its old architecture and acquires cloud pricing, frequently costing more than before, sized for a peak it now pays for hourly. Rehost works as a strategy when it is explicitly phase one of two (move fast, then optimize in place), and fails as a destination.
Replatform is where most of the portfolio should land. The targeted swaps (self-managed database to RDS-class services, app servers to containers, file shares to object storage, cron jobs to managed schedulers) capture a large share of cloud's operational value at a small share of refactoring's cost, without touching business logic. The discipline is the boundary: replatforming becomes refactoring through a series of small mid-flight decisions ("while we're in here..."), each defensible, the sum a schedule and budget the program never approved.
Refactor is for the workloads where cloud properties are the point. The applications whose scaling, release velocity, or resilience requirements genuinely need cloud-native architecture (event-driven designs, autoscaling services, managed data platforms) justify restructuring, and they are a minority of any portfolio. The honest test: would this application's business case fund its re-architecture even without a migration deadline? If the answer is no, the migration is being used to launder a rewrite, and the rewrite's risks come along.
Repurchase, retire, and retain are the underused dispositions. Migration discovery is the best inventory audit most organizations ever run, and it reliably finds applications nobody uses (retire: the cheapest migration is deletion), custom systems doing what SaaS now does better (repurchase: HR, expense, ticketing, email long ago; increasingly analytics and integration middleware), and systems that should not move at all (retain: the mainframe with no cloud story, the latency-bound factory system, the application three years from retirement that survives in place). Programs that skip the honest pass through these three dispositions migrate workloads that should have been ended, and pay cloud prices to keep mistakes alive.
Relocate deserves its modern mention: hypervisor-level moves (VMware estates onto cloud-hosted VMware) shift hundreds of VMs in weeks without re-imaging, at the price of bringing the old operating model along intact and adding licensing economics that have recently turned sharply unfavorable. It is the speed play for hard deadlines, with the same phase-two obligation as rehost and an extra incentive to make phase two real.
Discovery is where programs are won, eighteen months before anyone notices. The inventory is always worse than believed: applications missing from the CMDB, dependencies undocumented (the reporting job that reads the order database directly, the file share four departments quietly depend on, the hardcoded IP addresses), and owners who left years ago. Modern discovery combines automated tooling (network flow analysis, agent-based dependency mapping) with the interviews that surface what tooling cannot (why does this exist, who screams if it stops). The output that matters is the dependency map, because it defines the move groups: applications that must travel together because untangling them costs more than co-scheduling them.
Wave planning converts the map into a schedule. Early waves: real applications with real users but survivable failure modes, chosen to exercise the full machinery (landing zone, networking, identity, deployment pipeline, cutover process, rollback) while mistakes are affordable. Middle waves: the bulk of the portfolio, industrialized (the program should be running a repeatable factory by wave three, with runbooks, automation, and a cadence). Late waves: the crown jewels and the gnarly exceptions, attempted when the team has dozens of cutovers of experience. The anti-pattern is the inverse: starting with the hardest system to "prove commitment," which proves instead how programs end early.
The landing zone is the prerequisite that deadline pressure always wants to skip. Identity integration, network architecture (the connectivity back to remaining on-premises estates, which exists in every real migration), security baselines, account/subscription structure, logging, and guardrails: the platform into which workloads land. Programs that build it properly first move slower for a quarter and faster forever after; programs that skip it migrate workloads into chaos and retrofit governance against live traffic, which is the expensive order.
Data migration is its own engineering discipline inside the program. Large datasets move by physical appliance or dedicated links (bandwidth math is unforgiving at scale); databases move by replication with cutover windows measured in minutes (the same CDC machinery that powers real-time pipelines); the long tail of file shares and object data moves by sync tools with verification. The recurring failure is treating data as an attribute of the application rather than a workstream: the application cutover that waits on a replication backlog, the integrity verification skipped under deadline, the synchronization running both directions because cutover was partial.
Cutover discipline is what makes waves boring, and boring is the goal. Each application cutover is rehearsed (at least once in a staging move), scheduled with a rollback decision point and criteria, executed against a runbook, verified against defined checks (functional, performance, data integrity), and followed by a hypercare window with the migration team on call. By the twentieth cutover this is routine, which is precisely the achievement: migration programs succeed by making an inherently risky operation repetitive, and the rehearsal-runbook-rollback triad is how.
The dual-running period is the budget's hidden center. From first workload to data center closure, the organization pays for both estates: cloud consumption ramping up, data center costs continuing (the lease does not prorate, the hardware support contracts persist, the staff cover both), plus the program's own costs (tooling, partners, backfill). Business cases that model migration savings as starting at first workload are wrong by one to three years; the savings curve starts at decommissioning events (a closed data hall, an ended lease, a retired support contract), and the program should be managed against those events explicitly.
Like-for-like pricing disappoints by design. A VM sized for peak load, running 24/7 in the cloud, costs more than its depreciated on-premises equivalent; that is the rehost trap restated in money. The cloud economics arrive through behaviors the old estate could not express: right-sizing against actual utilization (the first FinOps pass reliably finds 30-50% oversizing in rehosted estates), scheduling (development environments off at night), reserved and spot purchasing, storage tiering, and the replatform moves that replace self-managed infrastructure with services billed by use. The corollary: budget the optimization program as part of the migration, not as a someday, because unoptimized rehosted estates are the source of most cloud-cost disillusionment.
Egress, licensing, and the small print compound at portfolio scale. Data egress charges surprise architectures that span the hybrid boundary chattily; software licensing in the cloud (databases and enterprise software with per-core terms designed for a different era, virtualization licensing repriced sharply) can dominate individual workload economics and occasionally flips dispositions (the application whose database licensing makes repurchase or refactor cheaper than rehost); and the long tail of cloud services (NAT gateways, cross-AZ traffic, logging ingestion) accumulates into a visible line that nobody itemized.
The organizational costs are real even though no invoice carries them. Operations teams retrained from hardware to platform engineering; security re-tooled from perimeter to identity-and-configuration; finance moved from capex planning to consumption management (FinOps as a function, not a tool); on-call and incident processes rebuilt for a new failure catalog. Programs that fund only the infrastructure work get estates run by teams still operating on data center instincts, which manifests as outages, overspend, and the quiet rebuilding of old patterns (static fleets, manual changes) inside the new platform.
Measured honestly, the migration's return usually rests on four legs: the avoided costs (data center exits, hardware refresh cycles dodged, the capacity buildout not built), the optimization gains (post-migration right-sizing and replatforming), the velocity dividend (provisioning in minutes against procurement in months, which shows up in product delivery rather than in IT budgets), and the option value (managed services, AI infrastructure, global regions, all available without capital projects). Cases built solely on infrastructure unit-cost comparison miss the legs that actually carry most successful programs.
The 80% stall is the signature failure. The movable workloads move, the program celebrates, and the remainder (the gnarly dependencies, the mainframe-adjacent systems, the applications whose owners resisted) sits in the data center, which now cannot close, which means the savings never arrive while the dual-running costs continue indefinitely. Finishers differ at the start: they scope the hard 20% first (sometimes deciding retain or retire explicitly, with the closure plan adjusted), they tie the program's definition of done to decommissioning events rather than migration counts, and they keep a named owner on the data center exit date with executive visibility.
Stalled programs migrated infrastructure; finished programs migrated operations. The recurring stall pattern: workloads in the cloud, operated like a data center: static capacity, manual changes, perimeter security thinking, no cost accountability. The cloud then under-delivers on every promised dimension, skeptics are vindicated, and momentum dies. Finishers invest in the operating model in parallel: platform teams, infrastructure as code as the default (often introduced during the migration itself, since every workload needs definition anyway), FinOps from the first bill, and security rebuilt around identity and configuration. The migration is the occasion; the operating model is the outcome.
Application owners decide velocity more than engineers do. Every workload has a stakeholder with reasons to delay (change freeze, busy season, mistrust, simple inertia), and a program that negotiates each move individually moves at the speed of its most reluctant owner. Finishers industrialize the social process too: executive mandate with a real date, standard treatment paths that make cooperation cheap (the program does the work for standard cases), escalation that actually escalates, and scoreboard transparency that makes laggards visible. This is unglamorous program management, and it predicts completion better than any technology choice.
Partners and tooling help where the factory needs scale, and mislead where strategy is outsourced. Migration partners bring discovery tooling, runbook libraries, and labor for the industrial middle; the failure mode is delegating dispositions and target architecture to a vendor whose incentives favor maximum migration (rehost everything, bill the hours) over the right portfolio mix including retire and repurchase. The dispositions, the sequencing, and the operating model design are the organization's strategy and should be owned in-house, however much of the execution is bought.
And the calendar is a forcing function worth engineering. Programs with hard external deadlines (lease expiry, divestiture, hardware end-of-life) complete at much higher rates than open-ended modernization journeys, because the deadline disciplines scope (dispositions get decided, the hard 20% gets confronted) and overrides the per-owner negotiation drift. Programs without a natural deadline benefit from manufacturing one: a committed decommissioning date with consequences, announced executive-down, converts migration from aspiration to schedule, which is the single cheapest intervention available to a stalling program.
Quarter one is discovery and the landing zone, run in parallel. Discovery tooling deploys across the estate (flow mapping, dependency agents, utilization capture) while the interviews work through application owners; the output is the inventory with dispositions drafted and the dependency-derived move groups. Simultaneously the platform workstream builds the landing zone: account structure, identity federation, network connectivity to the data center (the hybrid link every migration runs over), security baselines, logging, and the IaC pipelines that will define everything that lands. Neither workstream should wait for the other; both should resist the pressure to migrate something visible before either is ready.
Quarter two proves the machinery on the first wave. A handful of applications (real users, survivable stakes, spanning the common patterns: a web application, something with a database, something with file dependencies) go through the full lifecycle: disposition confirmed, target built via IaC, data migrated with verification, cutover rehearsed then executed against a runbook with rollback criteria, hypercare, and a retrospective that hardens the runbook for the factory phase. The wave's purpose is calibration, and its honest outputs are the program's first real numbers: hours per application by disposition, the surprise rate, and the dual-running cost curve, all of which should update the business case while updating it is still cheap.
The early decisions that disproportionately matter: the retire list gets actioned immediately (decommissioning dead applications is pure savings and builds credibility), the disposition mix gets defended against drift (the replatform that wants to become a refactor, the retain that someone relitigates), and the data center exit date gets a named owner and a public countdown, because the entire program's economics hang on it and every constituency benefits from forgetting it.
What should explicitly not happen in the first two quarters: volume migration before the landing zone is governed (workloads landing into chaos), the hardest system as a proof of commitment (the program's machinery is unproven), and partner-led disposition decisions (the strategy outsourced to incentives that favor maximum migration). Programs that hold these lines spend their first six months looking slower than programs that do not, and their second year looking dramatically faster, which is the trade the whole discipline keeps relearning.
The plan that assigns every application a disposition (rehost, replatform, repurchase, refactor, retire, retain, or relocate), sequences the moves into waves around dependencies and deadlines, and defines the target operating model that makes the migrated estate worth having.
Rehost (move unchanged), replatform (targeted swaps to managed services), repurchase (replace with SaaS), refactor (re-architect for cloud), retire (decommission), retain (deliberately leave in place), and relocate (hypervisor-level moves of virtualized estates). Real portfolios use most of them, and the disposition mix is the strategy's core content.
A few dozen applications: six months to a year. Enterprise portfolios of hundreds: two to four years, dominated by discovery, the industrial middle, and the stubborn final 20%. The program-level truth: the timeline to first workload is short and impressive, and the timeline to data center closure (where savings live) is the one to manage.
Mostly neither extreme: replatform is the right default for the bulk of a portfolio, capturing managed-service value without rewriting logic. Rehost wins under hard deadlines as an explicit phase one. Refactor is for the minority of workloads whose requirements would justify re-architecture even without a migration, and using the migration to smuggle in rewrites imports rewrite risk at portfolio scale.
Because a rehosted application keeps its old shape at cloud prices: sized for peak, running 24/7, self-managing infrastructure that managed services would replace. The corrective work (right-sizing against utilization, scheduling, reserved/spot purchasing, replatforming) is where the economics actually live, which is why optimization belongs in the program budget, not the someday list.
Three perennials: undocumented dependencies (discovery is always worse than the CMDB claims), the dual-running period (both estates paid for until decommissioning), and the operating model change (teams, processes, and finance working in new ways). Egress and software licensing fill out the surprise list at the portfolio's edges.
When latency or physics bind it to a site (factory floors, trading proximity), when licensing or architecture make cloud economics permanently worse, when it is near retirement (migrating a system with two years to live rarely pays), or when regulation genuinely requires specific infrastructure. Deliberate retain decisions, documented, are a sign of a healthy strategy rather than a failure of nerve.
Scope the hard 20% first and decide its fate explicitly; define done as decommissioning events with a named owner on the exit date; industrialize the social process (mandates, standard paths, visible scoreboards) so reluctant application owners do not set the pace; and protect the optimization and operating-model work that keeps cloud credibility alive through the long middle.
For portfolios beyond a few dozen applications, partners add real value in discovery tooling, runbook factories, and execution labor. Keep the strategy in-house: dispositions, sequencing, target architecture, and operating model are decisions whose incentives should be yours, since a partner billing by the migrated workload has opinions about retire and repurchase that you should not inherit.
