Let’s get this out on the table right up front: a lot of cloud adoption projects fail — and for many different reasons. That’s no knock on the cloud, it’s just par for the course. IT projects are always pretty fraught.
There was a point in my career when this puzzled me to no end. How can a large company full of smart people, and with the best intentions, set out to achieve an obvious good — modernizing their IT infrastructure — and completely fail to make headway after years of effort?
Cloud migrations can be tricky. But after working with many companies on cloud initiatives, I’ve started to pick up a few patterns. See if you recognize your own migration project in the pictures below:
Dead tree pruning
Some businesses only adopt cloud to get better at running their legacy systems. Maybe they’re out to drive down cost, or get out of the data center game, or alleviate some pressures of scale. These organizations want the benefit of cloud without changing much of anything about their systems, their architecture, or their people.
These types of migrations are usually called “lift-and-shift”, and nobody has lift-and-shift as an end goal. There’s always the assumption that a better architecture, a v2, a refactor, is just around the corner.
But the amazing thing about a lift-and-shift migration is that it’s not necessarily a stepping stone to a better cloud future. Just like pruning a dead tree, it can actually make things worse.
Like moving applications unchanged to the cloud, pruning a dead tree isn’t very hard, and you can see results in no time. The bad news is that it’s pointless, unless it’s the first step to cutting down the dead wood and planting a whole new tree. And new trees take awhile to grow.
Lift-and-shift migrations can be a delay tactic, not a guaranteed step forward. And delays are expensive, especially when they drag on for years. As bad habits accumulate in the cloud to support the legacy systems, the advantages cloud was supposed to provide remain — like a high tree branch — just out of reach.
The asteroid farm
Asteroid farmers seem much more cloud-native than the dead tree pruners. They may even be using fancy-schmancy cloud tools and services. An asteroid-farming business will have whole teams of people building with serverless and Kubernetes and whatever else the CNCF coughed up yesterday.
But when you look closely, you’ll see that all their feverish innovation is taking place on the periphery of their mission-critical systems. There’s no effort to get the big Oracle database out of the legacy datacenter or the big data out of the Oracle database. Instead, there’s this constant fringe of projects that pull bits of compute into the cloud for reporting, or run meta-workloads for managing future-state systems that never materialize.
The asteroid farmers run up big cloud bills and speak at cutting-edge conferences, but ultimately have little business value to show for it. And because nothing is happening, eventually the engineers who padded their resumes with the “cloud-native” projects move on to the next thing, and the business sinks back into maintenance mode.
I’ve seen lots of asteroid-farming companies get kind of disillusioned with cloud.
The donut hole
Unlike the asteroid farmers, the donut holes approach their cloud migration with serious strategic intent. They know that building out a Cloud Center of Excellence is a prerequisite to cloud success. So they establish architecture review boards and best practices. They implement central CI/CD pipelines and security gates. They create internal wiki pages explaining exactly how the whole business should go about adopting cloud. Then they sit back and wait for it to happen.
And yet somehow, when you fast-forward a couple of years the enterprise as a whole hasn’t made much progress toward cloud adoption. Everybody’s sort of still doing their legacy thing; maybe some people have engaged a bit with the central cloud team’s ideas, but there’s no sense of urgency to any of it. The cloud center of excellence ends up surrounded by a thick, chewy donut of dreadfulness, and all those well-laid plans might as well not even exist.
The petri dish
What do the dead tree orchards, the asteroid farms, and the donut holes have in common? They’re all attempts to graft cloud onto an existing technical and organizational structure, without undertaking the messy, difficult work of rehabilitating the structure itself.
The temptation for those of us who’ve experienced these problems is to blame some fundamental attribute of large organizations themselves: the politics, the inertia, the silos. But there’s nothing wrong with silos: they’re efficient ways of optimizing functional groups to achieve specific outcomes. The problem comes when old silos stop matching reality, and this is where you need transformational change.
The organizations I’ve seen adopt cloud successfully — and they do exist! — take an organic approach to change. Yes, they establish a cloud center of excellence, but they don’t let it become isolated. Rather, they foster outward-spreading cells of innovation within the legacy culture, kind of how penicillin spreads through a petri dish.
There are no shortcuts with this approach. You need comprehensive education, executive buy-in, and clear success metrics, as well as tolerance for the messiness of the process, to get off the ground. But a healthy cloud migration requires nothing less.
See how A Cloud Guru can transform your culture and guide you to success in the cloud.
Forrest Brazeal is an AWS Serverless Hero and enterprise architect who has led cloud adoption initiatives for companies ranging from startups to the Fortune 50.