Most cloud migration plans look sound on paper. Then the first production wave meets reality: an undocumented batch job, a hard-coded IP address, a license clause nobody read, a cutover window that is three hours too short.

This post collects the lessons that come up again and again in application migrations to Azure and AWS. They are documented in Microsoft’s Cloud Adoption Framework (CAF), AWS Prescriptive Guidance, regulator findings and public post-mortems. Each lesson covers what tends to go wrong, why, and what to do instead. It is written for CIOs, cloud architects and migration leads, particularly in regulated EU organizations. For the end-to-end method, see the Cloud Migration Handbook.

Key takeaways

• Treat the CMDB and discovery tools as a starting point. Validate dependencies with owners and with traffic data that covers a full business cycle.
• Check end-of-support dates and license terms before wave planning. Several important dates passed in 2026, and Windows Server 2016 follows in January 2027.
• Identity, DNS and network paths decide whether a cutover works. Prove them with a representative workload before wave 1.
• In regulated industries, security guardrails and regulatory notifications run on their own timelines. Start them during discovery.
• Lift-and-shift without rightsizing, and without a firm decommission date, usually costs more, not less.
• Measure outcomes such as performance against baseline, cost per workload and source capacity retired. VM counts don’t tell you much.

Discovery and planning

1. The CMDB is a starting point, not the truth

What goes wrong: The wave plan is built from the CMDB and an automated scan. Then cutover weekend turns up dependencies nobody listed: a hard-coded IP address, a partner’s SFTP allow-list, a nightly export to a file share, an on-premises SMTP relay, a hardware license dongle, or a time source that isn’t moving.

Why: A CMDB records what was approved, not what actually runs. Microsoft’s assessment guidance says automated tools “might miss undocumented dependencies” and recommends interviews with workload owners. Azure Migrate’s agentless dependency analysis polls active TCP connections every five minutes, so a month-end job or a short-lived connection can be missing from the map. Some dependencies also behave differently in the cloud: Azure blocks outbound SMTP on TCP port 25 from VMs on most subscription types (Enterprise Agreement and MCA-E are the exceptions) and recommends an authenticated relay on port 587.

What to do instead:

• Run dependency analysis across a full business cycle, including month-end. Microsoft’s 24-hour minimum is only enough to get started.
• Check tool data against owner interviews, firewall logs, scheduler definitions and DNS query logs.
• Keep a “forgotten dependencies” checklist: SMTP relays, file shares, printing, time sources, license dongles, certificates and partner allow-lists.
• Replace hard-coded IP addresses with DNS names before migration, as CAF’s compatibility guidance recommends.

2. End-of-support software surfaces mid-wave

What goes wrong: A wave is ready to replicate when someone notices the database runs SQL Server 2016 or the app tier is Windows Server 2012 R2. Now the workload needs an upgrade, an ISV recertification or a paid Extended Security Update (ESU) bridge, and the wave stalls.

Why: Discovery reports list versions, but nobody checks them against support dates and the migration calendar. 2026 has been a heavy year for this:

Product	Status as of October 2026	What it means for migration
Windows Server 2012 / 2012 R2	ESUs ended October 13, 2026, including in Azure	No more security updates anywhere. Upgrade or retire.
SQL Server 2016	Extended support ended July 14, 2026	ESUs on Azure VMs now require a paid subscription. They are no longer free.
Windows Server 2016	Extended support ends January 12, 2027	Azure Arc ESUs could be configured from August 3, 2026, with billing from January 13, 2027. You must attest Software Assurance or SPLA coverage.
RHEL 7	Maintenance ended June 30, 2024	Extended Life Cycle Support is available until May 31, 2029.

Microsoft has also standardized pricing for ESU offerings released on or after April 1, 2026: the same list price in Azure, on-premises or another cloud. “Move to Azure and get free ESUs” was true for Windows Server 2012. Don’t carry it into a 2016-era business case without checking.

What to do instead:

• Join discovery output to vendor lifecycle data (Microsoft Lifecycle, Red Hat, your ISVs). Flag anything that is out of support, or will be before its wave finishes.
• For each workload, decide whether to upgrade before migration, upgrade during it, or bridge with ESUs, and cost each option.
• Treat ESUs as a bridge with a fixed end date, not as the plan.

3. Licensing and ISV support statements are architecture constraints

What goes wrong: The target architecture is finished before anyone reviews licensing, which then turns out non-compliant or far more expensive than modeled. Or the ISV says the product is “not supported in public cloud”, and the business owner won’t accept that.

Why: License terms differ by provider and change often:

• Microsoft: Since October 1, 2019, licenses without Software Assurance or mobility rights can’t be used on dedicated hosted cloud services from the “Listed Providers” (Microsoft, Alibaba, Amazon and Google). Azure Hybrid Benefit requires active Software Assurance or qualifying subscriptions, with a minimum of eight core licenses per Windows Server VM.
• Oracle: Oracle’s cloud policy counts two vCPUs as one processor license when multithreading is enabled and caps Standard Edition 2 at eight vCPUs. Oracle doesn’t certify its products on non-Oracle public clouds and doesn’t support RAC there; on Azure, RAC means Oracle Database@Azure.
• VMware: Broadcom stopped selling perpetual licenses and support renewals in December 2023, which changed the economics of every exit option (see VMware migration to public cloud).
• ISVs: Support is explicit, not implied. SAP lists supported products and Azure VM types in SAP Note 1928533 (see SAP migration to Azure).

What to do instead:

• Review licensing for each workload during assessment, with procurement involved, and get each ISV’s written support statement for the target platform, VM family and OS version.
• Model license-included, bring-your-own-license and Hybrid Benefit costs explicitly rather than relying on an assessment tool’s defaults.
• Line up Software Assurance renewals with the migration timeline. Hybrid Benefit workloads may run only during the Software Assurance or subscription term.

4. Chatty applications don’t survive being split across waves

What goes wrong: The app servers move in wave 2 and their database in wave 4. Response times that were fine on the LAN collapse when every page load makes hundreds of round trips over VPN or ExpressRoute.

Why: Waves are often built around infrastructure convenience (a cluster, a subnet, a team) rather than how the components communicate. CAF says direct dependencies “require immediate communication and low latency” and should move together, and that components should be grouped when criticality is uncertain. Azure Migrate’s automatic wave planning (in preview) applies the same rule to strong two-way dependencies.

What to do instead:

• Group by dependency, not by infrastructure, and treat shared databases as wave anchors.
• Measure round trips per transaction for critical user journeys before you split anything.
• If a split can’t be avoided, test it in non-production over the real network path and give it an end date.

Technical

5. Identity and DNS are always on the critical path

What goes wrong: The VMs boot in Azure, but users can’t sign in, service accounts fail Kerberos, and half the clients still resolve the old IP address. From on-premises, private endpoints resolve to public addresses. The rollback starts at 3 a.m.

Why: Every workload depends on identity and name resolution, and teams outside the migration usually own them. Microsoft’s landing zone guidance names DNS forwarding and private DNS zone ownership as decisions that “often surface late”, and says to prove any legacy Active Directory dependency (LDAP, Kerberos, Group Policy) before migration. Time matters too: Kerberos and certificate-based authentication fail when clocks drift.

What to do instead:

• Before wave 1, build hybrid DNS (forwarders or Azure DNS Private Resolver, plus private DNS zones) and test it from a representative spoke.
• Decide early whether domain controllers must be in Azure before cutover, and design the time sync hierarchy deliberately.
• Lower DNS TTLs 24 to 48 hours before cutover. Microsoft notes this helps but doesn’t guarantee every client switches immediately, so plan rollback accordingly.
• Inventory service accounts and hard-coded credentials, and move to managed identities where supported.

6. “Temporary” hybrid states become permanent

What goes wrong: A Layer 2 network extension, a VPN path back to an on-premises database, or internet traffic forced back through the old datacenter is set up “for the migration”. Two years later it still carries production traffic, has no owner, and ties the workload to the site it was supposed to leave.

Why: Interim states take away the pressure to finish. Microsoft’s Azure VMware Solution guidance is blunt about it: “Some teams treat network extension as a permanent design. It’s not.” An extended network usually keeps its gateway on-premises, so the workload still depends on the source site. Microsoft’s landing zone guidance calls forced tunneling “generally an antipattern” for migrated workloads.

What to do instead:

• Give every interim construct an owner, an exit criterion and a date, and track it in the risk register.
• For components that have to stay behind, prefer integration patterns (API gateways, queues, data sync) over stretched networks, as CAF recommends.
• Report open interim states to the steering committee alongside wave progress.

Data

7. Data takes longer to move than the cutover window allows

What goes wrong: The replication estimate assumed the whole link. In practice the link is shared with production, the final delta sync takes longer than planned, and nobody budgeted validation (row counts, checksums, smoke tests) inside the window.

Why: Bandwidth arithmetic is optimistic. Google Cloud’s guidance puts 100 TB over a 1 Gbps link at about 12 days in ideal conditions, and more than 100 days over 100 Mbps. Near-zero-downtime methods help, but CAF notes they need bandwidth that keeps up with the rate of change.

What to do instead:

• Measure real throughput and change rates early. Seed large datasets offline (for example with Azure Data Box) and sync the deltas online.
• Choose downtime or near-zero-downtime migration per workload, based on documented business tolerance.
• Write the cutover as a runbook with owners, timings and a RACI, as AWS Prescriptive Guidance recommends, and rehearse it with production-sized data until timings are stable.
• Agree measurable rollback triggers and the point of no return before the window opens, and test the rollback itself, as CAF recommends.

Security and compliance

8. Security guardrails that arrive late block deployments

What goes wrong: The migration team tests in a permissive subscription. Days before go-live, production landing zone policies deny public IPs, require private endpoints or enforce tagging, and the deployment fails. Or DeployIfNotExists policies modify resources after deployment, and the infrastructure-as-code templates drift from reality.

Why: Guardrails are often finished in parallel with the migration instead of before it. Late security costs more than time: in August 2020 the US Office of the Comptroller of the Currency fined Capital One $80 million, citing its failure “to establish effective risk assessment processes prior to migrating significant information technology operations” to the public cloud.

What to do instead:

• Make security a named owner from discovery onward, with an agreed control baseline for each data classification.
• Test in landing zones with production’s policy assignments, and build platform-initiated policy changes into workload IaC templates, as Microsoft advises.
• Assign new policies in audit (DoNotEnforce) mode first, fix findings per wave, then enforce. Give exceptions expiry dates.

9. Regulated sign-offs run on their own clock

What goes wrong: The technical plan is ready, but the regulator hasn’t been informed, the third-party risk assessment isn’t finished, the DPO hasn’t approved the region, or the required exit plan doesn’t exist. Go-live waits weeks.

Why: In regulated sectors, migration decisions are compliance decisions:

• DORA (applicable since January 17, 2025) requires a register of ICT third-party arrangements, pre-contract risk assessment, informing the competent authority “in a timely manner” about planned arrangements supporting critical or important functions, and tested exit strategies. See the DORA guide.
• NIS2 lists supply chain security and business continuity among required risk-management measures. See the NIS2 guide.
• GDPR and data residency drive region choice; CAF recommends allowed-location policies in the baseline from the start. See the GDPR guide.
• The EU Data Act switching rules have applied since September 12, 2025, and switching charges are prohibited from January 12, 2027, which helps with exit plans. See the EU Data Act guide.

What to do instead:

• Map each workload to its regulatory obligations during assessment, and put notification and approval lead times into the wave plan.
• Build the evidence pack (risk assessment, register entry, exit plan, and a DPIA where needed) alongside the technical design.
• Identify early which workloads support critical or important functions. They set the pace of the program.

People and operating model

10. Somebody has to own the application after hypercare

What goes wrong: The migration team moves on to the next wave. The application runs on services the operations team has never managed, the runbooks still refer to the old datacenter and alerts go to nobody. The first incident becomes an argument between the platform team, the managed service provider and the application owner.

Why: Programs are funded to move workloads, not to change how they are run. AWS’s large-migration guidance calls runbooks set up before migration “critical” and recommends a defined handoff to cloud operations after hypercare. Its cutover guidance adds that a typical one-day to one-week warranty “might not be sufficient if your application runs on a quarterly batch schedule.”

What to do instead:

• Agree a RACI per workload (platform, application team, managed service provider, security) before its wave starts.
• Size hypercare to the business cycle, with explicit exit criteria: runbooks updated, alerts tested, a backup restored, on-call trained.
• Close skills gaps early through training or partners. Microsoft’s Azure Accelerate program, launched in July 2025, combines Azure Migrate and Modernize, Azure Innovate and expert-led deployment help. Check current eligibility.

11. Change fatigue is a delivery risk

What goes wrong: Business users get a steady stream of freeze windows, UAT requests and “minor” changes to URLs, sign-in flows and printers. By wave five, testing attendance drops, cutovers get pushed back, and defects reach production.

Why: Communication tends to be planned last. McKinsey’s 2021 research on cloud migration found that change management was the most-cited cause of cost overruns, and that 38% of companies had seen migrations delayed by more than a quarter.

What to do instead:

• Schedule waves around the business calendar (financial close, peak seasons, product launches), as CAF recommends, and have business owners confirm the sequence.
• Batch changes that users will notice, and explain them in business terms: what changes, when it changes, and what users have to do.
• Give each business unit a named contact and a simple status view of its applications, including when each one enters and leaves hypercare.

Cost

12. Lift-and-shift without rightsizing raises the bill

What goes wrong: VMs are sized “as is”, reservations wait until month six, and dev/test runs around the clock. The first quarterly bill exceeds the business case.

Why: On-premises servers are often over-provisioned because the capacity was already paid for. Azure Migrate’s performance-based sizing uses a percentile of collected utilization plus a comfort factor, and Microsoft recommends waiting for the full performance period before relying on it. Waste is common: Flexera’s 2026 State of the Cloud report puts self-estimated wasted cloud spend at 29%, and 85% of respondents name managing cloud spend as a top challenge.

What to do instead:

• Use performance-based sizing with at least a month of data, and review outliers with workload owners instead of accepting the defaults.
• Set budgets and alerts on each subscription, with a named owner, before the first workload lands, as CAF recommends.
• Make license benefits, reservations or savings plans, dev/test schedules and cost-allocation tags part of each wave. Don’t save them for a later optimization project.

13. The datacenter exit date slips unless someone owns it

What goes wrong: The workloads move, but the source keeps running: “just in case” VMs, a cluster with three tenants left, an array of data nobody will classify. The organization pays twice, and the business case savings never appear.

Why: Once users are served from the cloud, decommissioning has no natural owner or deadline. Microsoft warns that if you skip it, “you pay for idle infrastructure and carry security exposure.” McKinsey found the average company spends 14% more on migration than planned each year, so there is rarely budget for running two environments.

What to do instead:

• Include decommissioning in each wave’s scope, with a date, a stakeholder approval and a decision on how long to keep backups, following CAF’s decommissioning guidance.
• Make source capacity retired (servers, racks, licenses, contracts) a headline program metric.
• Work backward from lease, support and license renewal dates (see datacenter migration to Azure).

Cutover and after

14. Without a baseline and a DR test, nobody can prove it worked

What goes wrong: After cutover, users say the system “feels slower”, but there are no pre-migration figures to compare against. Meanwhile the on-premises DR setup is retired with the source, and the cloud workload goes live with backups on but no recovery ever tested.

Why: Baselines get skipped because the source “works”, and DR gets assumed rather than designed. TSB’s 2018 platform migration wasn’t a public cloud move, but it is one of Europe’s most-cited migration post-mortems. The independent Slaughter and May review questioned how testing was carried out, including a decision to test only one of two data centers, which turned out to be configured inconsistently. In December 2022 the FCA and PRA fined TSB £48.65 million for failing to plan the migration properly and to manage outsourcing risk. On DR: in May 2024 a provisioning misconfiguration deleted pension fund UniSuper’s private cloud subscription on Google Cloud, including its copies in two regions. Backups held with a separate provider made recovery possible. NIS2 Article 21 explicitly requires business continuity, “such as backup management and disaster recovery”.

What to do instead:

• Capture baselines on the source for critical transactions, batch jobs and peak periods. Fix known performance problems first so the comparison means something.
• Load-test the target with realistic traffic and compare the results to the baseline, as CAF recommends. Test every environment that will carry production, not only one.
• Work out RPO and RTO again for each workload, and keep at least one backup copy outside the production subscription’s administrative blast radius.
• Run a DR failover test during or right after hypercare, before the source is decommissioned.

15. Measure success beyond “VMs moved”

What goes wrong: The dashboard reports servers migrated per week, and the program hits its numbers. Yet costs are up, the datacenter is still open and users are unhappy. Leadership concludes the migration failed.

Why: VM counts are easy to measure and say nothing about the outcomes that justified the program. CAF recommends success metrics tied to each strategy’s business driver; for a rehost, its examples include Tier 1 workloads moved with no SLA degradation and a stated share of on-premises infrastructure decommissioned. AWS suggests a migration scorecard across applications and business units.

What to do instead:

• Agree a short scorecard for each wave: performance against baseline, incidents in the first 30 days, cost against the business case, source capacity retired and interim states closed.
• Report those outcomes to the steering committee, not just throughput.
• End each wave with a short lessons-learned review and feed it into the next wave’s plan. CAF’s iterative wave planning assumes you do exactly this.

One-page summary checklist

Area	Check before moving on
Discovery and planning	Dependencies validated over a full business cycle. Versions mapped to support dates. License position and ISV support confirmed. Coupled components in the same wave.
Technical	Hybrid DNS, identity and time sync proven. TTLs lowered before cutover. Every interim construct has an owner and an end date.
Data	Real throughput and change rate measured. Cutover rehearsed with production-sized data. Rollback triggers agreed.
Security and compliance	Tested under production policies. Security involved from discovery. Regulatory steps built into the timeline.
People and operating model	RACI, runbooks and alert routing agreed. Hypercare sized to the business cycle. Waves fit the business calendar.
Cost	Performance-based sizing. Budgets, tags and license benefits applied per wave. Decommissioning dated and approved.
Cutover and after	Baseline captured. DR re-tested before source retirement. Outcome scorecard and lessons-learned review after every wave.

Where to start

Pick the three lessons that match your biggest risks and act on them during discovery. For most regulated organizations, those are dependency validation, an end-of-support and licensing review, and starting the security and regulatory workstreams on day one. For the full method, see the Cloud Migration Handbook; for infrastructure-heavy estates, datacenter migration to Azure and VMware migration to public cloud.

Every migration teaches something new. What has your organization learned the hard way? Share your lessons in the comments, especially the ones that never made it into the official post-mortem.

Sources

• Microsoft Learn: Plan your migration (Cloud Adoption Framework)
• Microsoft Learn: Migration wave planning
• Microsoft Learn: Assess your workloads for cloud migration
• Microsoft Learn: Prepare workloads for the cloud
• Microsoft Learn: Select your cloud migration strategies
• Microsoft Learn: Decommission source workloads after migration to cloud
• Microsoft Learn: Migrate workloads to Azure VMware Solution (CAF)
• Microsoft Learn: Azure landing zones for on-premises experts
• Microsoft Learn: Adopt policy-driven guardrails
• Microsoft Learn: Azure Virtual Machines baseline architecture in an Azure landing zone
• Microsoft Learn: Azure Migrate dependency analysis
• Microsoft Learn: Analyze server dependencies (agentless)
• Microsoft Learn: Automatic wave planning in Azure Migrate (preview)
• Microsoft Learn: Assessment overview (migrate to Azure VMs)
• Microsoft Learn: Best practices for creating assessments
• Microsoft Learn: Troubleshoot outbound SMTP connectivity problems in Azure
• Microsoft Learn: Time sync for Linux VMs in Azure
• Microsoft Learn: Zero-downtime migration to Azure Kubernetes Service (DNS TTL guidance)
• Microsoft Learn: Extended Security Updates for Windows Server overview
• Microsoft Learn: Cloud-native licensing and cost management with Azure Arc-enabled servers
• Microsoft Learn: Deliver Extended Security Updates for Windows Server (Azure Arc)
• Microsoft Lifecycle: Windows Server 2016
• Microsoft Learn: Extended Security Updates for SQL Server FAQ
• Microsoft Learn: Extended Security Updates for SQL Server on Azure Virtual Machines
• Microsoft Licensing: Services pricing consistency update (ESU pricing from April 1, 2026)
• Microsoft Licensing: Updated licensing rights for dedicated hosted cloud services
• Microsoft Learn: Azure Hybrid Benefit for Windows VMs
• Red Hat: RHEL 7 end of maintenance and Extended Life Cycle Support
• Oracle: Licensing Oracle Software in the Cloud Computing Environment
• VMware Cloud Foundation blog: Oracle Database support on non-Oracle public clouds (quoting Oracle Doc ID 2688277.1)
• Microsoft Learn: Migrate Oracle workloads to Azure VMs
• Microsoft Learn: FAQ for Oracle Database@Azure
• Redmond Channel Partner: Broadcom kills VMware perpetual licenses (December 2023)
• Microsoft Learn: SAP certifications and configurations on Microsoft Azure
• Google Cloud: Migrate to Google Cloud, transfer your large datasets
• AWS Prescriptive Guidance: Best practices for migration cutover, pre-cutover stage
• AWS Prescriptive Guidance: Best practices for migration cutover, post-cutover stage
• AWS Prescriptive Guidance: Preparing the organization for a large migration
• OCC: OCC assesses $80 million civil money penalty against Capital One (August 2020)
• FCA: TSB fined £48.65m for operational resilience failings (December 2022)
• TSB: Response to the Slaughter and May independent review (November 2019)
• FStech: TSB publishes damning IT migration review
• UniSuper: Joint statement from UniSuper and Google Cloud (May 2024)
• EUR-Lex: Regulation (EU) 2022/2554 (DORA) and DORA Article 28 text
• FMA Austria: DORA, digital operational resilience in the financial sector
• NIS2 Directive, Article 21: Cybersecurity risk-management measures
• Latham & Watkins: EU Data Act switching requirements for data processing services
• McKinsey: Cloud migration opportunity, business value grows but missteps abound (2021)
• Flexera: 2026 State of the Cloud report press release
• Microsoft Azure Blog: Introducing Azure Accelerate (July 2025)

Last reviewed: October 2026.