Agile Cloud Migrations… Only 10% of your programme is technology.

Let me justify that title, with a story, 12 months ago I was planning for a mass migration. A 10,556 mile migration of people, process… and …luggage from the UK to Melbourne, Australia. I was driving my wife crazy with a Kanban inspired approach to emigrating to the other side of the earth, with 2 small children, but it worked! The technical migration was fairly simple, however the people and process side of the migration was a little more complex and still has not completed!

The Technology – 10%

Let’s start with technology. You have your application estate, you have your existing infrastructure and network with all those lovely dependencies. You’ve probably identified your target cloud platform or multi-cloud platforms. You may have even decided on your migration tools to get you from A to B, perhaps you are leveraging VMWare HCX, or the AWS Migration Hub, or Microsoft’s Azure Migrate.

You probably have the mechanics of the technology in hand, also you have hopefully identified your business applications, linked them to critical business processes and prioritised your applications down a migration or transformational pathway. Which of your applications will you chose to be Rehosted, Replatformed, Repurchased, Refactored, Rearchitected, Rebuilt, Retired or Retained… the list of “Rs” gets longer every day!

As a piece of advice this application transformation strategy is critical. The value that you acquire in transforming your applications is directly relational to the value of that application to your business. If you are going to see a surge in customers/revenue/value in one area of your lines of business, then you should consider transforming the applications which support that business line. You will get more value from data, insights & customer experience by prioritising these. Ultimately this will help you to show top line growth as part of your transformation, instead of focussing on operational efficiencies, which will hamper your overall TCO.

The Process – 40%

For me, the process of my mass migration was a complex one. It was very much a multi-phase approach to re-host my family into Australia with temporary accommodation. Then the fun begins on the adaptation and transformation, rebuilding our life, redesigning our day to day routines and adopting this new environment. Simple things like the route to work and considering how to complete a tax return were on my backlog and the enormity of the migration settled in when I saw that my cargo ship had exited the Suez Canal, navigated the coast of Africa and was moored off the coast of Madagascar, preparing for voyage across the Indian Ocean.

For cloud transformations to be successful they have to be completed in a model which sets you up for success and to me that means adopting an Agile migration process. You need to discover your environment, analyse your application dependencies and allocate your migration targets into your backlog. Throughout this phase local contact is essential, you need to be holding hands with the application owners to ensure that they have the best possible migration and transformation experience. Your apps and the data that they depend on is the lifeblood of your organisation, you must not short-change this part of the process.

From there you can prioritise and assign each application to a sprint with a corresponding value chain, either to do a rapid migration with Rehost & Replatform options. Or a transformational value chain to refactor, Rearchitect or to Rebuild a new cloud native application. As this process advances, the agile feedback loop will enable you to gain quick value and more importantly to learn quick lessons, so that you can further refine the latter sprints. 

Stepping into a cloud delivery with this route allows you to adopt iterative governance and build out your delivery policies, processes and structures over time, whilst still allowing you to make tangible progress.

The ongoing delivery process should be designed to avoid a runaway train, you should aim to create a Cloud Centre of Excellence, which contains your multi-skilled team members. All of whom should be fully versed in the migration itself, so that there is little/no handover, but instead a steady stream of happy applications being moved through a DevOps migration and transformation factory.

People – 50%

Lastly the people aspect kicks in, and I’d argue that the people aspect overrides the previous two and accounts for 50% of your cloud success. Consider the culture change and knowledge gap of stepping from one delivery model to another? For my personal experience this presented in questions such as:

■      Why is the moon upside down?

■      Why are they playing rugby on a circular pitch?

■      What on earth is a schooner?

The knowledge and cultural change between traditional IT delivery and cloud native deliver are poles apart. Gartner highlights that “through 2022, insufficient cloud IaaS skills will delay half of enterprise IT organisations’ migration to the cloud by two years or more”. Knowledge can be learnt reasonably quickly, especially with the support of an MSP, there are a plethora of cloud certification pathways to guide this re-skilling, however culture is something which takes much more time to get right.

During your migration and transformation, there will be a whole host of learning points which come from things working as planned and also from things going wrong. The team culture and ability to see the positives in these small hurdles will be the bedrock of your ongoing success.

You will need to set out your vision, your principles and you should embody the target culture right from the top. Insist on continual learning and experimentation, accept failure and relentlessly drive adaptive changes to drive improvements in all areas of your new cloud enabled organisation!

Find out more & get in touch here.