Cloud migration challenges: why moves stall or overspend, and the fix

Most cloud migration challenges are predictable. Migrations usually stall or overspend for the same few reasons. Nobody mapped the dependencies. Data-transfer costs were left out of the budget. The team did not know which security settings it owned. Old problems moved as they were into a more expensive environment.

This guide gives each challenge an early warning sign, a way to prevent it and a fix if it has already happened. If you are mid-migration and the plan has stopped matching reality, our cloud consulting services start with a review of what has moved, what it costs and who can access it.

Cloud migration challenges at a glance

Seven challenges account for most stalled, overspent or failed moves, and each has a sign you can spot weeks before it hurts. Find the row that matches what you are seeing, then read the section below it.

Each challenge starts in one stage of the move. A migration runs through five stages: assess, plan, move data, cut over and run. A problem is cheapest to prevent in the stage where it starts, and it usually costs more to fix at each stage after that.

• Assess (1): unmapped dependencies.
• Plan (3): cost overruns, lift-and-shift debt and skills gaps.
• Move data (2): security and access gaps, and slow data transfer.
• Cut over (1): no way back.
• Run (0): none of the seven starts here. This is where the ones you missed show up as invoices and incidents.

If you want the full step-by-step sequence, our cloud migration checklist covers it with an owner and evidence for each step.

Unmapped dependencies: why migrations stall

A common reason migrations stall is that a moved service still depends on something that stayed behind. The fix is a dependency map made during the assess stage, before anyone decides what moves in which wave.

Microsoft's Cloud Adoption Framework says it plainly in its guidance on planning a migration: dependencies between workloads cause service disruptions if they are not migrated together. It separates three kinds. Direct dependencies need low-latency communication and move together. Indirect dependencies tolerate some delay and can move in separate waves. Business dependencies follow reporting or management lines. When you are unsure how critical a dependency is, the framework's advice is to group the components together.

The dependencies that cause trouble are rarely on the architecture diagram. Look for these:

• Scheduled jobs that read from one system and write to another.
• Shared databases that two applications both treat as their own.
• Hard-coded IP addresses, hostnames and file paths.
• Authentication services, licence servers and email relays.
• Third parties that only accept traffic from your old addresses.

The same exercise shows what not to move at all. AWS's guidance on migration strategies suggests retiring applications whose average CPU and memory use is below 5 percent, which it calls zombie applications. Every application you retire is one less thing to map, move and pay for.

Cloud migration costs: where budgets break

Cloud migration costs break budgets in three places: data transfer charges, paying for two environments at once, and resources sized for the old hardware. All three are visible before the move if someone prices them.

Cost is a challenge most teams report. In Flexera's 2026 State of the Cloud report, a global survey of more than 750 cloud decision-makers and users, 85% named managing cloud spend as a top challenge. Estimated wasted cloud spend rose to 29%, its first increase in five years (as of March 2026).

Data transfer and egress

Cloud providers charge for data that leaves their network, known as egress. AWS gives each customer the first 100 GB of data transfer out to the internet each month at no charge, counted across its services and regions apart from China and GovCloud. Azure's bandwidth pricing also waives the first 100 GB a month. After that it lists $0.087 per GB for the next 10 TB from North America or Europe over its premium network (both as of November 2026).

A calculated example shows the scale. A product that sends 5 TB a month to its users from Azure in North America pays for 4,900 GB after the first 100 GB. At $0.087 per GB, that is $426.30 a month for traffic that may have cost nothing extra under a flat bandwidth contract in a data centre.

Smaller charges hide in the network design. AWS bills a NAT gateway, the network address translation service that lets private servers reach the internet, for each hour it is available and each gigabyte it processes. A chatty service behind one can cost more in network fees than in compute.

Double running and sizing

You pay for the old and new environments from the first wave until the old one is shut down. Every week the cutover slips adds a week of both. Put the overlap in the budget as its own line, with an end date.

Sizing is the other leak. Servers copied at their old size carry the spare capacity bought to last a whole hardware cycle. Set budget alerts on the first day. AWS Budgets, for example, can alert on both actual and forecasted spend, so the surprise arrives as an email and not as an invoice.

One cost is falling. The European Union's Data Act removes switching charges, including data egress charges, from 12 January 2027. Until then providers may still charge for the cost of a switch.

Cloud migration security: what you now own

Cloud migration security fails when a team assumes the provider now handles work that is still the customer's. The provider secures the infrastructure. You secure what you put on it, including who can reach it.

AWS calls this the shared responsibility model: the provider is responsible for security of the cloud, and the customer for security in the cloud. On a virtual server, that leaves you with the operating system and its security patches, your application software and the firewall rules. On managed storage, you still own your data, its encryption options and the access permissions.

The advice is not new. The US National Institute of Standards and Technology (NIST) published SP 800-144 in December 2011. It gives an overview of the security and privacy challenges of public cloud computing, and the points an organization should consider when it outsources data, applications and infrastructure.

For a working cloud migration security strategy, start from five practice areas. In March 2024 the US Cybersecurity and Infrastructure Security Agency (CISA) and National Security Agency (NSA) released five joint information sheets on cloud security, and they map well to a migration:

• Identity and access management. Create least-privilege roles before the first workload moves. Do not copy old admin accounts.
• Key management. Decide who holds encryption keys and how they rotate.
• Network segmentation and encryption. Encrypt data in transit during the move itself, not only after it.
• Data security. Classify data before it moves, so cloud migration data security rules follow the sensitive records.
• Managed service providers. Know what access any outside provider keeps after the project ends.

The migration window is the risky part. Firewall rules get opened "for now", data sits in temporary buckets, and old credentials still work. Give every temporary exception an owner and an end date. If a customer audit is on the horizon, our guide to SOC 2 for startups explains what evidence an auditor will ask for.

Data transfer and downtime

Large datasets move slower than plans assume, and the gap turns into downtime. Measure the transfer with real data on your real connection before you promise anyone a cutover date.

Google's guide to transferring large datasets gives the arithmetic. Moving 100 TB online takes over 10 days on a 1 Gbps connection. On a 100 Mbps connection, the same transfer takes over 100 days. Past that point Google suggests an offline transfer, where the provider ships you a storage appliance.

The cutover itself needs two controls. Microsoft's guidance on executing a migration recommends a change freeze, so nobody modifies the source systems during the migration window. It also has every support team review the rollback criteria before the move. A team that cannot say when it would reverse a cutover has no way back.

Lift-and-shift: old problems, new invoice

Lift-and-shift, or rehosting, moves an application as it is. It is usually the quickest strategy, and it carries every existing problem into an environment that bills by the hour.

That does not make it wrong. AWS lists seven migration strategies, the 7 Rs: retire, retain, rehost, relocate, repurchase, replatform, and refactor or re-architect. It calls refactoring the most complex of them and does not recommend it for large migrations. Its advice is to rehost, relocate or replatform first, then modernize after the migration is complete.

The challenge is the second half of that sentence. Teams rehost, declare the project done and never modernize. The bill then reflects a design built for owned hardware. Two habits prevent it:

• Pick a strategy per workload, not one for the whole estate.
• Write down, before the move, which rehosted workloads get modernized and when you will decide.

Planning is moving earlier. Flexera's summary of its 2026 report says cost optimization after migration fell from the third-ranked to the fifth-ranked migration challenge, while choosing the right instance and assessing cloud against on-premises costs grew in importance. Old code moved as it was is technical debt with a monthly invoice. Our guide on how to reduce technical debt shows how to rank what to fix first.

Skills gaps and unclear ownership

A migration changes who is responsible for what, and many teams discover that halfway through. The sign is one person holding every cloud decision, or nobody holding the cost and security ones.

Microsoft's guidance on preparing an organization for the cloud notes that letting each team run its own platform suits highly skilled teams. To limit security and compliance risk in that model, it says to assess team capabilities, provide training and run regular audits.

For a small team, that comes down to three named owners before the first wave: one for cost, one for access and security, and one for the deployment pipeline. One person can hold two of the three. What matters is that each has a name. If the pipeline is the gap, our DevOps consulting services build it with your developers.

Failed cloud migration: how to recover

A failed cloud migration is usually a stalled one: half the systems moved, both environments running, and costs above plan. Recovery starts by stopping new moves, not by pushing harder.

1. Stop the next wave. Nothing else moves until the current state is stable and understood.
2. Stabilize what has moved. Fix outages first. An incident response plan template gives the team roles and a timeline to work from.
3. Name the challenge. Use the table at the top. Most stalls trace back to one or two rows.
4. Decide per workload. Roll forward, roll back or retire. A workload that was a poor fit can stay where it was.
5. Re-plan with dates and owners. Add the missing piece: the dependency map, the budget line or the rollback criteria.

When production is down and the people who ran the migration have left, treat it as an incident. Our software project rescue service triages urgent requests the same day.

How we help with cloud migrations

We work with teams that are planning a move, stuck in the middle of one, or paying more than expected after one. Our cloud consulting services for startups cover the dependency map, the cost model with egress and overlap in it, a security and access review, and a cutover plan with rollback criteria. We work alongside your developers, so the knowledge stays with your team.

Every engagement is under an NDA, and the IP is always yours. Each project is different, so we quote it after a short call.

Frequently asked questions