Cloud migrations have a reputation for being difficult. Applications break, costs rise unexpectedly, deadlines slip and systems that worked perfectly well before the move can suddenly become less reliable.

When that happens, attention naturally turns to the migration itself. Yet many troubled cloud projects were already in difficulty long before anybody started moving workloads. The real problems often begin during planning, when organisations make assumptions about what they have, what they need and what moving to the cloud is supposed to achieve.

Starting with the destination instead of the problem

“We need to move to the cloud” sounds like a strategy, but it is not one.

Cloud is a way of delivering technology capabilities. The business case still needs to explain what those capabilities are expected to improve. Perhaps ageing infrastructure is expensive to maintain. Maybe the organisation needs better resilience, faster deployment or more flexibility as demand changes.

A useful cloud strategy starts with outcomes. What needs to become faster, safer, more resilient or easier to manage? How will the organisation know whether the investment has worked? Without clear answers, architecture decisions can quickly become disconnected from business requirements.

Not knowing what you actually have

One of the least glamorous parts of a cloud programme is also one of the most important: understanding the existing environment.

Established IT estates rarely resemble their documentation perfectly. Applications accumulate over years, servers are repurposed and integrations are created to solve immediate problems. A supposedly retired system might still feed data into a business process nobody thought to include in the migration plan.

Discovery therefore needs to go beyond producing a list of servers and applications. Teams need to understand dependencies, authentication services, data flows, recovery requirements and the people or processes that particular systems rely on. A forgotten dependency can look insignificant on a spreadsheet. During migration, it can stop an essential service from working.

Assuming every workload should move in the same way

Organisations often talk about “moving applications to the cloud” as though every application presents the same problem. It does not.

Some workloads can be rehosted with relatively little modification. Others make more sense when replatformed to use managed services. Certain applications justify redevelopment, while some should be replaced with software-as-a-service products or retired completely.

Applying one migration method across a diverse estate may simplify the programme plan, but it can create poor long-term results. Indiscriminately rehosting existing virtual machines, for example, can recreate the limitations of the old environment in a different location. The organisation has migrated, but it has not necessarily modernised.

Treating cost savings as automatic

Cloud can change the economics of IT significantly. It does not guarantee lower costs.

Without governance, oversized workloads can continue running around the clock, test resources can remain active after projects finish and storage can accumulate unnoticed. Cost management therefore needs to be part of architecture and planning, not something investigated after the first unexpectedly large bill.

Teams should know who owns cloud budgets, how consumption will be monitored and what controls exist around resource creation before large-scale migration begins.

Leaving security until the architecture is finished

Security teams are sometimes brought into cloud programmes after major design decisions have already been made. They are then asked to review the proposed environment and identify problems.

That turns security into an inspection rather than part of the design process. Identity, permissions, configuration, data protection, monitoring and regulatory requirements can all influence architecture. For UK organisations, data protection obligations are an obvious consideration, while regulated industries may have additional requirements.

Discovering a conflict during planning is inconvenient. Discovering it after hundreds of workloads have moved is considerably worse.

Recognising where expertise is missing

A strong internal IT team can still lack experience in some areas required for a major cloud programme. Running an established production environment and designing a large-scale migration involve overlapping but different skills.

This is where specialist input can be useful, particularly during discovery and strategy rather than only during implementation. A broader guide to cloud consultancy services can help technology leaders understand the areas external expertise may cover and decide where it could reduce project risk.

The goal is not to outsource every decision. It is to identify gaps early enough that they can be addressed deliberately rather than discovered halfway through delivery.

Forgetting what happens after migration

Eventually, the migration team goes home and somebody has to operate what has been built.

The operational model should not be an afterthought. Teams need to know who responds to alerts, manages identity policies, reviews costs, owns backup and recovery processes and maintains each part of the platform.

New technology can also change how people work. Infrastructure teams may adopt more automation, developers may gain greater control over provisioning and finance teams may need more visibility into technology consumption. If these changes are ignored, organisations can end up reproducing old processes on new technology.

Migration day should be the boring part

Complex migrations will always produce some surprises, but migration itself should not be where an organisation discovers fundamental problems with its strategy.

By that point, teams should understand the estate, know why workloads are moving, have selected appropriate migration approaches and established how the resulting environment will be secured, governed, funded and operated.

The less exciting truth about successful cloud transformation is that much of the most valuable work happens before anything visibly transforms. Organisations that ask difficult questions at the beginning tend to face fewer uncomfortable ones after the migration.