There are many different approaches you can take to migrate to the cloud. Do you want Software as a Service or Infrastructure as a Service? They are significantly different. The line of responsibility and decisions that you have to make are quite different across those, albeit they’re all called cloud.
There are also various roadmaps that you can follow. One is a straight line that says everything is ‘as is’ and everything needs to be in a ‘to be’ but the challenge in that is defining what ‘to be’ looks like, and getting that agreed. Because the decision about ‘to be’ involves deciding which cloud and which type of cloud service. Is it a full software as a service, is it infrastructure as a service or is it something in between?
The important thing is being able to step through the process logically and develop a defined strategy. A technology strategy, a business strategy, and also some level of cloud strategy.
What’s the starting point?
In my previous organisation, we identified the ‘as is’ state as the starting point and then we applied something called the six R's, to decide the fate of each application:
- Re-locate / Re-host - otherwise known as “lift-and-shift.”
- Re-platform - or “lift-tinker-and-shift.”
- Re-purchase - moving to a different product.
- Re-architect - reimagining how the application is architected and developed, typically using cloud-native features.
- Retire - get rid of.
- Retain - usually this means “revisit” or do nothing (for now).
The first step is identifying all of your applications, we had about 400 discreet applications, and then, for each one of them, you have to decide what it’s fate is. Is it something which needs to be retained, or relocated or retired? And then you decide what its trajectory is. How do we get it into its target state? That can be any one of a number of things ranging from relocation through to a complete rewrite.
What stays and what goes?
It could be that the application that you started with isn't the right application, and so you need to go out and choose a new one, actually design it from scratch. That involves a lot of work to identify what the application is providing, how is it constructed and what’s needed in the future. All of that is time and money. So even if you had unlimited money and time that would still be significant if you look at an entire company's portfolio of services.
You also need to identify the relative value of your applications. Which applications can’t be at the mercy of a third party who might deprecate a feature that is part of your key business process? What processes are unique and bespoke to each company to the point they are crown jewels?
You need to understand the asset life of the equipment you are running on premises. If somebody has just invested in an expensive on premises hardware platform, back-to-back cost elements say that the equipment will need to depreciate over its lifecycle. It would be a very brave person, a very brave CIO, who would turn around to the finance team to say, we've made a strategic decision to move everything to the cloud next year, and that means we have to write off that million pound platform.
What are the skills available in the team?
You can build a scorecard to see what you actually do right now, what does your application state look like, how up to date is it, what are your skill sets like within the teams that you have. Are they appropriate for a cloud migration activity? You might very quickly come to the conclusion that you don't have the people in place that you need to support, not just the running services in the cloud, but more importantly the migration activity in the first place.
The skill set you require in the team when working in the cloud vs working on prem is different and that’s part of the business transformation. If you've got people who have either got cloud experience from previous organisations, or you have got people that you can bring in to to work in the modified way, then that’s going to help you.
How far into the cloud?
Adopting cloud fully and moving all applications to Software as a Service is quite a courageous decision. If you have ownership of more of the stack then you know what the decisions are at other points in the stack. Whereas, if everything is operated and run by a third party you are at their mercy if they completely redesign - or worse - deprecate their application.
If you migrate to cloud, do you go with one provider or multi providers? There will be proprietary aspects of each of those cloud providers which may be beneficial to you, but might not be available from other cloud providers. You have to have the level of insight and knowledge to be able to make some of those decisions so you don't paint yourself into a corner.
The reality is, although cloud tools are often paid on a month by month basis, you’re not going to change your provider every month. It’s not in the interest of the application providers to make the migration away from their tool easy. The reason that you choose a particular application in the first place may be for some unique features which are proprietary to the application. So immediately, when you decide to move from one application to another, then it's back to that rewriting aspect, at least for those features. You get the standard features from any one of these vendors but for the specific things that you place a value on you may need to decide, is it worthwhile sticking with what we've got or moving to a different one.