Cloud Migration Handbook: Best Practices for Applications

Most application migrations don’t fail on technology. They fail on everything around it: a business case that ignored dual-running costs, a CMDB nobody trusted, dependencies found during cutover, and source systems still running a year after go-live. Microsoft’s Cloud Adoption Framework (CAF), AWS Prescriptive Guidance and the Migration Acceleration Program (MAP), and Google Cloud’s migration framework all address these failures, under different names.

This handbook combines them into one working reference for migration leads, cloud architects and IT managers moving a real portfolio, some of it regulated, to Azure or AWS. It follows the program lifecycle and ends with phase checklists, a RACI table and a list of anti-patterns. It’s also the hub of a five-part series: VMware to public cloud, datacenter migration to Azure, lessons learned from application migrations and SAP migration to Azure.

Key takeaways

Run it as a program, not a set of server moves. McKinsey found that poorly orchestrated migrations cost the average company 14 percent more than planned each year.
Retire before you migrate. Every application you eliminate is one you don’t have to assess, test, cut over or pay for twice.
Dependencies are the top migration challenge in Flexera’s 2026 survey. Combine agentless discovery with owner interviews, and group components when in doubt.
Build the landing zone before the first production wave, and run it as a product rather than a project.
For large estates, rehost, relocate or replatform first, and modernize afterwards. AWS advises against refactoring during large migrations.
A migration isn’t finished until the source is decommissioned. Give decommissioning an owner, a date and an approval step in every wave.

How the major frameworks line up

The frameworks use different names for the same sequence. CAF’s top level is Strategy, Plan, Ready, Adopt, Govern, Secure and Manage, with the last three running in parallel once operations begin. Its Migrate guidance has five steps: plan, prepare workloads, execute, optimize, and decommission the source. AWS describes large migrations, which it defines as 300 or more servers, in three phases: assess, mobilize, and migrate and modernize. Google Cloud uses assess, plan, deploy and optimize.

Program stage	Microsoft CAF	AWS (MAP, Prescriptive Guidance)	Google Cloud
Why, what and how much	Strategy, Plan	Assess	Assess
Foundations and people	Ready (Azure landing zone)	Mobilize (landing zone, operating model, first migrations)	Plan (identity, organization, networking)
Moving workloads	Adopt: plan, prepare, execute	Migrate and modernize	Deploy
After the move	Optimize, decommission	Modernize after migration	Optimize
Ongoing disciplines	Govern, Secure, Manage	AWS CAF perspectives: Business, People, Governance, Platform, Security, Operations	Adoption themes: Learn, Lead, Scale, Secure

The Well-Architected frameworks sit alongside these. Azure’s has five pillars: reliability, security, cost optimization, operational excellence and performance efficiency. AWS’s has six, adding sustainability, and AWS publishes a Migration Lens that applies them to each migration phase. Use a Well-Architected review twice: during assessment to shape the target design, and after cutover to set a baseline for the modernization backlog.

1. Before you start

Goals and success metrics

CAF ties every migration decision to a business driver: the gap between where a workload is and where the business needs it to be. Typical drivers are a datacenter contract ending, hardware refresh, end-of-support software, resilience or delivery speed. Track three kinds of metric:

Outcome: exit date met, run-rate cost against the business case, SLA parity for Tier 1 workloads.
Flow: applications cut over per wave against plan, applications decommissioned at source, rollbacks, time to hypercare exit.
Risk: open high-severity risks, waves with complete compliance evidence, temporary exceptions still open.

Count what you’ve switched off, not just what you’ve moved. A dashboard that only tracks migrated servers can show success while the cost base doubles.

Executive sponsorship

AWS places the executive sponsor in the Cloud Enablement Engine, the program’s governance body, to manage escalations and act as “the voice of authority”. In practice the sponsor owns what nobody else can: the business case, dual-running funding, and the final call when a business unit refuses its freeze window. The sponsor also has to keep expectations realistic. Gartner predicts that 25 percent of organizations will have experienced significant dissatisfaction with their cloud adoption by 2028, citing unrealistic expectations, suboptimal implementation and uncontrolled costs.

Business case

Most business cases get the cloud run cost roughly right and the transition wrong. In Flexera’s 2026 survey, 43 percent of respondents named assessing on-premises versus cloud costs as a migration challenge. Make sure the case includes:

Dual running for every wave, from replication start to source decommissioning.
Hybrid connectivity, migration tooling and partner services.
Licensing changes, Extended Security Updates and ISV re-licensing.
Skills, plus source-side exit costs: contract notice periods, hardware disposal, support terminations.

McKinsey’s 2021 analysis estimated more than $100 billion in wasted migration spend globally over three years, and found that 38 percent of companies had migrations delayed by more than a quarter. The causes it named were poor orchestration, systems-integrator fees tied to time rather than outcomes, and missing in-house architecture expertise. Tie partner commercials to wave outcomes and keep design authority in-house. Vendor funding helps, but don’t build the case on it. Microsoft consolidated its offers into Azure Accelerate in July 2025, and AWS provides investments through MAP.

Operating model and the Cloud Center of Excellence

CAF describes three operating models. In the centralized model, one team owns governance, security and operations; CAF calls it ideal for highly regulated industries but warns that it becomes a bottleneck at scale. In shared management, a platform team provides the landing zone and guardrails as products, and workload teams operate within them. In the decentralized model, each team owns everything. Most regulated enterprises end up with shared management.

The Cloud Center of Excellence (CCoE) gives that model a home. CAF defines it as cloud adoption, strategy, governance, platform and automation functions working together. Flexera reports that 71 percent of organizations now have a CCoE or similar team. CAF is blunt about the alternative: operating with only cloud adoption teams “is considered an antipattern and should be avoided.”

Skills

CAF recommends a formal readiness assessment covering the target platform, migration tools and cutover. AWS’s list of large-migration roles works as a capability checklist: migration lead, portfolio lead, cloud operations, network and infrastructure, licensing, security and compliance, and application team leads. Fill gaps with partners but keep decisions in-house, and have operations staff run the non-production migrations. AI tooling can speed up the work. Options include GitHub Copilot app modernization for .NET and Java, agentic workflows in AWS Transform, and the Copilot migration agent (in preview) in Azure Migrate. Treat their output as input to engineering judgment.

2. Discover and assess

Inventory and the reality of your CMDB

Treat the CMDB as a hypothesis. Reconcile it against automated discovery from the Azure Migrate appliance, AWS Transform or Google Cloud Migration Center. The Azure Migrate appliance runs agentless against VMware, Hyper-V, physical servers and other clouds. Two tooling changes matter here:

AWS Migration Hub closed to new customers on 7 November 2025. AWS Transform is its successor.
Microsoft is deprecating the Azure Migrate classic view by the end of 2026. It’s the only place agent-based dependency analysis remains, so plan new projects on the agentless experience.

Reconciliation produces three lists: discovered but not in the CMDB (shadow IT), recorded but not found (stale records), and running but owned by nobody. The last list is your best source of retire candidates. Don’t migrate anything without a named owner.

Dependency mapping

Flexera’s 2026 survey ranks understanding application dependencies and assessing technical feasibility as the top two migration challenges. Agentless dependency analysis in Azure Migrate polls TCP connections every five minutes and records processes, applications and ports. However, network data only shows traffic during the observation window. Keep collection running through month-end, quarter-end and annual batch cycles.

Then add what a network scan can’t see:

Shared databases and linked servers.
File drops on UNC paths.
Hard-coded IP addresses, host files and certificates bound to hostnames.
License servers and SMTP relays.
Partner IP allow-lists.
Scheduled jobs running on someone’s workstation.

CAF notes that tools “might miss undocumented dependencies” and recommends structured interviews with workload owners. Its rule for gray areas is the right one: when criticality is uncertain, group the components together.

Application profiling

Build one profile per application, not per server, with the attributes that actually change decisions:

Attribute	Why it matters
Business and technical owner	Owners sign off testing, go/no-go and decommissioning. No owner, no migration.
Criticality tier, SLA, RTO, RPO	Sets the migration method, the DR design and the wave position.
Data classification	Drives region, encryption, key management and who may administer it.
Regulatory scope	Whether it supports NIS2-relevant services, DORA critical or important functions, or processes GDPR personal data.
Licensing and support status	End-of-support dates, bring-your-own-license eligibility, ISV support on the target cloud.
Performance baseline	Rightsizing input and the post-cutover comparison point.
Dependency group, freeze windows	Which wave it can join and when it can be cut over.

Record regulatory scope during assessment, not at the end. DORA critical or important functions bring contractual, register-of-information and exit-strategy obligations (see the DORA guide). NIS2 scope shapes detection and incident reporting (NIS2 guide). Personal data drives region, transfer and processor decisions (GDPR guide).

Licensing

Licensing changes business cases more often than architecture does. In Flexera’s 2026 survey, 78 percent of respondents cite managing software licenses as a cloud challenge, ranking it third. Check these dates now:

Windows Server 2012 and 2012 R2: Extended Security Updates ended on 13 October 2026. Anything still running is unpatched.
Windows Server 2016: reaches end of support on 12 January 2027. Billing for ESUs through Azure Arc starts the next day.
SQL Server 2016: extended support ended in July 2026. Moving it to an Azure VM no longer brings free ESUs; they are now a paid subscription.

Validate Azure Hybrid Benefit eligibility, which requires Software Assurance or a qualifying subscription. Confirm that each ISV supports your target platform. And make licensing a named workstream with an owner.

Rationalize first: retire before you migrate

Gartner’s TIME model sorts applications by technical fit (quality, maintainability, compatibility) and functional fit (how well they support the business). Run it before choosing any migration R. Note that TIME’s “Migrate” quadrant means moving to a better platform or product, which is not the same as moving to the cloud.

TIME quadrant	Fit	Typical treatment
Tolerate	High technical, low functional	Rehost or retain with minimal investment
Invest	High technical, high functional	Replatform or refactor
Migrate	Low technical, high functional	Replace with SaaS, rebuild or replatform
Eliminate	Low technical, low functional	Retire and archive data per retention rules

Choosing an R for each application

The “Rs” started with Gartner’s original five: rehost, refactor, revise, rebuild and replace. CAF now lists eight strategies and AWS uses seven. Agree on one vocabulary for your program:

Treatment	Microsoft CAF	AWS 7 Rs	Google Cloud
Decommission	Retire	Retire	Not listed
Keep in place	Retain	Retain	Not listed
Move as-is	Rehost	Rehost; Relocate (whole platform)	Rehost
Move to managed services	Replatform	Replatform	Replatform
Change code or architecture	Refactor; Rearchitect	Refactor or re-architect	Refactor; Re-architect
Rewrite	Rebuild	No separate R	Rebuild
Buy SaaS	Replace	Repurchase	Repurchase

A decision tree that works on either cloud:

No funded business value? Retire it.
Hard constraint on moving it now (regulation, plant-floor latency, hardware dongles, no vendor support)? Retain it, manage it from the cloud control plane (for example with Azure Arc), and set a review date.
Good-enough SaaS fit, with manageable data migration and process change? Replace it.
The platform itself is the deadline, such as a VMware renewal? Relocate, then work through the guests (see the VMware post).
Stable, supported, and no modernization needed within two years? Rehost it. That’s CAF’s test, along with a warning: “Don’t rehost problematic workloads.”
A managed service removes OS or database work with minimal code change? Replatform it.
Architecture blocks a real business driver, and you have the skills and time? Refactor or rearchitect it, usually after migration.
Obsolete, and modernization isn’t feasible? Rebuild it. CAF notes that some components, such as DHCP servers and Active Directory domain controllers, are better deployed fresh than migrated.

For large migrations, AWS says refactoring “is not recommended”: it is the most complex strategy and hard to manage across many applications. Its advice is to rehost, relocate or replatform first, then modernize. CAF agrees. Modernize during migration only when you have the skills and time, when compatibility forces it, or when the migration budget is the only realistic funding. Record each decision and its rationale with the business owner.

3. Prepare the platform

CAF lists an Azure landing zone as a prerequisite for the migration plan, and AWS builds one in its mobilize phase. Every migrated workload inherits the platform’s identity, network, policy and operations model. Retrofitting those after a hundred applications have landed is far harder than designing them first.

CAF’s landing zone design areas make a good checklist on any cloud:

Billing and tenant
Identity and access
Resource organization
Network
Security
Management
Governance
Platform automation

What to build in each area:

Structure. On Azure, use a management group hierarchy, separate platform and application landing zones, and subscription vending. Deploy with the Azure Landing Zones IaC accelerator using Azure Verified Modules in Bicep or Terraform; Microsoft recommends this over the portal accelerator. On AWS, start with AWS Control Tower and Account Factory, then extend with Customizations for Control Tower or the Landing Zone Accelerator.
Identity. Use Microsoft Entra ID or IAM Identity Center for people, and managed identities or IAM roles in place of the hard-coded service accounts that assessment uncovers. Add just-in-time privileged access and break-glass accounts. Build new domain controllers in the cloud for legacy applications that still need Active Directory.
Network. Plan for a non-overlapping IP plan, a hub-and-spoke or managed WAN, ExpressRoute or Direct Connect, two-way hybrid DNS, private endpoints and central egress inspection. Design for the months when half an application is still on-premises.
Security baseline. Turn on posture management and threat detection, such as Defender for Cloud, from day one. Send logs to the SIEM, keep keys in Key Vault or KMS, and run vulnerability management.
Policy-as-code. Use Azure Policy at management group scope, or service control policies plus AWS Config. Keep definitions in Git, deploy them through pipelines, and enforce allowed regions for data residency.
Observability. Azure Monitor or CloudWatch dashboards and alerts must exist before the first wave. Capture source baselines so you can prove parity.
Backup and DR. Use Azure Backup and Site Recovery, or AWS Backup, with immutable vaults for regulated data. Every tier needs a tested restore against its RTO and RPO before go-live.
FinOps tagging. Enforce tags by policy: application ID (matching the CMDB), owner, cost center, environment, data classification and wave. The FinOps cycle of inform, optimize and operate depends on attributing costs from the first day.
Sovereignty. Microsoft completed the final phase of its EU Data Boundary in February 2025. The AWS European Sovereign Cloud became generally available on 15 January 2026 in Brandenburg, Germany. Decide which workloads need which level of sovereignty before you fix target regions.

Run the landing zone as a product with a backlog and release process. Later waves will bring new requirements. The datacenter migration to Azure post goes deeper on the Azure build.

4. Plan waves

Group by dependency and risk

CAF distinguishes three kinds of dependency:

Direct dependencies are latency-sensitive and must move together.
Indirect dependencies can tolerate hybrid operation and may move separately.
Business dependencies, such as reporting tied to a process, should follow business priorities.

Build groups around shared databases, APIs, authentication and network paths. Then make sure each group is complete, including load balancers, DNS records and caches. Sequence the groups by risk:

Move non-production environments before production, and use them to rehearse rollback and train operations.
Start with lower-risk workloads, but add one or two representative complex ones to each early wave so problems surface early.
Schedule critical systems after the factory has proven itself. If hardware end-of-life forces them earlier, add safeguards and extend testing.
Keep split-environment operation short, and plan explicitly for the components that can’t move.

Detail only the next wave and keep later waves at a high level. CAF suggests checkpoints at 25, 50 and 75 percent of each wave. After every wave, compare actual and planned durations and adjust the remaining plan.

Lighthouse applications

The first production moves should prove the whole chain, not just the replication tool. A good lighthouse application:

has real users and an engaged owner;
uses a stack that many later applications share;
exercises identity, network, backup, monitoring and change management end to end;
can tolerate a planned outage;
has limited regulatory exposure.

Avoid both extremes. A trivial application proves nothing, and the crown jewels carry too much risk.

The migration factory

AWS’s large-migration playbooks give the most concrete description of a factory. It has four core workstreams: foundation, project governance, portfolio and migration. Supporting workstreams cover security and compliance, cloud operations, testing and specialized workloads. A single technical leader coordinates all of them.

AWS’s sizing figures are a useful starting point:

Pod size and throughput: a rehost pod of four to five people moves up to 50 servers a week. A replatform pod of the same size moves up to 20.
Portfolio workstream: about half the size of the migration workstream. It needs one to two weeks per wave, while migration takes three to four.
Buffer: keep portfolio work about five waves ahead so the factory never runs out of work.
Ramp-up: in AWS’s example, 1,000 servers move in six months, starting at about five a week and reaching 50 to 100.

Run one- or two-week sprints. Hold a pre-mortem before you start and a retrospective after every cutover, and revise the runbooks each time.

Runbooks

Every application needs a cutover runbook that someone other than its author could run at 2 a.m. It should cover:

owners and the escalation path;
pre-checks, including replication health, lowered DNS TTLs and verified backups;
timed steps, each with a named executor;
validation pass criteria and go/no-go points;
rollback triggers and who has authority to call a rollback;
communications at each milestone;
post-cutover tasks, such as CMDB updates and pipeline changes.

Change management, communications and freeze windows

CAF advises avoiding critical business periods such as financial close, product launches and holidays. Regulated and industrial organizations have more to add: regulatory reporting, payroll, plant shutdowns and audit fieldwork. Publish the freeze calendar alongside the wave plan so conflicts show up during planning, not on the night.

Agree early with the CAB which repeatable patterns, such as a standard rehost, can become pre-approved standard changes. AWS treats the change control process and the communication plan as planning prerequisites. The communication plan should cover:

users;
the service desk, with knowledge articles ready before cutover;
partners, who need new IP addresses and endpoints;
any regulator notifications your sector requires.

5. Migrate

Best practices by workload pattern

Pattern	Azure	AWS	What to watch
Virtual machines	Azure Migrate (agentless for VMware; replication appliance for physical and other clouds)	AWS Transform MGN, renamed from Application Migration Service in June 2026	Test-migrate into an isolated network. Remove legacy agents. Rightsize from measured use, not allocation.
Databases	Azure Database Migration Service, Managed Instance link, Log Replay Service, native backup and restore	AWS DMS with change data capture; DMS Schema Conversion for heterogeneous moves	Logins, collation, linked servers, agent jobs (SSIS job steps move manually). Validate with checksums, not row counts alone.
File shares	Azure Storage Mover (SMB and NFS, full-fidelity metadata); Azure File Sync if caching stays	AWS DataSync	ACLs, DFS namespaces, apps writing to UNC paths. Run incremental passes, then set the source read-only.
Web apps	Azure Migrate to App Service for ASP.NET; GitHub Copilot app modernization	AWS Transform for .NET	Session state, local file writes, Windows authentication, certificates, partner allow-lists.
Containers	AKS or Azure Container Apps	Amazon EKS or ECS	Registry, secrets, ingress, persistent volumes, cluster policy aligned with the landing zone.
Mainframe and legacy	Architecture Center rehost and refactor patterns with partners	AWS Transform for mainframe (IBM z/OS, Fujitsu GS21)	Run as its own program. EBCDIC data conversion, batch scheduling, phased or single cutover.

SAP has its own constraints and is covered in the SAP migration to Azure post.

Data migration: online, offline, sync and cutover

For transfer paths, CAF’s order of preference is ExpressRoute, then VPN, then Azure Data Box for large offline moves. Use the public internet only for non-sensitive data. A common pattern is offline seeding followed by online delta sync. On AWS, Snowball Edge is no longer available to new customers; AWS now points to DataSync for online transfer and to Data Transfer Terminals or partner devices for offline. Compare data volume against the bandwidth you can actually spare during business hours.

CAF’s near-zero downtime sequence:

Establish native replication, and monitor lag until it reaches zero.
Copy unstructured data while replication is stable.
Pause writes in the agreed window and complete the final sync.
Validate integrity with checksums or hashes, then test critical functions.
Redirect DNS and load balancers, and monitor closely.

Downtime migrations are simpler: stop writes, copy, validate, test, switch. Choose per application based on downtime tolerance. Near-zero downtime for an application that can afford a weekend outage only adds risk.

Testing

Functional and regression testing, plus business UAT. Check first that the test environment is complete. CAF warns that missing components produce false positives.
Integration: include external partners and the new egress IP addresses.
Performance: realistic load against the source baseline, for example with Azure Load Testing.
DR: failover, failback and a timed restore against RTO and RPO.
Security: vulnerability scans, policy compliance, and penetration tests for internet-facing workloads.
Operational acceptance and rollback rehearsal: alerts fire, runbooks work, and rollback succeeds in non-production.

Cutover and rollback plans

CAF’s rollback guidance is specific:

Agree with stakeholders in advance what counts as a failed deployment, using concrete triggers such as failed health checks, response-time thresholds or error rates.
Automate rollback where possible, and test it.
Get written approval of the plan, including who holds rollback authority.

The hardest question is the point of no return. Once users write to the target, rolling back means either reverse replication or accepted data loss, so decide which before the night. Lower DNS TTLs days in advance, and keep the source available as a fallback through stabilization.

Hypercare

CAF recommends enhanced support during stabilization: experienced staff, shorter SLAs than normal operations, and close monitoring for the first 24 to 48 hours. Microsoft’s AWS-to-Azure guidance adds a cost check after a day or two to catch runaway resources.

Define hypercare exit criteria per tier, for example:

no Severity 1 or 2 incidents for an agreed period;
alerts tuned;
runbooks, CMDB and pipelines updated;
formal acceptance by the operations team.

Without exit criteria, hypercare keeps the factory team busy with old waves when they should be on the next one.

6. Optimize and operate

Rightsizing. Flexera’s 2026 report estimates wasted IaaS and PaaS spend at 29 percent, the first increase after five years of decline. Rehosted VMs sized from allocation rather than measured use are a common source of waste. Act on Azure Advisor or AWS recommendations once you have a few weeks of cloud telemetry.

Commitments. Microsoft’s recommended order works on either cloud:

Right-size first.
Exchange underused reservations.
Trade rigid reservations for savings plans where usage varies.
Reserve only stable workloads.
Add savings plans sized to a clean baseline.

In Microsoft’s words, “Discounts reduce rates, not waste.” While waves are still landing, commit only to the baseline you’re certain of.

Modernization backlog. Every “later” from assessment belongs in a backlog the business can see, along with the findings from a Well-Architected review of each migrated workload. McKinsey’s 2023 research found that only about 10 percent of companies had fully captured cloud’s value. The backlog, not the move itself, is where most of that value comes from.

Operations and SRE handover. Handover means more than sharing a dashboard. It covers SLOs, alert ownership, on-call, access models, updated incident and DR procedures, and support contracts with the provider and ISVs.

Decommissioning source systems, and why it slips

CAF’s Azure VMware Solution guidance calls decommissioning “a governed handoff rather than a cleanup task”. Skipping it means paying for idle infrastructure and carrying security exposure. It slips for predictable reasons:

no owner;
fear of an undiscovered dependency;
unplanned data retention obligations;
contract notice periods;
savings that don’t land in anyone’s budget.

To keep it on track:

Put the decommission date in the wave plan.
Get the business owner’s approval against explicit criteria. CAF’s example is “all performance benchmarks met for 30 days”.
Archive regulated data to immutable storage, and test retrieval before switching off.
Reclaim licenses and update the CMDB.
Send contract notices early.

7. Governance, risk and compliance across the program

In regulated industries, compliance has to be designed into the factory. Bolted on as a final gate, it is what makes the last waves late.

Risk register from day one. CAF recommends one covering technical, operational and organizational risks, with owners and mitigation dates. Review it at every wave checkpoint.
Evidence as a by-product. Generate audit evidence from the pipeline itself: policy compliance reports, change records, test results, approvals and restore logs, captured per wave.
DORA has applied since 17 January 2025. Financial entities must update the register of information as services move, include the required contract terms (such as access, inspection and audit rights for critical or important functions), and keep tested exit plans for those functions. See the DORA guide.
NIS2 transposition was due by 17 October 2024. Article 23 requires an early warning within 24 hours of becoming aware of a significant incident, a notification within 72 hours, and a final report within one month. Migrated workloads therefore need detection at go-live, and incident runbooks must include the provider and your partners. See the NIS2 guide.
GDPR. Confirm region, transfers, processor terms and any DPIA before personal data moves. Don’t migrate data you have no basis to keep. See the GDPR guide.
EU Data Act. Cloud switching rules have applied since 12 September 2025, and switching charges end on 12 January 2027. Customers can give up to two months’ notice, and the switch must finish within 30 days after the notice period. This makes credible exit plans easier, which also helps with DORA. See the EU Data Act guide.
Migration-window security. Replication credentials, temporary firewall rules, hybrid tunnels and duplicate data copies all widen the attack surface. Track each as a time-boxed exception and close it when the wave ends.
Cadence. Hold a steering committee for scope and funding, and a design authority for exceptions. Integrate with the CAB and run a regular risk review. Keep forums few, with clear decision rights.

8. Roles and responsibilities (RACI)

AWS recommends exactly one responsible (R) and one accountable (A) party per detailed task; C means consulted and I means informed. “Factory” means the migration and portfolio pods. “CCoE” includes the platform and FinOps teams.

Activity	Sponsor	Program lead	CCoE / platform	App owner	Factory	Security and compliance	Ops / SRE
Business case and metrics	A	R	C	C	I	C	I
Operating model and guardrails	A	C	R	I	I	C	C
Landing zone	I	C	A/R	I	C	C	C
Discovery and assessment	I	A	C	C	R	C	C
Migration strategy (R) per application	I	C	R	A	C	C	C
Wave plan and runbooks	I	A	C	C	R	C	C
Testing and UAT sign-off	I	C	I	A	R	C	C
Go/no-go and rollback decision	I	R	C	A	C	C	C
Cutover execution	I	A	C	C	R	I	C
Hypercare and handover	I	C	C	C	R	I	A
Source decommissioning	I	A	I	C	C	C	R
Compliance evidence and notifications	I	C	C	C	C	A/R	C
Post-migration cost optimization	I	I	A	C	I	I	R

9. Checklists by phase

Before you start

Sponsor named, with decision rights and a funded dual-running budget.
Business drivers and outcome metrics agreed, including decommissioning targets.
Business case covers transition, licensing, ESUs and source exit costs.
Operating model chosen; CCoE chartered.
Skills gaps assessed; partner scope tied to outcomes.

Discover and assess

Discovery running and reconciled against the CMDB.
Dependencies collected across business cycles and validated with owners.
Application profiles complete, including regulatory scope and licensing.
Retire list approved; R decision and rationale recorded per application.
Risk register opened.

Prepare the platform

Landing zone deployed from code, with subscription or account vending.
Identity, privileged access and workload identities in place.
Hybrid network, DNS and IP plan tested end to end.
Policy enforcing regions, tags, encryption and the security baseline.
Monitoring, SIEM, backup, DR and per-application cost reporting working.

Plan waves

Dependency groups complete, including load balancers, DNS and caches.
Lighthouse applications chosen; non-production first.
Freeze calendar published; standard changes agreed with the CAB.
Runbooks peer-reviewed; communication plan issued.

Migrate

Test migration done in an isolated environment.
Functional, performance, DR, security and operational tests passed.
Rollback triggers, authority and point of no return documented and rehearsed.
Replication lag at zero; data integrity validated; go/no-go recorded.
Hypercare staffed, with exit criteria.

Optimize and operate

Rightsized on cloud telemetry before buying commitments.
Well-Architected review done; modernization backlog prioritized.
Operations handover signed; CMDB and documentation updated.
Source decommissioned with evidence; licenses reclaimed; exceptions closed.

10. Common anti-patterns

Migrating the CMDB instead of the estate. Planning from records nobody has checked against discovery.
Waves by server count. Splitting dependency groups to hit a velocity target.
Rehosting problem workloads. Moving existing performance problems to a platform where they cost more.
Modernizing everything on the critical path. Turning a fixed exit date into an open-ended rewrite.
The one-off landing zone. Built for wave one, so every later wave runs on exceptions.
The one-sentence rollback plan. No triggers, no rehearsal, no agreed point of no return.
Endless split-environment operation. Chatty components left on opposite sides of a WAN link for months.
Buying commitments before rightsizing. Locking in a discount on capacity you don’t need.
Decommissioning as cleanup. Dual running becomes permanent, and the business case quietly fails.
Compliance as the final gate. Discovering DORA, NIS2 or GDPR obligations after the architecture is fixed.
Time-and-materials partners with no outcome targets. McKinsey names this as a driver of overruns.

Where to start

Write a one-page charter: drivers, outcome metrics, sponsor, scope and the decommissioning target.
Start discovery and dependency collection now, so they run through at least one full business cycle.
Run TIME rationalization with business owners, and approve a retire list before anyone sizes a VM.
Deploy the landing zone from code, with policy, identity, network, observability and tagging in place.
Pick two or three lighthouse applications and use them to calibrate the factory.

Then go deeper with the rest of the series: VMware to public cloud, datacenter migration to Azure, application migration lessons learned and SAP migration to Azure.

Sources

Last reviewed: October 2026.

One response to “The Cloud Migration Handbook: Best Practices for Moving Applications to the Cloud”

Azure Cloud Adoption Framework and Landing Zones Guide

October 22, 2026

[…] lists eight: retire, retain, rehost, replatform, refactor, rearchitect, rebuild and replace. Our Cloud Migration Handbook goes […]

Loading…

The Cloud Migration Handbook: Best Practices for Moving Applications to the Cloud