Over the past year, I've worked with an increasing number of businesses, large and small, who are excited (or in some instances apprehensive at the same time) to begin their journey to the cloud. This may be for a number of reasons, sometimes it's been IT led and they are wanting to increase innovation while reducing infrastructure maintenance, sometimes they have been given a calling from on high (C-Level) to go Cloud first/Cloud Only. On other occasions, it's big data or a specific technology but more and more it's because of the fear of their competitors doing it first and getting an advantage, even though often no one involved knows what that advantage may be upfront.
So where do you start if you're in an organisation looking to move to or harness the cloud? Well first, you should understand the reasons for moving to make sure it's actually feasible to achieve these goals. This is sometimes difficult depending on why the decision was made, at least two of the reasons listed above make it almost impossible. So the next thing to do is work out where you are. That doesn't just mean what data centres you're in, what servers you have on-premise, it's about getting an understanding of what your infrastructure is delivering to the business, how people interact with it, both users and administrators, and finally how it interacts with the other systems around it.
Cloud migration and adoption isn't an IT change, it's a business transformation. Whether this is moving to office 365/G-suite from your on-premise Exchange/Sharepoint environments as a first step, or creating a new datalake for people to get a single customer view. There are concepts within hyperscaler/cloud technology that must be understood at a basic level throughout the business to make sure true value is gained. It is fair to say the most successful cloud adoption engagements I’ve seen have been where the opportunity for transformation has been identified and put in the context of the priority assigned to customer specific business outcomes of cloud adoption to create a transformation roadmap for the short, medium and long-term.
So where does this journey of self-discovery start? Early in my career I asked my new director at the time, "what's the most important skill for this role?" he looked at me somewhat surprised that I'd admit I didn't know (as those of you who met me will probably think I come across like I believe I know everything and I'm sure his view of my opinion of myself was no different). He simply said "the same as every other role, self-reflection. You must learn from what you've done badly to improve, but you've also got to know what you did well so you can repeat it". In my opinion cloud transformation is no different, it must be iterative and you must be willing to make mistakes and correct them quickly while continuing what's been done well.
As such, the first things to do are to get an understanding of what services (often known as workloads) your current environments deliver to your users, both internal and external. You also need to do the same for environments that you don't know about. An application amnesty is key to this and I'll discuss this in another blog. This all needs to be done both at the technology/infrastructure level and at the business level. It's best to get some time with the users directly and understand their viewpoint. This will often help you get to grips with when they should be migrated to avoid busy times of year and how they should be architected to continue to give the users what they enjoy now, or hopefully improve on it. As well as this, understanding end-user impact will help you evaluate what success looks like and whether the migration of the application has improved user journeys.
The next step is to understand how you interact with your environments, what tooling is used, what tooling you'd like to use if you had a clean slate; what skills you have in-house and what training this may need; how your incident, change and problem procedures work and how they may need to be adapted. Also how you involve security/SecOps in your current environments, this is a chance to have them on board from the very beginning and make sure everything is built in a secure and approved methodology. Finally, work with finance from the very beginning, show them what's being done, how it will be consumed and how they can gain insight and visibility into what has often been considered a murky world of uncontrollable costs.
For certain parts of this journey, there are tools that you can use (especially around technical discovery), but if you'd like to talk through issues or concerns you've had so far, or some you're worried about before you've even started, please do reach out. Understanding where you are in terms of the current environment is clearly just the first step, over the coming weeks I will add further blogs detailing other steps and consideration points to build on this.
Stephen Old, Claranet UK