When I talk to customers who are already knowledgeable about the cloud, but still have not started their trip, the main subject we discuss about is : what is the first step to take to move into the cloud?
Usually at that point we all know about the cloud and its various flavors, on a personal level. I have touched already the subject on how to start playing with the cloud as a person :https://cloudinthealps.mandin.net/2017/03/17/how-to-embrace-azure-and-the-cloud/. But it’s not that easy to translate a personal journey and knowledge to a corporate view and strategy.
There are two major ways to plan that journey.
The first is : move everything, then transform.
The second is : pick the best target for each application, transform and migrate if needed.
Lift and shift
I will touch quickly on the first path. It’s quite a simple planning, if difficult to implement. The aim is to perform a full migration of your datacenter into the cloud, lift-and-shift style. This can be done one-shot or with multiple steps. But in the end you will have moved all of your infrastructure, mostly as it is, into the cloud. Then you start transforming your applications and workload to take advantage of the capabilities offered by the cloud, in terms of IaaS, PaaS or SaaS offerings. The difficulty in there, for me, is that not all workloads or applications are a good fit for the cloud.
Identify you application portfolio
Enters the second solution : tailor the migration to your applications. Because the application is what matters in the end, along with the impact and use of this application for the business. The question of how you virtualize, or which storage vendor to choose is not relevant to your business.
In that case you will have to identify all of your application portfolio, and split that into for categories :
- Existing custom Apps
Mostly business critical applications.
- New business apps
Application that you would like to build
- Packaged Apps
Bought off the shelves
- Applications operations
Everything else. Low use, low criticity
And here is a breakdown of each category and what you should do with those applications.
For your business critical application, which you have built yourself, or heavily customized, please leave those alone. They are usually largely dependant on other systems and network sensitive, and will not be the most relevant candidates. Keep those as they are, and maybe migrate to the cloud when you change the application. Some exceptions to that rule would be when you have hardware that is on it end of life, or high burst/high-performance computing, which could take advantage of the cloud solutions provided for these use cases.
The new business apps, that you want to build and develop : just build those cloud-native, and empower them with all those benefits from the cloud : scalability, mobility, global scale, fast deployment. Use as much PaaS components as you can, let the platform provider handle resiliency, servicing and management and focus on your business outcome.
Packaged apps are the easiest ones : they are the apps that you buy off the shelf and use as they are. Find out the SaaS version of those applications, and use it. The main examples are office apps (Office 365, G Apps), storage and sharing (Dropbox, Box, G. Drive, OneDrive) email (Exchange, Gmail).
The largest part of your application portfolio will most likely be represented by the Application Operation. They cover most of your apps : all of your infrastructure tools, all of the low use business application. These applications can be moved to the cloud, and transformed along the way, without any impact on their use, while giving you a very good ROI at low risk. Some examples : ITSM/ITIL tooling (inventory, CMDB, ticketing), billing, HR tools etc.
With that in hand, how do you expect to start?