Cloud foundation · 8 min read

Your cloud foundation
still matters.

A rapid migration is not a reason to postpone the foundation. It is the moment to build the guardrails that protect your business case, your run rate and your next wave of modernisation.

The foundation is not a future concern

Large cloud migration programmes often begin with a clear and legitimate business case: leave a data centre, reduce a fixed commitment, improve resilience or create room for growth. When the deadline is real, a rapid migration can be the right decision.

But a fast migration should not become an excuse to leave the cloud foundation behind. Even when the application landscape remains largely unchanged, the environment it moves into will shape its cost, security, reliability and operability for years. The foundation is not a layer to add after migration. It determines whether migration creates a platform for progress or simply relocates yesterday's problems.

Keep the business case and the run rate in view

A migration business case is often strongest at the start. The savings from exiting a data centre are visible, the programme has momentum and the target date creates focus. That is exactly when a second question needs equal attention: what will it cost to run this environment once the migration team has gone?

Cloud spend is not just a technical metric. It is a business outcome. It is influenced by architecture, operating model, ownership, data movement, resilience choices and the discipline with which teams use shared services. If those decisions are not visible during the migration, the original business case can quietly be replaced by a much higher run rate.

This does not mean every workload needs to be redesigned before it moves. It means the organisation needs guardrails from day one: cost allocation, budgets and forecasts, accountable owners, useful observability and a way to challenge the choices that drive ongoing spend.

Lift and shift is a route, not a strategy

Cloud providers and partners can make lift and shift sound like the obvious answer. It can be fast, reduce delivery risk and, in the right circumstances, be commercially sensible. When an organisation has a compelling reason to close an ageing data centre, a rapid move may be the best available decision. The value lies in retiring the old environment and removing a major operational risk.

But lift and shift should not become the destination. If an application moves unchanged into the cloud, its constraints usually move with it: rigid capacity, manual operations, unclear dependencies, weak cost visibility and recovery patterns designed for a different world. The organisation may gain a new hosting location without gaining the operating advantages of the cloud.

If the case is primarily about leaving the old environment, say so. Measure it. Then make sure the foundation keeps the door open for the work that follows.

A landing zone should support modernisation

A cloud foundation, often called a landing zone, is not an academic architecture exercise. It is the practical set of capabilities that allows teams to use cloud services safely, consistently and at pace.

It should provide a clear structure for identity and access, networking, security policies, logging, monitoring, cost management, automation and shared operational patterns. It should make the right route easier than the exception.

Most importantly, it should support gradual modernisation. Teams should be able to move a workload quickly today, then improve it tomorrow through cloud-native services, better resilience, automated delivery or more efficient data patterns. A sound foundation turns those improvements into repeatable work rather than a series of one-off projects.

There is always time to improve the foundation

In a rapid migration, someone will say there is no time. There is rarely time to build a perfect end state. But there is always time to establish the principles that prevent expensive rework later. The goal is not perfection before the first migration wave. The goal is a foundation that can evolve while protecting the programme.

That means clear ownership for cost, security and operations; reusable deployment patterns rather than manual exceptions; central logging and monitoring that teams can actually use; policies that create safe defaults; and a regular review of actual run rate against the original business case. These choices are not a delay. They are how a migration programme avoids creating a new legacy estate in a new location.

Hold the line when the compromises arrive

Every exception can sound reasonable in isolation. A shortcut helps one migration wave. A bespoke network pattern unblocks one application. A manual process feels faster than building automation. Over time, those small decisions become the shape of the platform.

A clear foundation vision gives teams a shared reference point when trade-offs are necessary. It helps leaders distinguish a temporary compromise from a permanent deviation. And it protects the organisation's ability to address the application landscape later, from a much stronger position.

The foundation does not need to solve every future problem. It needs to make future improvement possible.

Move fast, but leave the door open

Cloud migration is not only a destination change. It is an operating-model change. When urgency is high, lift and shift may be part of the answer. But it should be used with a clear exit case, not as a substitute for strategy. Without a strong foundation, the problems that existed on-premises often reappear in the cloud, accompanied by a surprising bill.

Build the platform that keeps your options open. Keep the business case honest. Watch the run rate. And make sure every migration wave moves the organisation a little closer to the cloud capabilities it will eventually need.