Cloud migration is not a destination — it is a design problem. Organisations that lift and shift workloads without architectural clarity import their technical debt into a new environment at cloud prices, creating the conditions for expensive remediation rather than the agility and economics the migration was meant to deliver.
The Promise and the Reality of Cloud Migration
Cloud migration has become the default modernisation strategy for Australian enterprises. The commercial logic is compelling in the abstract: reduced infrastructure capital expenditure, elastic scaling, access to platform services, and the operational agility that on-premises environments cannot provide. For organisations still running aging data centres, the move to cloud carries an almost moral urgency — a necessary escape from the constraints of physical infrastructure into the flexibility of modern computing.
The reality, for a significant proportion of Australian organisations that have undertaken cloud migration programmes, is considerably more complicated. Costs have increased rather than decreased. Complexity has grown rather than diminished. The promised agility has not materialised, because the applications and processes that were migrated were not redesigned to take advantage of the cloud environment they now inhabit.
The fundamental error is treating cloud migration as a destination rather than a design problem. When organisations lift and shift existing workloads into cloud infrastructure without addressing architectural assumptions, they import not just the applications but the technical debt, the inefficiencies, and the structural constraints of the on-premises environment — at cloud prices and with cloud complexity added on top.
The conversation that is missing from most cloud migration programmes is not about which cloud provider to select or which workloads to migrate first. It is about what the target architecture should look like, and whether the organisation has the clarity and discipline to get there.
What Architectural Clarity Actually Means
Architectural clarity is not a technical document. It is an organisational agreement about how technology should be structured to serve business objectives — and it has to precede migration decisions if those decisions are to be anything more than expensive deferrals of the harder design work.
In practice, architectural clarity requires agreement on several dimensions that most cloud migration programmes skip in the interest of pace. The first is the target operating model for technology: which capabilities should be built and owned, which should be consumed as services, and which should be sourced from specialist providers. This is a strategic question, not a technical one, and it cannot be answered by architects alone.
Lifting and shifting existing workloads without redesigning them imports all the debt of the on-premises environment — at cloud prices, with cloud complexity added on top.
The second dimension is data architecture. Where data lives, how it moves, who controls it, and how it is governed are questions that become significantly more complex in a cloud environment spanning multiple providers and regions. Organisations that migrate without a clear data architecture often find themselves with data distributed across environments in ways that are difficult to query, expensive to move, and challenging to govern.
The third dimension is integration architecture. Legacy systems that remain on-premises must integrate with cloud-based systems. The integration patterns chosen at the outset of migration will constrain architectural options for years. Choosing the wrong pattern — typically, recreating on-premises point-to-point integration in a cloud wrapper — creates exactly the kind of technical debt in the new environment that was supposed to be left behind in the old one.
The Cost Surprise That Wasn’t
The phenomenon of cloud costs exceeding expectations is now sufficiently common to have its own term in the technology industry: cloud bill shock. For Australian enterprises, this has been a particularly acute experience in financial services, retail, and media, where data volumes are large and workloads are complex.
The causes are predictable in retrospect. Applications that were designed for on-premises infrastructure, where compute was fixed and data transfer was internal, generate significant costs when running in cloud environments where every API call, every data transfer between availability zones, and every storage transaction carries a price. The application was not designed with the cloud pricing model in mind because it was designed before cloud was the target environment.
Cloud-native redesign — rebuilding applications to take advantage of cloud pricing structures, autoscaling, managed services, and serverless patterns — is the architectural work that converts cloud potential into cloud economics. It is also expensive, time-consuming, and requires skills that many Australian organisations do not have in abundance. The organisations that undertook lift-and-shift migrations in the expectation that cloud-native redesign could follow have, in many cases, found that the follow-on work is more expensive and disruptive than the initial migration.
Why Reversibility Is More Expensive Than It Appears
One of the arguments made in favour of lift-and-shift migration is that it preserves optionality — the organisation can always redesign later. This is technically true but practically misleading. The cost of reversibility, in practice, is extremely high.
Once workloads are running in a cloud environment, operational dependencies accumulate rapidly. Teams build processes around cloud-native tools. Data pipelines are integrated with cloud services. Monitoring and security tooling is reconfigured for the cloud environment. The organisation becomes operationally dependent on the cloud provider’s ecosystem in ways that make the theoretical option to redesign or repatriate significantly more complex and expensive than it appeared at the outset.
This is not an argument against cloud migration. It is an argument for doing it with sufficient architectural clarity at the outset to avoid creating the conditions for expensive course correction later. The organisations that spend more time on architecture before migration consistently spend less time and money on remediation after it.
The Board’s Architectural Due Diligence Obligation
Cloud migration programmes typically receive board endorsement on the basis of business cases that present expected cost savings, risk reduction, and capability improvements. Rarely do these business cases include explicit discussion of the architectural assumptions on which the projections depend, the conditions under which those assumptions might not hold, or the cost of the remediation work that would be required if the target architecture is not achieved.
Boards approving cloud migration investments should be satisfied that the programme has a defined target architecture that is separate from the migration roadmap, that the target architecture has been validated by parties independent of the delivery team, and that the business case reflects the cost of achieving the target architecture rather than merely the cost of migrating workloads.
The difference between a cloud migration that delivers its intended value and one that creates a more expensive version of the original problem is almost always an architectural question. Treating it as such, at the investment decision stage, is the most effective governance intervention available to boards overseeing these programmes.
The difference between a cloud migration that delivers value and one that recreates the original problem at higher cost is, almost always, an architectural decision made before the first workload moves.