What usually goes wrong first when a company moves to the cloud? It is rarely the servers. It is the surprise: a bill that triples, an application that refuses to start, or a security reviewer asking who approved a storage bucket that nobody can name. The technology works. The trouble comes from everything wrapped around it.
Cloud migration is the process of moving applications, data, and workloads from on-premises data centers or one cloud provider to another. It sounds like a lift-and-shift exercise. In reality, it is a long chain of decisions about architecture, contracts, compliance, and people. Below are the challenges that show up most often, why they are hard, and what tends to work when teams face them.
The challenge starts before anyone touches a server
The most common mistake in a cloud migration is treating the inventory as a formality. Teams list the servers they know about, skip the shadow IT, and discover weeks later that a reporting job depended on a database nobody documented.
Good discovery answers harder questions than “what do we have?” It maps dependencies: which service calls which, what runs on a schedule, which systems share a database, and which have hard-coded IP addresses. A practical starting point is a structured approach to what to inventory before a cloud migration, because the inventory becomes the migration plan whether or not anyone intends it to.
Two practical tips from teams that have done this well:
- Run network flow analysis for at least a full month, ideally a full quarter, so monthly and quarterly batch jobs appear.
- Interview the people who run the systems as well as the people who own the budget. The on-call engineer usually knows about the undocumented cron job.
Choosing a migration strategy is harder than it looks
The industry has a shared vocabulary for migration approaches, often called the seven Rs: retire, retain, rehost, relocate, replatform, repurchase, and refactor. The set was popularized by Gartner analyst Richard Watson around 2012 and has been revised since, which is itself a warning: even the frameworks shift.
| Strategy | What it means | Typical risk |
|---|---|---|
| Retire | Turn the system off | Hidden dependents surface late |
| Retain | Keep it where it is for now | Drift and forgotten workloads |
| Rehost | Move as-is | Carrying old problems to a new bill |
| Relocate | Move the platform, not the app | Limited to specific technologies |
| Replatform | Small changes to fit the cloud | Scope creep mid-project |
| Repurchase | Switch to a SaaS product | Data migration and retraining |
| Refactor | Rebuild for cloud-native design | Cost and timeline overruns |
The trap is defaulting to rehost for everything because it looks fastest. Rehosting is genuinely the right call for some systems. But rehosting a poorly understood application simply moves the mystery to a more expensive location. A useful discipline is to assign a strategy per application, in writing, with a named owner and a one-line reason. When the reason is “we ran out of time,” that is a signal to retain the system deliberately rather than migrate it badly.
Legacy systems and skills gaps slow everything down
Old applications carry old assumptions: local file paths, hard-coded credentials, single-server state, and dependencies on software versions that no vendor still supports. These are not glamorous problems, but they consume the calendar.
The skills gap is just as real. Moving to the cloud changes the job of the people doing the work. Infrastructure becomes code. Networking becomes software-defined. Security becomes a shared responsibility model rather than a firewall at the edge. Teams that plan for training, pairing, and a period of reduced delivery speed tend to recover faster than teams that assume the same people will simply absorb the change.
A common mistake here is hiring cloud specialists and expecting them to migrate legacy systems alone. The people who understand the legacy application are the ones who know why it behaves the way it does. Pair them with the cloud engineers rather than replacing them.
Cost surprises are the most predictable failure
Almost every migration story includes a bill that does not match the forecast. The reasons repeat: forgotten test environments left running, data transfer charges nobody modeled, storage tiers chosen by default, and autoscaling configured so generously that it scales into the budget.
Egress fees deserve special mention. Moving data out of a cloud provider is often charged, and those charges are a documented switching barrier. The European Union’s Data Act, Regulation (EU) 2023/2854, which entered into force in January 2024 with most provisions applying from September 2025, includes cloud-switching provisions intended to reduce lock-in. Regulatory attention to exit costs is a strong signal that the problem is structural, not imaginary.
The fix is not a stricter budget. It is better visibility. Cost reviews only change behavior when engineers can see the connection between their code and the bill, which is why a clearer way to track cloud data transfer costs matters more than another dashboard. Tagging discipline, per-team cost allocation, and reviewing spend with the engineers who control it all help. Making cloud cost reviews useful to engineers is a cultural project as much as a finance one. (Cloud computing)
Security and compliance work expands, not shrinks
In a data center, security has a perimeter. In the cloud, it has a configuration surface. Every storage bucket, identity role, and network rule is a decision, and the default is not always safe.
Three recurring problems stand out:
- Identity sprawl. Roles accumulate permissions because removing them requires knowing what still uses them.
- Misconfiguration. Public storage, overly broad security groups, and logging that was never turned on.
- Shared responsibility confusion. Teams assume the provider secures something that is actually the customer’s job.
Compliance adds another layer. Regulated industries must show that controls still work after the move. In the United States, federal agencies and their vendors work through FedRAMP, a standardized security assessment program built on the NIST SP 800-53 control catalog. In the EU, the NIS2 Directive, Directive (EU) 2022/2555, imposes cybersecurity risk-management duties on cloud providers and their customers, with member states required to transpose it by October 2024. Neither framework is a migration blocker, but both add documentation and evidence work that rarely appears in the original timeline.
Data residency is the other constraint. Rules about where data may be stored and transferred vary by jurisdiction. The GDPR’s rules on international transfers are the best-known example, and they directly affect which regions a workload can use. Reading a region announcement carefully, rather than assuming a new region solves a residency problem, is a skill worth building. A guide to how to read a cloud region announcement covers what the fine print actually means.
Lock-in and exit planning get ignored until too late
Vendor lock-in is not a single problem. It is a stack of small dependencies: proprietary APIs, managed services with no equivalent elsewhere, data formats that are awkward to export, and identity systems wired into everything.
The practical response is not to avoid managed services. That would throw away much of the cloud’s value. The response is to know which dependencies are strategic and which are accidental. A few habits help:
- Keep data in open formats where the cost of doing so is low.
- Isolate provider-specific code behind an internal interface.
- Document what an exit would require, even if nobody plans to leave.
- Review the contract’s exit terms before signing, not after.
Splitting workloads across accounts is related, and it is as much a governance decision as a technical one. Knowing when to split workloads across cloud accounts reduces blast radius and makes cost attribution cleaner, but it also multiplies the number of places a misconfiguration can hide.
Organizational friction is the quiet blocker
Migrations fail for people reasons more often than technical ones. Ownership is unclear. A platform team builds guardrails that application teams experience as obstacles. Security is brought in at the end as an approver rather than at the start as a partner.
What actually works, in practice:
- Name one accountable owner per workload, with authority to make trade-offs.
- Bring security and finance into design reviews early, while decisions are still cheap to change.
- Publish a paved road: approved patterns, templates, and golden images that make the secure option the easy option.
- Celebrate retirements. Turning systems off is a real migration outcome and deserves the same visibility as a launch.
The organizations that struggle most are usually the ones treating migration as a project with an end date rather than a change in how infrastructure is run. Cloud platforms keep changing. The operating model has to keep up. That is why enterprise AI and cloud security practices increasingly overlap with migration planning: the same identity, data, and governance decisions serve both.
Conclusion
Cloud migration challenges are rarely about whether the technology works. They are about incomplete inventories, strategies chosen by default, legacy assumptions, cost models that ignore transfer and idle resources, security surfaces that grow with every configuration, lock-in that accumulates quietly, and teams that were never set up to succeed.
The pattern across all of them is the same. The problems that hurt most are the ones nobody wrote down. Teams that inventory thoroughly, assign a deliberate strategy per application, bring security and finance in early, and treat cost and exit planning as engineering problems rather than afterthoughts consistently have calmer migrations. For a broader view of how these pieces fit together, the cloud infrastructure and architecture resources at 9481.org are a useful reference point, as is the site’s coverage of enterprise AI and cloud intelligence.
The cloud does not remove complexity. It relocates it, and then hands you the controls. Knowing where it went is most of the work.
FAQ
What is the biggest challenge in cloud migration?
In practice, incomplete discovery is the biggest one. Teams migrate what they can see and discover later that undocumented dependencies, scheduled jobs, and shadow systems were part of the estate all along. Almost every other problem, from cost overruns to outages, traces back to something that was not in the inventory.
How long does a typical cloud migration take?
There is no standard duration. A single application can move in weeks; an estate with legacy systems, regulatory constraints, and dozens of dependencies can take years. The more useful question is how long each phase takes: discovery, design, pilot, migration waves, and decommissioning. Decommissioning is the phase most often skipped, which is why old systems keep costing money long after the “migration” is declared complete.
Why do cloud costs often exceed forecasts?
Three reasons dominate. First, resources that were meant to be temporary stay running. Second, data transfer and egress charges are poorly modeled. Third, storage and compute tiers default to expensive options. Forecasts also tend to assume steady usage, while real workloads spike. Tagging, per-team cost visibility, and regular reviews with the engineers who control spend address most of it.
What is vendor lock-in, and how do you reduce it?
Vendor lock-in means the cost of leaving a provider is high enough to constrain your choices. It comes from proprietary APIs, managed services with no equivalent elsewhere, awkward data export, and tightly coupled identity systems. You reduce it by keeping data in open formats, isolating provider-specific code, documenting an exit plan, and reading contract exit terms before signing.
How do security and compliance change after migration?
The perimeter model gives way to a configuration model. Every storage bucket, identity role, and network rule is a decision, and misconfiguration becomes the main risk. Compliance work grows too: frameworks such as FedRAMP in the US and the NIS2 Directive in the EU require evidence that controls still work, and data residency rules limit which regions a workload can use.
Should every application be refactored for the cloud?
No. Refactoring is expensive and slow, and it only pays off for systems that will change often or need cloud-native scaling. Rehosting is a legitimate choice for stable applications, and retaining a system deliberately is better than migrating it badly. The mistake is choosing a strategy by default rather than assigning one per application, in writing, with a reason.
