Cloud migration is the controlled transfer of applications, data and supporting infrastructure from an owned data centre into a provider’s environment. The decision is usually framed as technical, yet it is settled by business trade-offs: which outcome the move must produce, what the organisation can afford to disturb, and how the portfolio is sequenced.
Quick Overview
What you’ll learn from this article:
- How to turn a stated business outcome into a migration scope that can be planned
- How to build an inventory and a dependency map that hold up under execution
- How to assign a migration strategy per application instead of applying one approach to the whole portfolio
- How to validate, cut over and roll back without betting the business on a single evening
- How to keep cost and operating discipline after the landing, when the project ends and the running bill begins
Who this article is for: IT directors and heads of infrastructure preparing a migration decision, architects designing the target environment, and programme managers accountable for the schedule and the budget.
Reading time: 17 minutes
Why Migration Is a Programme, Not a Project
The most expensive framing error is treating the move as a delivery project with a start, an end and a handover. A project ends when the last workload is running elsewhere. A migration does not: the moment traffic lands, the organisation inherits a new cost model, a new operating model, a new security boundary and a new set of failure modes. Teams that plan only to the cutover date discover the rest of the work after the budget has been spent.
The programme framing changes concrete decisions. It puts a standing owner on the effort rather than a temporary lead. It funds a period of parallel running, in which part of the estate sits in the old environment and part in the new, instead of assuming a clean switch. It reserves capacity for optimisation after landing, which is where most of the promised savings actually materialise. Microsoft’s Develop a Cloud Adoption Strategy guidance makes the same separation, treating motivation, business justification and readiness as distinct workstreams that precede any migration wave.
The framing also decides who is in the room. A project invites infrastructure and application owners. A programme also needs finance, because the spending model shifts from capital purchase to running consumption; procurement, because contracts and licensing move; risk and compliance, because data location and shared responsibility change; and the people who will run the services afterwards. An empty seat during planning surfaces later as a blocked wave.
Naming the Business Outcome Before the Target Platform
Migration is rarely worth doing for its own sake. It is an instrument, and the instrument has to be pointed at something nameable. Outcomes that hold up under scrutiny are specific: exiting a data centre before a lease expires, removing a scaling ceiling that already costs revenue, shortening the path from code to production, entering a market where latency or data residency blocks you, or replacing an ageing platform whose maintenance skills are leaving the labour market.
Each outcome implies a different migration. A lease deadline compresses the schedule and pushes the portfolio towards the fastest strategies, accepting that optimisation comes later. A scaling ceiling points at particular applications rather than the whole estate, and the honest scope may be a handful of systems. A delivery-speed goal is not fixed by moving virtual machines at all — it is fixed by the pipeline, the release process and the ownership model, and moving machines without those changes reproduces the old constraints on rented hardware.
Write the outcome down as a claim that could later be shown false. “Reduce infrastructure cost” is not such a claim; “leave the data centre before the contract renews, without raising the monthly run rate for the migrated systems” is. The second form survives into the measurement section of the plan; the first quietly becomes whatever the result happens to be.
The outcome also settles what is explicitly out of scope — systems near end of life, applications already scheduled for replacement, workloads whose regulatory position is unresolved. Naming them as excluded at the start is cheaper than defending each one under schedule pressure.
Building an Inventory That Survives Contact With Reality
Every migration plan rests on an inventory, and most inventories are optimistic. Configuration databases drift, ownership records go stale, and environments accumulate systems no document mentions. The inventory step is therefore not document-gathering; it is discovery, reconciled against what the network actually shows.
A usable inventory records, for each application: the servers and services it runs on, the databases it touches, the integrations it exposes and consumes, its licensing position, its performance and availability expectations, its regulatory constraints, and — the field most often missing — a named business owner and a named technical owner. Utilisation over a full business cycle matters more than a point-in-time snapshot, because sizing decided on a quiet week produces a bill that surprises finance at quarter end.
Automated discovery tooling shortens the mechanical part but does not replace the interviews. Discovery finds traffic between hosts; it does not know that a nightly file drop is the settlement process, or that a system nobody claims is the only place a regulator-facing report is produced. Google Cloud’s Migrate to Google Cloud: Get started guidance treats assessment as a distinct phase for this reason, ahead of planning or deployment.
Expect the inventory to change the scope. Discovery routinely surfaces systems that qualify for decommissioning before they ever reach a migration decision, along with duplicate tooling that consolidation removes. Retiring a system is the cheapest migration available, and the audit is the moment it becomes visible.
Mapping Dependencies and Cutting the Portfolio Into Waves
An application does not move alone. It moves with whatever it must talk to, and the cost of learning that late is an outage. Dependency mapping records the flows: synchronous calls that fail when latency changes, asynchronous flows that tolerate a pause, shared databases that cannot be split without a data strategy, batch jobs whose windows assume a single network, and external integrations whose vendor may need notice.
The map exists to be cut. Grouping applications into waves — sets that move together — turns a portfolio into a schedule. A good wave is internally coupled and externally loose: the systems inside depend on each other, and their outside dependencies are few enough to bridge with a temporary connection. A bad wave is assembled by business unit or alphabetical order, and keeps a chatty link open across environments indefinitely.
Sequencing follows from the map plus the risk appetite. The first wave should be one the organisation can afford to get wrong: a system with real users, but without the exposure of a revenue-critical platform. That wave is where the team learns the tooling, discovers what the runbook missed, and calibrates how long the work takes — the estimate for wave one is a guess, the estimate for wave four is evidence. The same staged logic underpins the client questions collected in on-premise to AWS cloud migration: the questions we hear most from clients, where the pilot exists to buy experience before high-risk systems move.
Plan for coexistence explicitly. While waves are in flight, part of the estate sits in each place, and the link between them needs a data synchronisation strategy, a security position and an owner. Coexistence is a designed state with an end date, not an accident the schedule apologises for.
The Six Migration Strategies and How to Assign Them
The strategy catalogue that most organisations use descends from 6 Strategies for Migrating Applications to the Cloud, the AWS enterprise strategy note that gave the industry its shorthand. The value of the catalogue is not the naming. It is the discipline of assigning a strategy per application, against stated criteria, rather than choosing an approach for the estate and forcing every system through it.
- Rehost moves the application essentially unchanged onto rented infrastructure. It is the fastest route out of a data centre and the least disruptive to the application team, and it deliberately postpones the benefits: what could not scale before will not scale afterwards, and its cost profile follows the machines it used to occupy. Choose it under deadline pressure, for packaged software you cannot modify, or for systems whose future is short.
- Replatform moves the application while taking a limited, bounded optimisation — a self-managed database becoming a managed service, an unsupported operating system stepping up a version, a hand-rolled load balancer becoming a platform feature. It buys a real share of the operational benefit for a fraction of the redesign effort, and it is the default worth arguing against rather than the exception.
- Refactor reworks the application’s architecture so it can use the target environment properly: decomposition, containerisation, managed messaging, autoscaling as a design assumption rather than a bolt-on. It is the strategy that produces the outcomes people quote when they justify migrations, and it is priced accordingly, in engineering months and in the risk of touching working code.
- Rebuild discards the implementation and writes the capability again on the target platform. It becomes rational when the existing codebase is a liability in its own right — unmaintainable, unstaffable, or so far from current requirements that refactoring means rewriting anyway. The business case has to survive the comparison with buying instead of building.
- Repurchase replaces the application with a commercial subscription service. For commodity capability — collaboration, service desk, expense handling, much of finance and human resources — the market has matured to the point where custom maintenance is hard to defend. The evaluation is a procurement exercise about fit, integration, data portability and exit, not an infrastructure exercise.
- Retire switches the system off. Every serious audit finds candidates: superseded reporting tools, environments kept alive for a project that ended, duplicate systems inherited through acquisition. Nothing else in the catalogue delivers savings this cleanly.
Assignment needs criteria written down before the portfolio is scored, otherwise it becomes advocacy. Useful criteria: remaining business life, coupling to the rest of the estate, whether the code can be changed at all, licensing implications on the target, regulatory constraints on where data may sit, and the availability of people who understand the system well enough to change it safely. Score the portfolio against those, then review the outliers — assignments that surprise the reviewers are where the interesting information sits.
Two failure patterns recur. The first is uniform rehosting, which converts a capital cost into an operating cost and produces a bill without a benefit; it is defensible only when the deadline genuinely dominates and the optimisation is funded as a following phase. The second is ambitious refactoring applied to the first wave, before the team has run a single migration and while the pressure to show progress is highest.
Choosing the Deployment Model Underneath the Strategy
Strategy assignment assumes a target, and the target is a deployment model, not just a provider. The NIST Definition of Cloud Computing still supplies the vocabulary the industry argues in: the service models that separate infrastructure, platform and software responsibilities, and the deployment models — public, private, community, hybrid — that separate who the environment is for. Choosing among them is the first architectural decision the migration inherits, and it constrains everything downstream.
Public infrastructure offers the widest service catalogue and the most elastic consumption. A private environment, owned or hosted, keeps control where regulation or genuinely unusual workload shapes demand it. Hybrid arrangements keep part of the estate local by design rather than by inertia — a legitimate end state, not a half-finished migration. Multi-provider arrangements buy negotiating position and resilience against provider-level failure, at the cost of running identity, networking, monitoring, cost management and the necessary skills twice.
The decision belongs before wave planning because it changes the assignment. An application destined for a private environment gets a different strategy than the same application headed for a public platform with managed services available. The criteria and trade-offs are worked through in detail in public, private or hybrid cloud: how to choose the right cloud strategy, and the choice made there is an input to the portfolio scoring described above, not a parallel exercise.
Turning the Assignment Into a Plan With Dates That Hold
A migration plan is credible when its dates are derived rather than declared. The derivation runs from the wave structure: each wave has a preparation, execution, validation and stabilisation window, sized from measured effort on comparable systems rather than from the deadline working backwards.
The plan should carry, per wave: the systems in scope, the strategy assigned to each, the target environment, the preparation tasks and their owners, the data migration approach, the validation criteria that must pass before cutover, the cutover procedure, the rollback procedure with its decision point, and the communication plan for the people who will notice. Microsoft’s Plan your migration guidance structures the same material as a repeating cycle of assess, deploy and release per workload, which is a useful corrective to plans that treat migration as a single sequential push.
Resource planning is where optimistic schedules break. The people who understand the legacy systems are the people who run them, and they cannot do both at full capacity. Either the run load drops during the wave, or external capacity is brought in, or the schedule accommodates the constraint — pretending it is absent produces the third outcome anyway, with worse morale.
Build the plan to be revised: after each wave, set measured effort against the estimate and reprice what remains. A programme that never adjusts its dates is not disciplined; it is not measuring.
The Stages of Execution
Within a wave, the sequence is stable across environments and providers. Assessment confirms what the inventory claimed and closes gaps. Design fixes the target architecture: network topology, identity and access model, data placement, resilience posture, monitoring and the operational model that will run the result. Build stands up the target environment and its deployment pipelines. Migration moves the application and its data by the assigned strategy. Validation proves the result, cutover redirects users, and optimisation — starting the day after and never ending — tunes cost, performance and reliability against what production actually does.
Data movement deserves its own thinking within that sequence. The approach depends on volume, on how much the data changes during the move, and on the downtime the business will accept. A modest dataset that can pause tolerates a copy during a maintenance window; a large or continuously changing one needs replication running ahead of the cutover, with the final switch closing a small delta. Historical archives can often move separately and early, shrinking the critical path.
Environment build is worth doing once, properly. Landing zones — the pre-built account structure, network layout, identity model, guardrails and logging that every workload inherits — are what stop the estate becoming a collection of individually reasonable, mutually incompatible arrangements. Microsoft’s Ready your Azure cloud operations guidance treats this preparation as a prerequisite to migration rather than an outcome of it.
Validating Before Cutover
Validation answers a narrow question: does the migrated system do what the original did, well enough, under the conditions it will actually meet? The answer needs evidence in several dimensions, and the criteria should be agreed before the wave starts, when nobody is under pressure to declare success.
Functional testing confirms behaviour, ideally against the source system rather than against a specification that may itself be stale. Integration testing exercises the flows the dependency map identified, including those crossing the coexistence boundary. Performance testing runs against realistic load, because the failure that matters appears at the busiest hour. Security testing checks the target configuration — misconfiguration of the new environment is a more common source of exposure than any platform weakness. Recovery testing proves the backup and restore path, which is a different path from the old one and has never been exercised.
User acceptance closes the loop technical testing cannot. Daily users notice the report that renders differently, the export missing a column, the job finishing later than the downstream process expects. Giving them a working environment before cutover is cheaper than discovering the same list afterwards through the service desk.
Treat validation results as a gate with a named decision-maker. A wave that fails its criteria and proceeds anyway has converted a testing process into a formality, and the organisation will treat the next gate accordingly.
Designing the Cutover and the Way Back
Cutover is the moment of exposure, and its risk is managed by design rather than by care. Write the procedure as a runbook with timings, named owners, explicit verification after each step and a communication schedule. Rehearse it — a dry run against a non-production copy finds the ordering mistakes a document review does not.
Every cutover needs a defined way back. The rollback plan states what triggers it, who is authorised to call it, how long the decision window stays open, and what has to be true for it to work — above all, whether data written in the new environment can be reconciled with the old, which is what makes rollback genuinely rather than nominally available. Keeping the source environment on standby for a defined period buys that option; running both costs money, and it is cheap against the alternative for a critical system.
The decision window should be short and explicit. An open-ended rollback option quietly becomes permanent coexistence, which carries the cost of both environments and the benefits of neither. Name the date on which the source environment is switched off, and make switching it off a tracked task with an owner.
Security and Compliance While Systems Are in Motion
Data in transit between environments is the migration’s most concentrated risk, and it is handled with familiar controls applied deliberately: encryption in transit and at rest, dedicated or private connectivity rather than the public internet where volume and sensitivity justify it, and tightly scoped credentials for the migration tooling itself. Migration accounts are frequently over-privileged because it is convenient, and they are frequently left in place afterwards because nobody owns their removal.
The compliance position changes shape rather than disappearing. Responsibility is now shared with the provider, and the boundary sits in a different place for infrastructure, platform and software services — a distinction Cloud Computing Synopsis and Recommendations works through in detail. Obligations once satisfied by physical control of a data centre now depend on contract, configuration and evidence. Data residency, retention, access logging and the right to audit need restating against the target before the wave, not after a regulator asks.
Identity is the control plane that matters most in the target environment. Access that was implicitly bounded by the network perimeter now depends on the identity model, so least privilege, separation of duties and reviewable access grants stop being good practice and start being the primary control. Establishing that model in the landing zone, before workloads arrive, avoids retrofitting it across an estate that has already grown.
Measuring Whether the Migration Delivered
Success is measured against the outcome named at the start, which is why the naming mattered. The measurement needs a baseline captured before the move — the current cost, the current performance, the current availability, the current release cadence — because a comparison against remembered numbers is not a comparison.
Business-side indicators follow the stated outcome: total cost of ownership including operational costs that used to sit in other budgets, time from decision to production, availability against commitments made to the business, and the specific capability the migration was meant to unlock. Technical indicators track the health of the result: response times under real load, error rates, recovery times, and how much of the estate now runs on managed services rather than self-maintained infrastructure.
Take the cost measurement over a complete billing cycle before drawing conclusions. Consumption billing has a shape that a partial month misrepresents, and an unoptimised environment in its first weeks is not evidence about the steady state. It is evidence about the optimisation work that has not happened yet.
Report the measurements to the people who approved the programme, including the ones that disappoint. A migration reported only through its successes teaches the organisation nothing about the next wave.
Controlling Cost After Landing
The most reliable surprise in cloud migration is the bill. Consumption pricing removes the friction that used to constrain provisioning: nobody has to sign a purchase order to leave an oversized environment running. The discipline that replaces the purchase order is a practice, and the FinOps Framework Overview describes it as a continuous cycle of informing, optimising and operating, owned jointly by engineering, finance and the business rather than delegated to any of them.
The mechanics are unglamorous and effective. Attribute spend to owners through consistent tagging, so consumption has an address. Right-size against measured utilisation, not against the machine the workload used to occupy. Shut down non-production environments outside working hours. Use commitment-based pricing for the steady baseline once its shape is known. Watch storage tiering and data transfer, which accumulate quietly and rarely appear in the first estimate.
The organisational half matters more than the tooling. Cost information has to reach the engineers who can act on it, in a form that names their workloads, on a cadence short enough to matter. A monthly report to finance changes nothing; a weekly view owned by the team that provisioned the resources changes behaviour.
Preparing the Team and the Operating Model
The migration ends with people running something they have not run before. Preparation is partly technical — the target platform’s services, infrastructure as code, container orchestration where it applies, the pipeline that deploys into the new environment — and partly a change in how work is organised. Microsoft’s Prepare your organization for the cloud guidance treats skills readiness and operating-model design as prerequisites rather than follow-on activities, and the sequencing is deliberate.
The operating change tends to be the harder half. Ownership moves closer to the teams that build, monitoring becomes a design requirement instead of an afterthought, and the boundary between building and running blurs in ways that existing role definitions do not accommodate. The organisations that handle this well decide the target operating model during the design phase and staff towards it, rather than discovering after cutover that nobody is formally accountable for a service that now exists. Structured preparation is exactly what cloud migration — strategy, planning and execution is built around: assessing a portfolio, assigning strategies and rehearsing the execution sequence on a real case before the first wave is scheduled.
Training the team on the platform is necessary and insufficient. The skill that decides outcomes is judgement about trade-offs — when a managed service is worth its constraints, when a bounded optimisation is worth the delay, when to stop and reassess a wave. That judgement is built by running waves under supervision, which is another argument for a deliberately survivable first wave.
What This Article Deliberately Leaves Out
This is a guide to moving, not a guide to designing what you move into. The architectural question — what applications built for a cloud environment actually look like, which patterns hold under distribution, and how containers, orchestration and continuous delivery fit together — is a separate subject, treated in cloud native: designing and deploying applications in the cloud. The distinction is worth keeping sharp: knowing what a cloud-native system looks like does not tell you how to get an existing estate there, and a migration plan that quietly turns into an architecture programme is how deadlines are missed.
Provider-specific mechanics are also outside the frame. The strategies, the wave logic, the validation gates and the cost discipline described here transfer across platforms; the tooling, service names and commercial terms do not, and the details belong with the platform documentation and with the provider-specific material linked above.
Frequently Asked Questions
Should the whole portfolio move at once?
Almost never. Moving the estate in a single event concentrates every risk into one window and gives the team no opportunity to learn from a smaller attempt first. Wave-based migration, sequenced by dependency coupling and business criticality, spreads the risk and produces effort estimates grounded in measurement rather than assumption. The exception is a portfolio small and loosely coupled enough that waves would be an artificial construct.
Does migration automatically reduce IT costs?
No, and assuming it does is the most common budgeting error. Migration changes the cost model from owned capacity to consumed capacity; whether the total falls depends on what was moved, how it was sized, and whether anyone is actively managing consumption afterwards. Rehosting an oversized estate reproduces the oversizing on rented hardware and adds transfer charges. Savings come from optimisation work that has to be funded and owned, not from the move itself.
How do you decide between rehosting and refactoring an application?
Weigh the application’s remaining business life against the benefit that redesign would unlock and the risk of changing working code. A system with years ahead of it, a real scaling or delivery constraint, and a team able to change it safely is a candidate for refactoring. A system with an uncertain future, unavailable source, or a hard external deadline is a candidate for rehosting, with optimisation deferred to a named later phase rather than abandoned silently.
What has to be in place before the first wave starts?
A named outcome the programme will be judged against, a reconciled inventory with owners, a dependency map, a target environment with its identity and network model already established, validation criteria agreed by the people who will sign them off, and a rollback path that has been checked for data reconcilability. A wave that starts without the rollback path is not a migration wave; it is a bet.
How long should the source environment stay available after cutover?
Long enough to cover the period in which a problem missed by testing would realistically surface, which usually means at least one full business cycle for the affected systems — a month-end, a settlement run, a reporting deadline. Fix the date in advance, assign an owner to the decommissioning task, and treat an extension as a decision requiring a reason rather than a default.