There are many reasons why organisations are choosing to embrace the Cloud (in one of the many guises we discussed in a previous blog post) but, once the decision is made, how do you go about making sure your new environment will be an optimised success providing a healthy return on investment? The answer, as with many things, is planning.
I’d like to preface the following with the clarification that no matter how much planning you do, you will always experience things that are unexpected – no one can plan for every eventuality and things will always crop up that will come as a surprise. However, the process of planning makes us aware, in broad strokes, of what we need to consider and, by thinking about the bigger picture makes us consider things that we may not have done at first glance.
A typical Cloud Transformation project will follow multiple phases, all of these are carried out with the aim of surfacing as much information as possible and making the migration a success. There is often trepidation amongst traditional IT teams that the Cloud is something to be feared or hated, however, if we treat it like a tool to be used in the correct job, it definitely has a place in everyone’s toolbox.
Phase 1: Portfolio Discovery and Initial Planning
This phase could also be called “You don’t know what you don’t know”. The focus here is to understand the current organisation and the associated portfolio of processes and applications.
The duration of time spent on each phase will vary based on the complexity of the organisation and what they’re trying to achieve (move one application vs. their entire estate for example) however, this phase would typically last 4 – 5 weeks. The reason for this is that a lot of things in businesses happen at specific times of the month (i.e. a payroll run at the end of the month), by running an assessment that extends beyond a month, we have a much greater chance of catching these one off tasks than if we just run an assessment for a day or two.
This phase will often involve the use of automated discovery tooling. This will scan your network(s) and discover applications. Depending on the exact tooling used, it can also identify application dependencies and links between different elements.
By the end of Phase 1, we should have identified our initial list of migration candidates and decided how our application base can be rationalised to a set of core, must have applications; due to the way Cloud resources are metered, you want to move only what is required and decommission anything that is not.
Phase 2: Prioritised Application Assessment
In phase 2 we look at what will give the business the most benefit for the least amount of effort. We focus on these “low hanging fruit” in order to deliver a faster time-to-value.
We use the data collected during Phase 1 to identify the important applications and do a detailed assessment of those that are the most critical. This will then inform our decisions as we begin our initial design of the target architecture.
One of the most important aspects of moving the initial applications is that it gives IT teams Cloud Migration experience that they may not have had before. It also gives the opportunity to interact with the environment and to establish a common set of services that will span the entire architecture – things like Jump Boxes, ExpressRoutes/Direct Connect etc.
This phase will likely last a couple of weeks, although again, it all depends on the size of the organisation and what they’re trying to achieve.