Don’t freak out. Learnings from my worst cloud migration nightmares

At the end of 2010, when I was still a Microsoft employee my manager asked me to lead business development of the new Microsoft Business Productivity Online Suite. BPOS consisted of Microsoft-hosted versions of Exchange, SharePoint, and Live Meeting applications that eventually transformed into full Microsoft Office 365. It was until I left Microsoft when the wake-up call happened and taught me the real nuts and bolts of the cloud migration projects. My first non-Microsoft cloud migration journey was, softly said, as hard as going into the Amazonian bushes with no GPS nor paper map. The only lifebuoy was our experience from former on-premises projects and infrastructure migrations to BPOS. In addition to the standard 8 work hours, I had to spend nearly 6 additional hours per day for the next 6 months running my own proof of concepts, with one goal in mind: to make it all working as expected and save us from failure. What I have learned during this grueling period of my life laid foundations for my current understanding and approach to the cloud migration projects. To sum it up in a few points my life would be easier if at the beginning I had addressed:

There are tens of chief executives, directors, and managers I worked with who tried to use the cloud migration project as a trampoline to jump higher on the corporate ladder. What you envision is probably enthusiasm and a supportive approach but in reality, in most cases, it was the opposite attitude. By constantly and insistently demonstrating each day that moving to the cloud makes no sense they tried to underline GM or COO doubts thus posing the perception they are the only ones conscious and aware of the dangers. The ones who are predisposed to handle more responsibilities thus should be promoted to lead and manage others.

Constantly under fire with no prior cloud migration experience, we also had not any proven guidance that could pave our road to a successful transformation. Because of a completely new technology stack and a new project implementation approach project manager became strong blockers. Whiteboards, spreadsheets, and scratched sheets of paper were insufficient to assure we have a solid plan. The so-called digital transformation deceived us. While reading marketing leaflets, it sounded simple and straightforward to do but in reality, tens of new questions was appearing during each meeting.

To assure we made the correct decisions several proofs of concept were organized but as the famous saying goes “you can’t get honey from a rock” we almost failed. Without a clearly defined list of systems and an ordered list of steps, we fell into agile testing. To cover up for our messy approach at the end of each day I was recreating subsequent elements of the test infrastructure in my own cloud environment so we could finally present a reasonably coherent whole for each of the POCs. As a cherry on the top apart from the development of my technical skills I drastically expanded my knowledge of musical bands by becoming a heavy, nighttime Spotify user.

Last but not least. Our hurray optimism was the only thing we could be sure of throughout each of the projects. No matter what was happening on we were projecting ourselves as explorers, The Columbuses of the New Cloud World. The danger of this perception is best described by saying that our eyes were bigger than our stomachs. In limited time with limited people onboard we tried to tackle every possible aspect of each cloud migration project. We promised ourselves to have answers to every question that can flow out during customer meetings. We lived and breathed the cloud. What happened as a result of this conviction was primarily a lack of solid arguments to convince some customers that cloud was a better alternative and in other cases complaints that we promised something that ultimately is not feasible. No matter how we ended we always left them with high infrastructure bills as solace.

Surely, I am not the only one who ground his teeth on the cloud migration projects but still, I believe there are some ins and outs that are worth sharing with a wider audience. Of course, you can study the cloud adoption framework published by Amazon on their website at AWS Cloud Adoption Framework but likely you will dig into a lot of details rather than focus on a high-level perspective on the cloud migration project. My goal is to awaken those who replicate my former approach and give suggestions to others who already
embarked on the cloud bandwagon.

Through this series of articles, I will shed some light on the first 3 elements of each successful cloud
migration project I took part in. These are:

If you adopt my findings your project shall run smoother and you probably will save yourself a lot of headaches not to mention high bills and difficult conversations with managers. Is the list complete? Not at all. But before you deep dive into the ocean spend some time assembling your boat with the necessary basic equipment. Afterward, you will forge your own path. Each article will discuss one element from my list. Below is a summary that gives you an overview of their content.

As I wrote earlier having only a proper attitude or exceptional motivation you risk failure. Migration to the cloud opens new possibilities that can be transformed into multiple new business strategies. To make all things working you must ensure business stakeholders are there to help you. They must be at least neutral if not strong proponents of the project. The best way to handle this challenge is to instill the cloud migration project into your organization. If it becomes an element of the company-wide strategy you win. You will have to work hard on the cloud business case not only by documenting reasons for the current stage of migration but also by discussing wider perspectives of the cloud migration journey. To make it easily adaptable to company strategy and digestible by your CFO you should divide this journey into shorter, independent steps. When you catch the attention of high-ranked stakeholders establish the cloud governance committee and engage them in its operations. Then you can identify and solve potential cloud adoption problems together.

This is the moment when you get more technical. You already received the green light to start the migration project and now your cloud committee expects some tangible results. You will have to allocate some time to go through the infrastructure cloud readiness assessment. The result in the form of a gap analysis will be your future guidance. Since the whole process must be imperceptible for the business operations you should also analyze data that will be moved during migration.

You are ready to work on the cloud migration plan. Be sure to have the cloud migration architect in your team. He will be your wingman and advisor while flying through meanders of the cloud integration:

While working on the cloud migration plan you must also secure an exit strategy. Sounds crazy? You probably don’t want to be the one who blows up the company operations. There are chances that unsatisfactory performance, high cost, or a change in company strategy will force a decision to opt-out. Use this moment to secure a safe return home. It is much easier to prepare so-called “reverse migration” while working on an actual migration project.

If you are not considering hiring a cloud migration specialist, what I am sincerely recommending if your team has not performed such operations before, you must identify areas where they would need upskilling. The process of training can take at least 2 months of learning and practicing before they get more confident in this entirely new environment.

Feeling ready to make first cloud migration step? Stop here. Before you dive deeper you must estimate costs of your cloud migration project. You have all necessary information thus the process will be easier. Take into account all you have learned earlier. The preliminary budget along with the project documentation must be revised and accepted by the cloud governance committee. In the end, remember that no matter where you operate you are still working with data. Analyze potential security risks and check required compliance.

The final element of your preparation for migration to the cloud is the proof of concept. Why should you bother? Simply to eliminate future guessing and minimize potential risks. Vast experience with your onpremises infrastructure may not be relevant when running its components in the cloud. Also, even the best external cloud consultant may find some modules or systems that are used in your company completely new to him. You are going through this exercise to test whether functionality critical to keep business operations running without disruption will perform as expected when moved to the cloud.

Don’t proceed with most difficult use cases. Select elements that represent key areas of your infrastructure. Start small then grow bigger. Use automation wherever possible. Implement incremental testing and rollouts. Because some things can still go wrong try to reduce this risk by moving a limited group of end-users to a new environment so they can identify potential issues while working. Finally, remember to constantly evaluate your migration strategy and review performance KPIs.

This is only the beginning of your incredibly engaging and joyful journey to the cloud. Buckle up. Put the  pedal to the metal and accelerate into the New Cloud World.