In my last post I pointed out the organisations we’ve worked with on their journey to the cloud fall into two broad camps.
Firstly, there are those who have a compelling event necessitating they move a significant portion of their infrastructure. This comes with a deadline and a cost if it is missed. We refer to these as having a burning platform. Secondly, we see those without a burning platform adopting a phased transition approach to cloud transformation.
In this post I want to delve more deeply into how having a burning platform will impact how an organisation adopt cloud.
Speed, quality, cost
There are a couple of traits of a burning platform migration that significantly shape the program of work. First and foremost of these is of course, the deadline by which the bulk of the infrastructure needs to be running somewhere other than where it is now.
One of the great truisms of major infrastructure projects (IT or otherwise) I first heard when I was at university. It has stuck with me all this time. Simply put, it is this:
Fast, good, cheap – pick two.
Speed is the issue
This basically means that in a major IT project there is a natural relationship between the speed, quality and cost of delivery. You can execute a transformation that is of high quality (and this includes reducing risk) in a short timeframe. However this adds cost. It requires teams of people working in unison and may require 3rd party tools to speed the process and/or reduce risk. Conversely you can deliver a high quality outcome cheaply – but it typically takes a long time. To keep the cost down, you do manually what tools could do faster or you leverage internal resources, taking them from their day jobs, at least to some degree.
The quest for quality
At least one of those elements (speed) is a given in the case of a burning platform. I’d argue most businesses can’t survive significant impact to their core infrastructure. Therefore, if speed is the issue, you really need the quality to be there as well.
In this respect, quality does not just describe the end state. It also, relates to the process. A high quality transition is one that minimises disruption to the business such as unplanned outages, data loss or a significant impact to the user experience.
Given that these types of migrations are working under time pressure, they tend to involve a lot of activities happening in parallel. Even if the desired timeframe is realistic and achievable this approach is inherently riskier than a phased approach.
The key recommendations I would make to help mitigate some of this risk are:
- Adopt a “lift and shift” approach. Minimise change within the application stack while you migrate. Except where absolutely necessary don’t try to re-platform everything to the latest Server OS or software version. These activities will add time, complexity and risk. When is it absolutely necessary? When the current version is not supported or won’t run on your target platform. Even then I’d advocate finding somewhere else to put it rather than adding change.
- Use tools to understand your source environment. We recommend using tools that will help you understand what you have now, the real requirements of the applications, and will also map out dependencies between servers and applications. This will help you make informed planning decisions for the design and migration.
- Don’t stop after the deadline. A lift and shift approach will leave you with things running on Infrastructure as a Service (IaaS). For a more cost effective solution, it could probably be transitioned to Platform as a Service or Software as a Service. Once you get the initial migration over the line it is important you revisit the environment. You should always be looking for opportunities for further refine or optimise.
In my next post I will explore our approach to a phased transition to the cloud. Until then, if you have any questions please feel free to contact us or join the conversation via the comments (below), Twitter or LinkedIn.