Common cloud migration mistakes

Why cloud migrations fail even when the technology works

The most expensive common cloud migration mistakes rarely start with a failed virtual machine deployment. They start with incomplete dependency maps, unrealistic cost models, unclear ownership, and migration plans that treat data movement as the finish line. An application can run successfully in the cloud while becoming harder to operate, more expensive to maintain, or less resilient than before.

For decision-makers, the challenge is defining measurable outcomes and refusing premature commitments. For practitioners, it is proving that applications, data, networking, identity, and operations work together under production conditions.

A sound migration plan should answer four questions: Why move this workload? What must remain true during the move? How will success be measured? Who owns it afterward? The mistakes below show what happens when those answers remain vague.

1. Choosing a migration strategy before understanding the workload

“Move everything to the cloud” is a direction, not a workload strategy. Rehosting, replatforming, refactoring, replacing, retaining, and retiring applications have different economics and risks.

Match the approach to a specific outcome

Rehosting can be the right choice for a data-center exit. It becomes a mistake when leaders assume it automatically produces cloud-native efficiency.

Prevention: Give each workload an explicit rationale, owner, target outcome, and acceptance threshold. For example, “reduce database patching work without worsening transaction latency” is testable; “modernize the database” is not.

2. Building the migration plan from an incomplete inventory

A server inventory does not reveal an application’s full operating environment. Hidden dependencies often include identity providers, license servers, scheduled jobs, shared folders, outbound IP allowlists, and hard-coded hostnames.

A migrated application may pass a daytime smoke test but fail during overnight settlement because its batch job still writes to an on-premises share.

Discover dependencies before selecting migration waves

Combine several sources:

• Infrastructure discovery: Use tools such as Azure Migrate, AWS Application Discovery Service, or existing configuration-management inventories.
• Runtime evidence: Review network flows, DNS queries, application traces, and database connections.
• Human knowledge: Interview application owners and support teams about infrequent jobs and manual procedures.
• Business calendars: Include month-end processing, reporting deadlines, and seasonal peaks.

Discovery tools are useful, but observation windows matter. A short scan cannot prove the absence of a quarterly dependency.

Prevention: Require a dependency map showing direction, protocol, authentication, latency sensitivity, and ownership. Group tightly coupled components into migration waves rather than separating them solely by infrastructure type.

3. Comparing cloud prices with an incomplete on-premises baseline

A virtual machine price is not the cost of running an application. Cloud bills can include storage operations, snapshots, managed database capacity, load balancers, NAT processing, inter-region traffic, logging, support, and commercial licenses.

The comparison also becomes misleading when the on-premises baseline excludes staff effort, facility costs, backup infrastructure, or hardware renewal.

Model the complete operating pattern

Use AWS Pricing Calculator, Azure Pricing Calculator, or Google Cloud Pricing Calculator with observed workload measurements—not provisioned capacity alone.

Include:

• Normal demand, peaks, and nonproduction environments.
• Data transfer paths, including internet egress and hybrid connectivity.
• Backup retention, recovery environments, and monitoring volume.
• Temporary parallel operation during migration.
• Licensing rules and eligible portability benefits.
• Staff responsibilities before and after migration.

The FinOps Framework provides a useful structure for allocation, forecasting, and shared financial accountability.

Prevention: Compare equivalent service levels and model several demand scenarios. Track cost per business unit, such as transaction or customer, alongside total spend. Delay long-term consumption commitments until workloads stabilize; discounts on the wrong resource shape can preserve waste.

4. Moving workloads before establishing a landing zone

Without shared foundations, early migration teams create inconsistent accounts, permissions, networks, and logging. Those choices become difficult to reverse once production depends on them.

A landing zone should establish the minimum safe environment before application teams begin deploying.

Define mandatory controls without blocking delivery

At minimum, establish:

• Account or subscription separation for production and nonproduction.
• Federated identity, multifactor authentication, and emergency access.
• Central audit logging with appropriate retention and access controls.
• Network address allocation, DNS, routing, and private connectivity.
• Encryption, key ownership, and secrets management.
• Resource ownership metadata, budgets, and policy enforcement.

AWS Control Tower, Azure landing zones, and Google Cloud organization policies support these foundations. Terraform, OpenTofu, Bicep, or CloudFormation can make deployment repeatable.

Trade-off: Excessively rigid controls can drive teams toward workarounds. Provide approved patterns and a documented exception process with an owner and expiry date.

5. Treating cloud security as a provider responsibility

Cloud providers secure underlying infrastructure, but customer responsibilities remain substantial. The exact boundary varies between virtual machines, managed databases, containers, and software-as-a-service.

Managed services do not remove responsibility for identities, sensitive data, authorization, or application behavior. The AWS shared responsibility model illustrates how these responsibilities differ by service.

Verify controls against realistic failure paths

Common gaps include broad administrative roles, credentials stored in deployment scripts, publicly reachable databases, and audit logs that nobody reviews.

Before production migration:

• Map human and workload identities to least-privilege roles.
• Prefer short-lived credentials over embedded access keys.
• Test network access from approved and unapproved locations.
• Confirm where primary data, backups, replicas, and logs reside.
• Validate key recovery and emergency-access procedures.
• Assign responsibility for patching every remaining customer-managed layer.

Prevention: Turn security requirements into automated policy checks and deployment gates. Provider certifications alone do not establish that your application configuration satisfies regulatory or contractual obligations.

6. Underestimating data gravity and transfer complexity

Moving application code is often easier than moving its data. Large datasets, sustained write activity, and latency-sensitive connections can make apparently simple migrations difficult.

Copy duration depends on effective throughput, not advertised circuit speed. Encryption overhead, source disk performance, competing traffic, and small-file behavior can all become bottlenecks.

Plan for convergence, not just the initial copy

Tools such as AWS Database Migration Service, Azure Database Migration Service, and Google Cloud Database Migration Service can assist with supported migration paths. They do not guarantee semantic compatibility or eliminate validation.

Define:

• The authoritative source during every migration phase.
• Initial-load method and expected completion window.
• Change replication approach and acceptable lag.
• Schema, collation, time-zone, and extension compatibility.
• Record-count, checksum, or business-level reconciliation methods.
• Treatment of deletes, retries, duplicates, and failed transactions.

Trade-off: Online replication can reduce downtime but adds operational complexity. An offline move may be safer when the business can tolerate a maintenance window.

Avoid placing chatty application components across a hybrid boundary without measurement. Repeated database round trips can turn modest network latency into unacceptable response times.

7. Redesigning everything during the migration

A cloud migration becomes much harder when it also introduces microservices, Kubernetes, a new database engine, and a rewritten deployment platform.

Each change may be reasonable individually. Together, they expand the failure surface and make troubleshooting ambiguous.

Separate required changes from optional modernization

Classify proposed changes as:

• Required for compatibility: Necessary for the workload to run.
• Required for acceptance: Necessary to meet security, reliability, or cost objectives.
• Optional improvement: Valuable but not needed for the migration’s success.

Kubernetes is appropriate when its orchestration capabilities justify its operational burden. It is not a default destination for every application. Managed application platforms or conventional virtual machines may fit the team better.

Prevention: Modernize selectively and preserve a working baseline. Make architectural changes before migration when they are prerequisites; otherwise, sequence them afterward when practical.

8. Testing whether it runs instead of whether it is production-ready

A successful login test does not establish production readiness. Cloud environments differ in storage behavior, network limits, service quotas, identity integration, and failure modes.

Use a review structure such as the Azure Well-Architected Framework to cover reliability, security, performance, cost, and operational concerns.

Set acceptance criteria before testing

Useful criteria include:

• Performance: Critical journeys meet agreed percentile-latency targets under representative load.
• Capacity: Quotas and resource limits accommodate expected peaks.
• Recovery: Restore tests demonstrate the required recovery time and recovery point objectives.
• Correctness: Reconciliation checks confirm business transactions and migrated records.
• Operations: Alerts reach the right responder and include usable diagnostic context.
• Security: Unauthorized access attempts are rejected and recorded.

Use k6, JMeter, or Locust for load testing, and OpenTelemetry-compatible instrumentation for traces and metrics.

Prevention: Test representative data volumes and transaction patterns. Small test databases often hide indexing, query-plan, and restore-time problems that appear only at production scale.

9. Planning a cutover without a credible rollback

“Change DNS back” is not a complete rollback plan. Once users write data to the new environment, returning to the old one can lose or duplicate transactions.

Rollback also depends on replication direction, schema compatibility, cached DNS responses, and whether both environments can accept writes.

Design the decision before the maintenance window

The cutover runbook should specify:

• Named decision-maker and communication channels.
• Entry checks, including replication status and verified backups.
• Write-freeze or traffic-draining steps where required.
• Ordered execution steps with verification points.
• Measurable abort conditions and a decision deadline.
• Data reconciliation procedures if rollback follows new writes.

Trade-off: Some migrations become safer to roll forward than back after a particular point. State that boundary explicitly and rehearse the recovery path.

Do not let schedule pressure replace an evidence-based go/no-go decision.

10. Forgetting the people and systems left behind

Migrations often receive project funding without a durable operating model. The result is infrastructure that nobody confidently owns, escalating support tickets, and duplicate environments that remain billable.

A cloud architect alone cannot replace expertise in application behavior, database operations, networking, security, and business processes.

Make ownership and retirement part of completion

Before handover, confirm:

• A named service owner, on-call coverage, and escalation path.
• Runbooks tested by people who did not write them.
• Ownership of infrastructure code, pipelines, certificates, and secrets.
• Training for routine operations and incident response.
• A decommissioning checklist for old infrastructure and contracts.
• Required retention or secure deletion of legacy data.

Prevention: Keep source systems only for a justified stabilization or retention period. Remove obsolete routes, credentials, monitoring, licenses, and backups according to policy—not merely the old virtual machines.

A step-by-step cloud migration process that reduces risk

Use migration waves with explicit exit criteria rather than one large deadline.

1. Define business outcomes. Establish measurable goals, downtime tolerance, compliance constraints, and financial boundaries.
2. Discover workloads and dependencies. Combine inventories, runtime evidence, and owner interviews. Identify candidates to retire or retain.
3. Choose workload strategies. Document why each application will be rehosted, replatformed, refactored, or replaced.
4. Build the foundations. Establish landing-zone controls, connectivity, identity, logging, ownership, and cost allocation.
5. Pilot a representative workload. Select something manageable that exercises meaningful dependencies—not simply the easiest application.
6. Rehearse migration and recovery. Measure transfer behavior, validate data, test performance, and execute rollback or roll-forward procedures.
7. Cut over using evidence. Confirm acceptance criteria, assign decision authority, and record deviations.
8. Stabilize, optimize, and retire. Resolve operational gaps, rightsize from observed demand, and decommission obsolete infrastructure.

Maintain a risk register with an owner, mitigation, trigger, and decision date for each material risk. For related delivery and implementation guidance, browse more Mistakes to avoid topics.

Frequently asked questions

What is the biggest mistake in a cloud migration?

Treating migration as an infrastructure copy rather than a change to an operating system of people, processes, and technology. Moving workloads without explicit success criteria leaves cost, reliability, security, and ownership problems unresolved.

Is lift-and-shift always a bad cloud migration strategy?

No. Rehosting can reduce change risk and support urgent data-center exits. It becomes problematic when its limitations are ignored. Budget for stabilization and rightsizing, and identify which workloads need later modernization to achieve the intended benefits.

How can teams prevent unexpected cloud migration costs?

Measure current usage, model the complete architecture, and include transfer charges, monitoring, backups, licenses, support, and parallel running. Establish allocation tags, budgets, and anomaly alerts early. Budget alerts generally notify; they should not be assumed to impose a hard spending cap.

When should an organization postpone a cloud migration?

Postpone a workload when critical dependencies remain unknown, recovery cannot be demonstrated, regulatory requirements are unresolved, or no team can operate the target environment. A controlled delay with clear remediation criteria is safer than transferring unresolved risk into production.