Cloud adoption continues to accelerate across every industry. The chief benefits reported by organisations that have successfully migrated include increased operational efficiency, simplified administration, easier access to resources, and reduced infrastructure costs. But before those benefits materialise, businesses must navigate a migration process that is often more complex than initially anticipated — spanning technical architecture, organisational change, security posture, and cost modelling.
The following 13 challenges represent the most common obstacles engineering and IT leaders encounter during cloud migrations. The insights below are drawn from practitioner perspectives originally published via Forbes Technology Council.
1. Getting the Architecture Right the First Time
Infrastructure-as-a-Service (IaaS) platforms such as AWS, Azure, and Google Cloud give you enormous flexibility — but that flexibility is a double-edged sword. There are dozens of ways to assemble cloud infrastructure, and many of them will work just well enough to hide problems until they become expensive. If your team lacks deep cloud architecture experience, consider starting with a Platform-as-a-Service (PaaS) offering such as Heroku or Google App Engine. PaaS platforms are opinionated by design, reducing the number of wrong turns available to you. Save IaaS for workloads where you genuinely need that level of control.
2. People and Processes, Not Just Technology
The most commonly underestimated cloud migration challenge is not technical — it is organisational. Moving to the cloud changes how teams provision resources, how incidents are handled, how costs are allocated, and how development workflows are structured. Without deliberate investment in retraining, new runbooks, and updated operational processes, organisations find that they have simply replicated their on-premises problems in a new environment. Cloud-native operations require genuinely different habits, and changing habits takes time. Larger enterprises with deeply embedded processes will face a longer transition than younger, leaner organisations.
3. Defining a Clear Strategy and Business Objectives
Cloud migration is not a goal in itself — it is a means to an end. Before any migration work begins, document the specific business objectives the migration is intended to serve: faster time to market, reduced capital expenditure, improved disaster recovery, greater geographic reach, or something else entirely. These objectives determine which workloads migrate first, which cloud model (public, private, hybrid, or multi-cloud) is appropriate, and how success will be measured. Migrations that begin without this clarity frequently stall mid-way as teams argue over priorities that should have been resolved before a single VM was moved.
4. Overcoming Psychological Barriers
Concerns about security, uptime, and support quality are legitimate, but they should be evaluated on evidence rather than assumption. Mainstream cloud providers invest significantly in physical security, redundant infrastructure, compliance certifications, and 24/7 support — often exceeding what a mid-sized organisation can afford to maintain independently. The appropriate response to these concerns is a structured vendor assessment: review SLAs, compliance documentation (SOC 2, ISO 27001, FedRAMP where applicable), incident history, and support tier options. Data-driven evaluation replaces anxiety with actionable decision criteria.
5. Managing Time, Cost, and Security During Migration
Data migration is slow. Transferring large datasets requires significant bandwidth, careful scheduling to avoid production impact, and substantial engineering time. Security concerns during the transition period are also real — data in flight between on-premises and cloud environments must be encrypted, and access controls must be reviewed and updated as workloads move. Plan the migration in phases, transfer data during low-traffic windows, use encrypted transfer services provided by your cloud vendor, and conduct a security review at each phase boundary rather than only at the end.
6. Avoiding Hype-Driven Over-Migration
Not every workload belongs in the cloud on day one, and not every workload belongs with the same provider. A common mistake is moving too much too quickly, driven by executive enthusiasm or vendor pressure rather than a sober workload assessment. Map each workload against its performance requirements, compliance constraints, latency sensitivity, and cost profile before assigning it a migration target. Migrate in priority order — typically starting with workloads that are least business-critical and easiest to move — so your team builds competence before tackling the systems your business depends on most.
7. Change Management Across the Organisation
Cloud migration is a significant organisational change event, not just a technical project. Treat it accordingly. Stakeholders across the business — finance (for new cost models), security, compliance, application owners, and end users — all need to understand what is changing, when, and what it means for them. Establish a clear communication plan, identify change champions within each affected team, and build feedback loops that surface problems early. Requirements gathered from stakeholders during the migration should translate into concrete, measurable outcomes rather than vague aspirations.
8. Assessing Your Physical Network Infrastructure
Greater dependence on cloud services means greater dependence on your internet connectivity. Before migrating business-critical workloads, audit your physical network infrastructure. Key questions include: Do you have access to multiple ISPs for redundancy? Is your total available bandwidth sufficient for the increased traffic cloud-hosted applications will generate? Are your network edge devices capable of handling the load? Do remote and mobile workers have reliable connectivity to cloud endpoints? Gaps in physical infrastructure can silently undermine even a technically excellent cloud migration.
9. Accurately Estimating Cloud Costs
Cloud pricing is granular and variable, which makes it genuinely difficult to estimate accurately before you have real usage data. Common mistakes include underestimating data egress costs, failing to account for idle resource charges, and not modelling how costs scale with usage growth. Use your cloud provider’s cost calculator, and complement it with real monitoring data from any workloads already running in the cloud. A practical approach is to migrate your least-used services first — this generates real cost data with low business risk, and those workloads are also where you are most likely to find immediate savings over on-premises equivalents.
10. Deciding How Much to Re-Architect
Cloud migration teams often face pressure from two opposing directions: those who want to refactor everything to be perfectly cloud-native before migrating, and those who want to lift-and-shift without changing a single line of code. Both extremes carry risk. A complete rewrite before migration delays the benefits of cloud and can consume more budget than the migration itself is worth. A pure lift-and-shift often means paying cloud prices for on-premises performance characteristics, missing the efficiency gains that cloud-native design enables. A pragmatic middle path is to migrate first and then iteratively modernise — get to the cloud quickly, then progressively refactor workloads to use managed services and cloud-native patterns as budget and capacity allow.
11. Translating Your Security Posture to the Cloud
Cloud providers operate on a shared responsibility model: the provider secures the underlying infrastructure, and the customer is responsible for securing everything built on top of it — data, access controls, application configuration, and network policies. Many organisations migrating for the first time assume the provider handles more than it does. Before migration, map your existing security controls to their cloud equivalents and identify gaps. Request and review third-party attestation reports such as SOC 2 Type II from your cloud provider. These reports describe both the controls the provider has in place and the complementary controls your organisation is expected to implement.
12. Lease vs. Own: Understanding the Long-Term Cost Model
For compute-intensive workloads, the economics of renting cloud capacity versus owning and financing hardware shift significantly depending on time horizon and utilisation rate. Variable cloud pricing is highly efficient for bursty or unpredictable workloads. For steady, predictable workloads running at high utilisation, reserved instances or committed use discounts substantially reduce costs — but they introduce multi-year financial commitments. For some very high-volume, stable workloads, on-premises or co-location may still be the more cost-effective option. Model both scenarios with realistic utilisation projections before committing.
13. Connecting Legacy Systems with Cloud Applications
Most organisations have systems of record — ERP, CRM, mainframe-based processing, or purpose-built databases — that were never designed to communicate with cloud-native applications. Integrating these systems with newer cloud services is frequently the most technically demanding part of a migration. In the short to medium term, hybrid integration approaches are often the only viable path: middleware, API gateways, and event streaming platforms (such as Apache Kafka or cloud-native equivalents) can bridge on-premises systems and cloud applications without requiring a full rewrite of the legacy system. Choose integration vendors and tools that explicitly support hybrid environments and have a credible roadmap for fully cloud-native operation.
Planning Your Cloud Migration
No two cloud migrations are identical, but the challenges above appear consistently across organisations of every size and sector. The common thread is that successful migrations combine technical rigour with organisational readiness: clear objectives, honest cost modelling, a security-first mindset, and a realistic phased plan that builds competence before tackling your most critical systems.
- Start with a workload inventory — classify each workload by criticality, cloud-readiness, and migration complexity.
- Define success metrics before migration begins, not after.
- Build cost monitoring in from day one — cloud cost surprises are almost always the result of insufficient observability.
- Treat security as a parallel workstream, not a post-migration checklist item.
- Invest in team training early — cloud-native operations require skills that most on-premises teams do not yet have.
Original insights sourced from Forbes Technology Council contributor perspectives.