Cloud migration is one of the most expensive initiatives an enterprise can undertake — and one of the most frequently mismanaged. The technology itself is well understood. The cloud platforms are mature. The tooling is extensive. What goes wrong is almost never the technology. What goes wrong is the strategy that precedes it.
Studies and practitioner experience consistently point to the same root causes: inadequate discovery, poor workload sequencing, underestimated data complexity, and a tendency to treat migration as a project with a fixed end date rather than a programme that requires ongoing governance. A team that begins migrating workloads without a complete dependency map is not being bold — it is accepting a category of risk that will materialise as mid-migration surprises, unplanned rollbacks, and scope that expands after commitments have been made.
The most common pattern is: the organisation announces a cloud migration, names a deadline, and immediately begins moving the applications its teams know best — which are usually not the applications that matter most. The complex, deeply integrated, revenue-critical systems get deferred. When they finally get addressed, the team discovers dependencies on on-premises infrastructure that was already decommissioned, data volumes that were never factored into the migration timeline, and compliance requirements that the initial architecture did not account for.
Not every workload should be treated the same way. Applying a single migration approach to an entire application portfolio is one of the most reliable ways to drive up cost and extend timelines. The five patterns below provide a classification framework that helps teams make deliberate decisions about each workload.
Move the application to the cloud without changing its architecture. The workload runs on a virtual machine in the cloud the same way it ran on-premises. This is the fastest pattern and requires the least application knowledge, but it delivers the least cloud benefit — cost, resilience, and scalability improvements are limited because the application was not designed for cloud-native primitives.
Make targeted optimisations during migration — switching from a self-managed database to a managed cloud database service, for example — without redesigning the application's core architecture. This captures meaningful cloud benefit with a contained scope change, and is often the right pattern for stable, well-understood workloads that are not candidates for full re-architecture.
Redesign the application to take full advantage of cloud-native capabilities — containers, serverless functions, managed services, auto-scaling, event-driven patterns. This pattern carries the highest migration effort but delivers the greatest long-term benefit: lower operational overhead, better resilience, and the ability to scale individual components independently. It is most justified for business-critical applications with long remaining lifespans.
Decommission applications that are no longer used or that are duplicated by other systems. A properly conducted application portfolio review typically surfaces a meaningful percentage of workloads that are good candidates for retirement rather than migration — reducing the scope and cost of the programme while simplifying the post-migration landscape.
Keep certain applications on-premises, at least for now. Some workloads have regulatory constraints, hardware dependencies, or migration costs that are not currently justified by the business case. Explicitly deciding to retain is not a failure — it is a deliberate sequencing decision that should be reviewed on a defined schedule.
Before a single workload moves, the team needs a complete picture of the application landscape: what applications exist, what they do, what they connect to, what data they hold, who consumes them, and what compliance obligations they carry. This is the discovery phase — and it is consistently the most underestimated, most skipped, and most expensive step to skip.
The specific output that matters most is the application dependency map. This documents every connection between applications: which systems call which APIs, which databases are shared across applications, which batch jobs depend on which file transfers, and which third-party services are embedded in which workflows. Without this map, any workload sequencing decision is made on incomplete information. The most common mid-migration crisis — an application that stops working after a dependent service is migrated — is a dependency mapping failure, not a technical failure.
Discovery takes time. For a portfolio of 50 to 200 applications, a thorough discovery process typically takes four to eight weeks. Teams that compress this to two weeks or skip it entirely consistently report that the time saved in discovery is recovered three or four times over in mid-migration rework and extended stabilisation periods.
A landing zone is a pre-configured cloud environment that establishes the networking topology, identity and access management structure, security controls, compliance guardrails, and logging standards that every workload will inherit. Migrating workloads before the landing zone is designed and validated means each team configures these elements independently — producing inconsistent security postures, networking configurations that conflict as the estate grows, and remediation work that is far more expensive when applied retroactively to live workloads than when designed upfront.
Every team that skips dependency mapping justifies it the same way: 'We know our landscape well enough.' The teams that have completed rigorous dependency mapping exercises consistently report that they discovered significant dependencies they did not previously know about — particularly around shared databases, implicit API contracts between services that were never formally documented, and data flows that exist in ETL jobs written years ago by team members who have since left.
Cloud migration does not end when the last workload moves. Post-migration, the organisation still needs to manage cloud costs, optimise underperforming workloads, maintain security posture as the environment evolves, and handle the workloads that were retained but will need to migrate eventually. Teams that treat migration as a bounded project — with a dedicated team that disbands when migration is declared complete — typically find that cloud costs escalate and governance gaps accumulate within eighteen months.
The organisations that extract the most value from cloud migration treat it as a programme — an ongoing capability with a dedicated team, a maintained application portfolio inventory, a continuous cost optimisation function, and a governance model that keeps the environment aligned with policy as it evolves.
This does not mean migration never ends. It means the skills, processes, and governance built during migration are not discarded when the initial lift is complete. The team that migrated the first hundred workloads is better positioned than any external consultant to migrate the next fifty — and to optimise the first hundred so they perform and cost what was promised.
At QueuesHub, our cloud migration practice supports organisations through every stage of this journey — from initial assessment and landing zone design through workload migration, post-migration optimisation, and the ongoing governance that keeps cloud environments aligned with business and compliance requirements. If your organisation is planning a migration or navigating a stalled programme, we are glad to help you find the right path forward.
