In the first post in this series I highlighted that organisations we work with on their journey to the cloud fall into two broad camps. Firstly, those who have a compelling event necessitating moving a significant portion of their infrastructure – 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 who adopt a phased transition to cloud transformation.
I’ve already looked at the Burning Platform approach in detail. Now I want to explore the phased transition approach.
Unlike organisations with a compelling event driving change, those adopting a phased approach have the luxury of time. This enables them to break up the transformation into manageable “bite-sized chunks”. However, this approach can also present challenges of its own.
CIOs and IT managers with a history of deploying infrastructure on-premises will be used to 18 month software release cycles and three to five year hardware refresh cycles. Coming from that background, it’s easy to be tempted to try at the outset to build a fairly detailed plan for a three year infrastructure transformation program. But the game has changed. With the rate of change in the cloudscape, if you try to plan a three year program in any detail, you’re on a hiding to nothing.
We’d recommend an alternate approach, to lay the foundation for the cloud and take an iterative approach to the transformation. In practice this means there are a number of stages in a phased transition. At a high level they are:
While it’s important not to go too deep at this stage a few decisions need to be made up-front. Which cloud platform – or platforms – are you going to be targeting? Single public cloud, multiple public cloud, private cloud or hybrid? Another critical decision you really want to get right up-front is to determine the strategy for identity. Finally, a strategy for connectivity to your chosen cloud or clouds deserves some consideration.
Define and prioritise the workloads to be moved to the cloud. At this stage don’t concern yourself with how you will transition or what to target. Undoubtedly, by the time the first project is finished some of the goal posts will have moved. Just focus on understanding which workloads are going to produce the most benefit for the least effort and prioritise those first.
Lay the foundation
Spend time putting the connectivity and identity foundations in place up-front. You don’t want to have to address either of these when you’ve already start moving workloads and running into issues.
Plan out the first wave
This stage could involve multiple streams if they are sufficiently independent. This is when you look in more detail at what you are moving to and how you will get there. Unlike the burning platform approach, you want to transform as you go and only lift and shift to Infrastructure as a Service (IaaS) as a last resort. Ask yourself, Is there a Software as a Service (SaaS) option available that will meet my needs? For instance, on-premises messaging, home drives, intranet sites and the like are prime candidates for Office 365. CRM and Accounting are two other workloads that have plenty of SaaS options available. But if SaaS is not a suitable alternative, can it be moved to Platform as a Service (PaaS)? Databases and web servers are prime candidates to move to PaaS.
If you do end up moving to IaaS, look for opportunities to optimise or automate to minimise operational costs. An investment in automation here will pay dividends down the line.
After the first wave, stop for a checkpoint as the world has changed. Review the strategic decisions to make sure that they are still valid. Are there any learnings from the first wave that we need to take into account? Also look at the prioritisation for the remaining projects. Have any priorities changed? Anything to add?
Rinse and repeat
Now is the time to plan out and execute the next project or wave. Execute, reassess, plan.
Looking at this process you might be thinking the process will never end. There will always be new business requirements and priorities to address. But that should not be too much of a concern. Once the major transformation activities have been completed the same process is used to maintain and evolve your environment – but the rate of change is much lower. It’s also true that in the on-premises deployment paradigm there was a similar never ending stream of upgrades.
Hopefully this series has provided you with some food for thought some insight into how your own journey to the cloud will shape up. As always if you would like to know more, feel free to join the conversation via the comments (below), Twitter or LinkedIn.