Cloud migration promises flexibility, scalability and cost savings. The reality is more nuanced. Ten practical considerations for organisations planning a move to cloud, from legacy compatibility to compliance and connectivity.
Cloud migration has become a standard part of most organisations’ technology plans. The benefits are well established: greater flexibility, better scalability, reduced infrastructure overhead, and the ability to adopt new capabilities without capital investment in hardware.
The reality of getting there is more varied. Cloud works well for many workloads and creates genuine complexity in others. The organisations that navigate it well tend to go in with clear eyes about what they are moving, why, and what the underlying infrastructure needs to support it. The ones that struggle tend to treat cloud as a destination rather than a series of deliberate decisions.
These ten considerations won’t cover every scenario, but they cover the ones that most commonly catch organisations out.
Running cloud infrastructure requires different skills from running on-premise systems. You do not need specialist expertise to use SaaS applications, but migrating business-critical workloads to IaaS platforms requires people who understand cloud architectures, the specific platforms involved, and the applications being moved. The cloud market is large, and the range of providers, tools and configurations is significant. Without the right capability in-house, it is difficult to evaluate options well, and easy to lose time on approaches that do not suit the requirement. Factor the cost of recruiting or contracting cloud skills into the business case from the start.
Legacy applications are often the most business-critical ones. Whether it is a database built a decade ago, a custom application that has been modified extensively, or a system with dependencies nobody has fully mapped, these workloads need careful assessment before migration. Not all of them will move cleanly to cloud, and some may not be suitable candidates at all. A compatibility review before migration planning begins will save significantly more time than it costs.
Cloud consumption models replace capital expenditure on hardware with recurring operating expenditure. This is often presented as a straightforward advantage, but it introduces forecasting challenges that on-premise models do not share. Cloud costs scale with usage, and without careful monitoring, they can diverge significantly from projections. Finance teams need visibility of expected cloud spend before approving migration, and the operating model after migration needs to include active cost management, not just occasional invoice review.
Data egress charges – the cost of retrieving data from a cloud environment – are one of the most consistently underestimated costs in cloud migration. If your applications or databases are in cloud and are accessed regularly at significant volume, egress charges accumulate quickly. Analyse the data flows in and out of the applications you are planning to migrate before finalising the business case, and factor egress costs into the ongoing operating cost model.
For regulated organisations, compliance requirements can constrain where data is stored and processed. Cloud providers offer regional choices, but the distributed and self-healing nature of cloud infrastructure can make data residency harder to evidence. Organisations connecting to regulated networks like the Public Services Network (PSN) or the Health and Social Care Network (HSCN) also need to demonstrate that their end-to-end architecture meets the relevant Connection Agreement or Code of Connection requirements. Cloud environments add complexity to that process if they are not planned for from the beginning.
SaaS applications are easy to procure. In many cases, a credit card and an internet connection are all that is required. The risk is that cloud tool adoption outpaces governance: tools are duplicated, data ends up in unsanctioned systems, and the IT team loses visibility of what is running on the estate. Clear software procurement policies, consistently applied, matter more in a cloud environment than in an on-premise one precisely because the barrier to adoption is so low.
The internet is a best-effort network. For light, latency-tolerant workloads, it is a reasonable foundation for cloud connectivity. For business-critical applications, production databases, or workloads subject to regulatory scrutiny, it is worth considering whether a private connection to the cloud is warranted. Dedicated private connectivity through services such as AWS Direct Connect or Azure ExpressRoute offers predictable performance, stronger security at the boundary, and the ability to evidence what is happening on the path. The right connectivity model depends on what the workload requires, not on what is simplest to provision.
Cloud providers offer capable security tooling, but it requires deliberate configuration to be effective. Default settings are a starting point, not a finished security posture. Regulated organisations face an additional challenge: security controls need to be evidenced continuously, not just configured and assumed to be in place. Inspection, policy enforcement, access governance, and change records all need to be operating and producing evidence before an assessment, not assembled in response to one. A managed security layer applied consistently across cloud and on-premise environments is considerably easier to evidence than a set of individually configured cloud-native controls.
Cloud lock-in occurs when workloads become tightly coupled to a specific provider’s native tools and services, making migration difficult and costly. This is common, and somewhat ironic, since reducing dependency on a single vendor is often part of the original case for moving to cloud. Building portability into migration plans from the start, through open standards, abstraction layers, and deliberate architectural choices, keeps options open as requirements change and as the cloud market continues to evolve.
AI-enabled applications create new data flows between cloud and on-premise systems, often at volumes and with sensitivity that existing connectivity and governance arrangements were not designed for. New attack surfaces emerge, compliance questions become harder to answer, and the path data takes between cloud and on-premise systems needs the same level of deliberate design as the workloads themselves. If AI workloads are part of the migration picture, the connectivity, inspection and evidence requirements deserve specific attention rather than being treated as a variant of standard cloud migration.
For regulated organisations, cloud migration rarely happens in isolation from the wider network estate. Workloads moving to cloud still need to reach on-premise systems, regulated networks, and users wherever they work. The connection between cloud and the rest of the estate is as important as the cloud environment itself, and it benefits from the same level of deliberate design.
Cloud Gateway provides managed private connectivity between cloud environments and the wider estate, including compliant connectivity to HSCN and PSN for organisations that need it. For more on how this works, see our Connect to the cloud page.
