Cloud Adoption Is Widespread, but Deep Value Remains Elusive

Despite cloud computing being mainstream for well over a decade, many organizations are still treating it as little more than a remote data centre — a place to park virtual machines (VMs) rather than a platform for genuine transformation. The author, writing from more than ten years of hands-on experience as a CIO and CTO, argues that this conservative posture leaves the most important benefits of cloud computing completely untapped.

Case Study: Elastic Donation Infrastructure at Comic Relief

The author’s first significant encounter with cloud’s transformational potential came in 2009 while serving as CIO of Comic Relief, the UK charity known for its televised fundraising events (Red Nose Day and Sport Relief). The organisation faced a classic traffic-spike engineering problem: its telethons, watched by millions, generated enormous bursts of online donation traffic concentrated in a very short window on broadcast night. Building permanent on-premises infrastructure capable of sustaining hundreds of transactions per second — for only one or two peaks per year — would have been financially unsustainable.

Working with major technology partners, the team built a horizontally scalable, cloud-based donation platform. Horizontal scalability in this context meant that capacity could be increased by adding additional compute nodes during peak demand, rather than replacing or upgrading existing hardware. Nodes could be provisioned cheaply and quickly, and decommissioned once the peak had passed. The result was an autoscaling system that set transaction-volume records while keeping infrastructure costs proportionate to actual usage — an early, practical proof of what cloud elasticity could deliver.

Case Study: Migrating the National Geographic Image Collection to Google Cloud

Later, as CTO at National Geographic in Washington, D.C., the author led the migration of the organisation’s image collection — approximately two million iconic photographs, including the famous “Afghan Girl” portrait — from an internal on-premises platform to Google Cloud.

The migration addressed two distinct problems:

• Performance: The legacy on-premises system could no longer keep pace with user expectations as concurrent session counts grew. Moving to Google Cloud provided cost-effective access to additional compute capacity, improving application responsiveness at scale.
• Security: The existing system relied on a simple username-and-password authentication model that was out of alignment with modern security policies. The migration enabled the team to implement a new identity and access management (IAM) framework using Google Cloud’s native capabilities, restricting access to properly authenticated users and significantly improving the overall security posture.

The National Geographic case illustrates that cloud migration, when approached thoughtfully, is an opportunity to remediate technical debt in security and architecture — not just to replicate existing infrastructure in a different location.

Why Most Cloud Migrations Underperform

Enterprise cloud adoption, while growing, remains shallower than headline figures suggest. Even organisations that have formally adopted cloud services often have only a small fraction of their total workloads running off-premises. Two structural barriers explain much of the gap between cloud’s promise and its delivered value.

1. Hidden Transition Costs

The cost savings cited by cloud providers are real over the long term, but they are not automatic. Organisations frequently encounter an initial increase in costs during and immediately after migration, driven by factors including:

• Investment in retraining existing staff in cloud-native tools and practices
• New operational processes required for cloud environments — revised security policies, VPN configurations, access controls
• Data residency and sovereignty laws in certain jurisdictions that restrict where data can be stored or processed
• A shift from capital expenditure (CapEx) for hardware purchases to operational expenditure (OpEx) for cloud consumption — a change that can disrupt established budgeting and financial approval processes

2. Legacy Application Architecture

Many enterprise applications were designed within a data-centre paradigm: large, monolithic codebases running on tightly coupled hardware and middleware. These architectural characteristics directly limit the ability to exploit cloud-native capabilities. For example, decomposing a monolith into microservices and well-defined APIs allows separate teams to develop, test, and deploy individual components independently, reducing deployment bottlenecks and enabling faster iteration. A monolith moved to the cloud as-is gains little from that decomposition opportunity.

This is why a pure “lift and shift” strategy — moving VMs and their workloads to cloud infrastructure with no architectural changes — frequently fails to deliver meaningful improvements. It relocates existing constraints rather than resolving them.

The Alternative: A “Move and Improve” Mindset

Rather than treating migration as a destination, organisations should treat it as the beginning of a modernisation journey. The author proposes a four-phase framework for progressive cloud transformation.

Phase 1: Audit and Rationalize

Before migrating anything, take stock of what you actually have and whether it is worth migrating. Key questions to answer at this stage:

• Which applications are mission-critical, and which are candidates for deprecation?
• Could a legacy custom-built application be replaced entirely by a modern SaaS product, avoiding a complex migration altogether?
• What are the dependencies between systems, and in what order should workloads move?

A structured audit prevents teams from investing effort migrating applications that should be retired or replaced — a common and expensive mistake.

Phase 2: Optimize

Once the migration roadmap is clear, identify immediate improvements that the move to cloud makes possible. Security is often the most accessible quick win: replacing a weak authentication model with cloud-native IAM, enforcing least-privilege access, and enabling audit logging are improvements that can be implemented during migration without requiring significant changes to application code.

Phase 3: Enhance

Look for components of the application — or services that support it — that can be upgraded independently, without a full rewrite. Examples include:

• Replacing an aging relational database with a cloud-native managed database service, reducing licensing costs and operational overhead
• Improving front-end performance to increase conversion rates for customer-facing applications — quantifying the revenue impact of performance improvements helps build the business case
• Offloading static asset delivery to a cloud CDN to reduce latency globally

The enhancement phase is most effective when guided by the key business metrics that matter most to the organisation. Start with the pain points that have measurable financial or operational consequences.

Phase 4: Modernize

With a stable, optimised cloud-hosted application as the foundation, teams can begin more fundamental architectural changes. This is where cloud-native capabilities deliver their greatest leverage:

• Decomposing monolithic applications into microservices and APIs, allowing independent deployment of discrete components and significantly increasing development velocity
• Replacing rule-based or manual processes with machine-learning services — for example, automating metadata tagging in a document management system, with human review reserved for edge cases
• Adopting managed services for infrastructure-heavy concerns (queuing, caching, storage, identity) so that engineering effort shifts toward product features rather than platform maintenance

Lift and Shift Is a Starting Point, Not a Strategy

Moving VMs to the cloud can be a legitimate first step — it establishes connectivity, builds team familiarity with cloud operations, and may deliver some immediate cost relief on ageing hardware. But it should be understood as a foundation, not a finished state. The durable value of cloud computing for an organisation comes from progressively modernising the applications and processes that run on top of it.

For technology leaders, this means framing cloud adoption internally not as an infrastructure project but as a business transformation programme — one that requires sustained investment in people, process, and architecture, and that delivers compounding returns over time rather than a single cost-reduction event.

Key Takeaways for DevOps and Platform Teams

• Elasticity is the killer feature: If your cloud architecture cannot scale dynamically in response to demand, you are not exploiting the fundamental advantage cloud provides over on-premises infrastructure.
• Audit before you migrate: Not every workload deserves to be migrated. Replace or retire where possible; only migrate what genuinely needs to move.
• Security is not optional: Migration is an opportunity to raise your security baseline. IAM, secrets management, and zero-trust network access should be part of every cloud project scope.
• Decompose incrementally: You do not need to rebuild everything as microservices on day one. Identify bounded contexts within existing monoliths and extract them progressively.
• Measure business outcomes: Cloud projects that cannot demonstrate impact on revenue, cost, or risk will lose executive support. Instrument early, measure continuously, and communicate results clearly.