The Unglamorous Work

Moving a workload is the visible part of a cloud migration. It has a date, a cutover window and a moment when the application comes up in its new home.

Whether the enterprise can depend on that workload afterwards is decided by work almost nobody sees: dependency maps, rehearsals, rollback plans and backups. None of it appears in the launch announcement. All of it decides whether the launch holds.

I learned this at Hewlett Packard Enterprise (HPE), leading a €150M global hybrid cloud transformation for a global eyewear enterprise across more than 150 markets, covering more than 1,200 applications and 2,500 servers. Three lessons from that programme have stayed with me.

Readiness lives in the dependencies

We defined four migration waves by environment and complexity. Development and test systems moved first, followed by infrastructure and the remaining servers. Each wave progressed from the least complex workloads to the business-critical ones, and every wave was planned from a dependency register, our single source of truth for dependencies.

That sequence was sound. The weak point was the dependency data underneath it.

Categorising workloads by complexity helped us plan. It did not tell us whether a workload was ready to move. Readiness depended on what each application talked to, and where those connections were incomplete, migrations started late. Some had to be repeated.

The lesson: categorisation supports planning, but dependency mapping determines readiness. A wave plan is only as reliable as the dependency map beneath it.

Continuity is designed, not hoped for

The programme reported zero business disruption. That outcome was not luck. It came from safeguards that were practical and specific, each answering a different question:

• Testing: does the workload behave correctly in its new environment?
• Migration rehearsals: can we do this within the time we have?
• Rollback arrangements: can we undo it if it goes wrong?
• Cutover windows: when will a move do the least harm to the business?
• Application-owner involvement: does the business agree that it works?
• Infrastructure readiness checks: is the target environment ready before anything lands on it?

Remove any one of them and the risk does not disappear. It moves to the business, usually at the worst possible moment.

Migrated is not the same as recoverable

The turning point in the programme was a backup decision.

The cloud platform's native backup capability did not meet the business requirements. They fell short on retention, recovery time objectives, recovery point objectives, coverage, independent backup copies and disaster recovery. We developed a separate Backup as a Service solution, which met all of them.

It is easy to assume that moving infrastructure to the cloud brings enterprise resilience with it. It does not. A cloud platform offers resilience features. Whether those features meet the enterprise's recovery requirements is a separate question, and it needs answering before migration, not after an incident.

The questions are specific. How long must data be kept? How quickly must a service be restored, and to what point in time? Is every workload covered? Is there a backup copy independent of the primary platform? What happens if a whole region is lost? If the native capability does not answer each of these, the gap has to be closed, and it is better found in the business case than in a recovery.

Built to be run

A migration ends. Operation does not.

The programme also delivered a 24×7 cloud operating model, designed for the organisation to own, operate and improve. That mattered as much as any wave. A workload the organisation cannot run, support and recover on its own has been relocated, not transformed.

What the programme reported

The programme was delivered in four waves over 15 months against an approved 21-month plan, six months ahead of schedule, with zero business disruption. It reported a 45% reduction in data-centre footprint, an 80% reduction in capital expenditure on re-architected systems and €4M in annual operating savings.

No single safeguard produced those results. They came from the combination: sequencing grounded in dependencies, continuity designed into every cutover, recovery treated as a requirement rather than a feature, and an operating model ready to take over.

The workload starting is the beginning of the test, not the end of it.