Your Azure Migration Project Is Doomed To Fail

Photo by Nathan Dumlao on Unsplash

That heading is a positive way to get your holiday spirit going, eh? I’m afraid I’m going to be your Festive Tech Calendar 2022 Grinch and rain doom and gloom on you for the next while. But hang on – The Grinch story ends with a happy-ever-after.

In this article, I want to explain why a typical “Azure migration” project is doomed to fail to deliver what the business ultimately expects: an agile environment that delivers on the promises of The Cloud. The customers that are affected are typically larger: those with IT operations and one or more development teams that create software for the organisation. If you don’t fall into that market, then keep reading because this might still be interesting to you.

My experience is Microsoft-focused, but the tale that I will tell is just as applicable to AWS, GCP, and other alternatives to Microsoft Azure.

Migration Versus Adoption

I have been working with mid-large organisations entering The Cloud for the last 4 years. The vast majority of these projects start with the same objectives:

  1. Migrate existing workloads into Azure, usually targeting migration to virtual machines because of timelines and complexities with legacy or vendor-supplied software.
  2. Build new workloads and, maybe, rearchitect some migrated workloads.

Those two objectives are two different projects:

  1. Migration: Get started in Azure and migrate the old stuff
  2. Adoption: Start to use Azure to build new things

Getting Started

The Azure journey typically starts in the IT Operations department. The manager that runs infrastructure architecture/operations will kick off the project either in-house or with a consulting firm. Depending on who is running things, there will be some kind of process to figure out how to prepare the landing zone(s) (the infrastructure) in Azure, some form of workloads assessment will be performed, and existing workloads will be migrated to The Cloud. That project, absent of (typically organisation) issues, should end well:

  • The Azure platform is secure and stable
  • The old workloads are running well in their landing zone(s)

The Migration project is over, there is a party, people are happy, and things are … great?

Adoption Failure

Adoption starts after Migration ends. Operations has built their field of dreams and now the developers will come – cars laden with Visual Studio, containers, code, and company aspirations will be lining up through the corn fields of The Cloud, eager to get going … or not. In reality, if Migration has happened like I wrote above, things have already gone wrong and it is already probably too late to change the path forward. That’s been my experience. It might take 1 or 2 years, but eventually, there will be a meeting where someone will ask: why do the developers not want to use Azure?

The first case of this that I saw happened with a large multinational. Two years after we succeeded with a successful Azure deployment – the customer was very happy at the time – we were approached by another department, the developers, in the company. They loved what we built in Azure but they hated how it was run by IT. IT had taken all their ITIL processes, ticketing systems, and centralised control that were used for on-premises and applied them to what we delivered in Azure. The developers were keen to use agile techniques, tools, and resource types in Azure, but found that the legacy operations prevented this from working. They knew who built the Azure environment, they came to us, and asked us to build a shadow IT environment in Azure just for them, outside of the control of IT Operations!

That sounds crazy, right? But this is not a unique story. We’ve seen it again and again. I hear stories of “can we create custom roles to lock down what developers can do?” and then that adoption is failing. Or “developers find it easier to work elsewhere”. What has gone wrong?

Take a Drink!

Adoption is when the developers adopt what is delivered in Azure and start to build and innovate. They expect to find a self-service environment that enables cool things like GitOps, Kubernetes, and all those nerdy cool things that will make their job easier. But their adoption will not happen because they do not get that. They get a locked-down environment where permissions are restricted, access to platform resources might be banned because Operations only know & support Windows, and the ability to create firewall rules for Internet access or to get a VM is hidden behind a ticketing system with a 5-day turnaround.

Some of us in the community joke about taking a drink every time some Microsoft presenter says a certain phrase at a conference. One of those phrases in the early days of Microsoft Azure was “cloud is not where you work, it is how you work”. That phrase started reappearing in Microsoft events earlier this year. And it’s a phrase that I have been using regularly for nearly 18 months.

The problem that these organisations have is that they didn’t understand that how IT is delivered needs to change in order to provide the organisation with the agile platform that the Cloud can be. The Cloud is not magically agile; it requires that you:

  • Use the right tools & technology, which involves skills acquisition/development
  • People are reorganised
  • New processes are implemented

Let’s turn that into the Cloud Equation:

Cloud = Process(People + Tools)

Aidan Finn, failed mathematician and self-admitted cloud Grinch

With the current skills shortage, one might think that the tools/tech/skills part is the hard part of the Cloud Equation. Yes; developing or acquiring skills is not easy. But, that is actually the easiest part of the Cloud Equation.

Our business has had a split that has been there since the days of the first computer. It is worse than Linux versus Windows. It is worse than Microsoft versus Apple. It is worse than ex-Twitter employees versus Elon. The split that I talk of is developers (Devs) versus operations (Ops). I’ve been there. I have been the Ba*tard Operator From Hell – I took great joy in making the life of a developer miserable so that “my” systems were stable and secure (what I mistakenly viewed as my priority). I know that I was not unique – I see it still happens in lots of organisations.

People must be reorganised to work together, plan together, build and secure together, to improve workloads together … together. Enabling that “together” requires that old processes are cast aside with the physical data centre, and new processes that are suitable for The Cloud are used.

Why can’t all this be done after Migration has been completed? I can tell you that for these organisations, the failure happened a long time before Migration started.

The Root Cause

According to my article, who initiated the cloud journey? It was a manager in IT Operations. Who owns the old processes? The manager in IT Operations. Who is not responsible for the developers? The manager in IT Operations. Who is not empowered, and maybe not motivated, to make the required Tools(People + Process) changes that can enable an agile Cloud.

In my experience, a cloud journey project will fail at the Adoption phase if the entire journey does not start at the board level. Someone in the C-suite needs to kick that project off – and remain involved.

A Solution

Mcrosoft Cloud Adoption Framework 2022
Microsoft Cloud Adoption Framework 2022

The Microsoft Cloud Adoption Framework (AKA CAF and AWS and GCP have their own versions) recognises that  Cloud Journey must start at the top. The first thing that should be done is to sit down with organisation leadership to discuss and document business motivations. The results of the conversation(s) should result in:

  1. A documented cloud strategy plan
  2. A clear communication to the business: this is how things will be with the implied “or else”

Only the CEO, CTO (or equivalent) can give the order that Operations and Development must change how things are done DevOps. Ideally, Security is put into that mix considering all the threats out there and that Security should be a business priority: DevSecOps. Only when all this is documented and clearly communicated, should the rest of the process start.

The Plan Phase of the CAF has some important deliverables:

  • Initial organisation alignment: Organise staff with their new roles in DevSecOps – The People part of the Cloud Equation.
  • Skills Readiness: Create the skills for the Tools part of the Cloud Equation.

Engineering starts in the Ready phase; this is when things get turned on and the techies (should) start to enjoy the project. The very first phase in the recently updated CAF is the Operating Model; this is a slight change that recognises the need for process change. This is when the final part of the Cloud Equation can be implemented: the new processes multiply the effect of tools/skills and organisation. With that in place, we should be ready, as a unified organisation, to build things for the organisation – not for IT Operations or the Developers – with agility and security.

I have skipped over all the governance, management, compliance, and finance stuff that should also happen to highlight the necessary changes that are usually missing.

Whether the teams are real or virtual, in the org chart or not, each workload will have a team made up of operations, security, and development skills. That team will share a single backlog that starts out with a mission statement or epic that will have a user story that says something like “the company requires something that does XYZ”. The team will work together to build out that backlog with features and tasks (swap in whatever agile terminology you want) as the project progresses to plan out tasks across all the required skill sets in the team and with external providers. This working together means that there are no surprises, Devs aren’t “dumping” code on IT, IT isn’t locking down Devs, and Security is built-in and not a hope-for-the-best afterthought.

Final Thoughts

The problem I have described is not unique. I have seen it repeatedly and it has happened and is happening all around the world. The fix is there. I am not saying that it is easy. Getting access to the C-Level is hard for various reasons. Changing momentum that has been there for decades is a monumental mission. Even when everyone is aligned, the change will be hard and take time to get right but it will be rewarding.  Bon, voyage!

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.