Cloud Engineering

In most estates there is at least one critical system whose behaviour is understood by one person, and at least one integration nobody documented.

Migration is an engineering problem, not a moving job

Cloud migration is often planned as though it were logistics: an inventory, a sequence, a cutover weekend. The organisations that struggle are usually the ones that treated it that way.

A successful migration rests on three pillars — planning, moving workloads, and operating in the cloud. The third is the one most plans underinvest in, and the one that determines whether the benefits survive the first year.

The measure of a migration is not that it completed; it is that the team left holding it can run it.

Understanding what you actually use

Before anything moves, you need an honest picture of the existing estate: what each system does, what depends on it, what it costs to operate today, and who knows how it works.

That last point is not a joke. In most estates there is at least one critical system whose behaviour is understood by one person, and at least one integration nobody documented. Both will surface during a migration; the only question is whether they surface during discovery or during cutover.

Choosing per workload, not per estate

There is no single best migration solution, and applying one approach to everything is the commonest cause of disappointing outcomes. Some workloads should be rehosted and left alone. Some should be replatformed onto managed services. Some should be refactored properly. Some should be replaced with SaaS, and a meaningful number should simply be switched off.

Deciding this per workload takes longer up front and is the difference between a migration that saves money and one that moves the bill.

The biggest challenges

• Hidden dependencies discovered too late
• Data migration — volume, consistency, and the cutover window
• Cost surprises, where elastic infrastructure is billed like elastic infrastructure but sized like a datacentre
• Skills, because running cloud infrastructure is not the same job as running servers
• Post-migration issues nobody owns, because the project ended at cutover

Getting data across safely

Data migration deserves separate treatment from application migration. The essentials: profile and clean before you move rather than after; migrate in stages with reconciliation at each one; run parallel long enough to compare outputs; and agree in advance what "correct" looks like, in numbers, so the decision to go live is evidence-based rather than a judgement call at 2am.

The key to a successful migration

The pattern that works is unspectacular. Prove the approach on something low risk. Keep a rollback path until each move is verified. Plan for operating in the cloud — monitoring, cost management, security posture — as part of the project rather than as a follow-on.

And treat the handover as a deliverable. The measure of a migration is not that it completed; it is that the team left holding it can run it.