The cloud-race is in full swing, and analysts expect it to continue for the foreseeable future. In fact, Gartner predicts that the cloud services industry will grow exponentially though 2022 to exceed $332bn.
Modern, cloud-based systems are a critical enabler for businesses in the digital economy. But it’s important not to get swept along with the tide. You need to ensure your cloud adoption plan acknowledges existing circumstances and works towards specific goals.
Cloud migration – moving application workloads to the cloud – is just one aspect of the journey. Cloud adoption is much more complex. It involves the people and processes behind the business, many of which sit outside or extend beyond enterprise IT. So, cloud adoption encompasses more than technical replatforming. Unless it’s handled with care and expertise, it’s easy to find that costs spiral up, deadlines get missed and performance benefits are delayed.
The cloud adoption frameworks published by Microsoft and AWS provide valuable insights and guidance to help shape your strategy. To get the most from these, it’s useful to understand your current position on the cloud adoption spectrum. It enables you to define what you want from your next move, and ensure every step gets you closer to long-term aspirations.
The four phases of cloud adoption
Our experience indicates that there are four broad phases of enterprise cloud adoption. There can be an element of overlap and interplay between them and, in the end, there is no single clear path that works for every organisation. But it helps to consider these phases individually as each has defining features, challenges and some useful guiding principles:
Phase 1: Opportunistic
In today’s environment, it nearly always makes sense to build new applications in the cloud, even if the bulk of your IT estate is still firmly rooted on-premise. Many of the organisations we work with are first compelled to dabble with cloud infrastructures when they commission a new project.
Teams seize the opportunity and typically have a go at leveraging modern ways of working, such as implementing infrastructure as code. The resultant applications are generally cloud-native to a certain extent. They might not be perfect, and the process may take some time, but lots of valuable learnings are gained. This scenario is often repeated several times, with team capabilities and performance improving iteratively with each project.
Dev and test environments are often moved to the cloud during this phase too, since they’re perceived as relatively low risk. There are many benefits to this. It relieves constraints in the software delivery process and learnings will support future cloud migration and development.
Phase 2: Cloud-first
Once you have a few production services live in the cloud, confidence and expectations increase. At some point, you decide the time is right to pronounce that all new projects will be deployed on cloud as a matter of course. This declaration marks the start of your ‘cloud-first’ phase.
Now is the time to develop a clear strategy to underpin decisions relating to provider choice, multi-cloud use, data governance and other critical factors. It’s also important to make foundational investments that will support ongoing growth in your cloud-based infrastructure.
Establishing a Cloud Centre of Excellence (CCoE) to lead the adoption of cloud is widely regarded as best practice (although I’d urge you to call it something less elitist!). There is disagreement between industry heavyweights on whether this should be a pure architectural function or something that is either more hands-on or multidisciplinary (involving business owners, finance, compliance etc). But let’s not split hairs. Evidence suggests that any structure is better than not having a CCoE, so consider the options and assess what will be most effective in your business.
Invest in training your people too. You may be able to hire-in key roles, but it’s not realistic to rip and replace the entire workforce. It’s much better to take people on the journey with you. Your cloud-first strategy should be linked to clear plans for skills development and change management. Don’t underestimate the scale of change required, or the importance of winning hearts and minds. Showing a willingness to invest in people’s careers will help develop the trust you’ll need from your teams.
During the cloud-first phase you’ll develop an increasingly firm set of engineering principles about how applications should be deployed on the cloud. This is good. But it’s important to realise that these principles are likely to come under threat during the ‘all-in’ third phase. Rather than expecting cloud-first to form a blueprint for all-in, it’s more appropriate to consider it as groundwork.
Phase 3: All-in
Sooner or later, your business reaches a tipping point where a wholesale datacentre-exit plan is justified and a large-scale cloud migration becomes inevitable. Typically, this is catalysed by a datacentre contract renewal or hardware refresh cycles. Whatever it is, it triggers the decision to relocate all (or at least a significant majority) of your IT estate to the cloud.
This phase often overlaps, or closely dovetails, with the cloud-first phase. Learnings gained from earlier migrations or building new applications in the cloud inform the business case for all-in, large-scale migration. They can be leveraged to determine the level of contingency required and to set realistic expectations surrounding efficiency gains and other benefits.
Whether you’re feeling energised or overwhelmed at the prospect of going all-in, the advice is the same: take things one step at a time. With most deadline-driven large-scale migrations, you need to take a ‘done is better than perfect’ stance for at least some of the estate. That’s fine, because modernisation of applications and the operating model should be an ongoing process. It’s about figuring out the best approach for your own needs and circumstances.
Phase 4: Cloud-native
You can’t move to the cloud and call it a day, not if you want to get the most out of the transition. Modern cloud infrastructures are built to facilitate continual improvement, which means work is ongoing.
Expense management often comes to the fore at this stage. RightScale’s 2019 State of the Cloud Report from Flexera showed that cost optimisation was the top concern of cloud users for the third year running. However, according to the report, users are not doing enough to optimise costs and wastage is often underestimated. Flexera has measured wastage at 35% of spend for 2019, whereas survey respondents estimated that it was 27% on average.
Clearly, expense management is a widespread challenge. Acknowledging this and planning for it with effective tagging implemented during earlier stages will hold you in good stead here.
Once your first systems are in the cloud, take a deeper look at business needs to understand where fully cloud-native applications could deliver better cost and performance profiles. Some of the more complex, big-ticket processes like continuous integration and continuous delivery (CI/CD) and microservices come into play here. They can take automation and agility to a higher level, but they also bring their own challenges which need to be anticipated and managed. You’ll be learning all the time, so apply your team’s skills and experience to more complex applications after they’ve been honed on simpler jobs.
Don’t get swept along
For many businesses, the transition to the third phase of all-in cloud migration is a precarious moment. It often merges with the cloud-first phase, and without the foundational investments and learnings in place, many businesses end up stalling in some sort of paralysis trap.
If you’re somewhere between cloud-first and all-in, take a step back to look at the bigger picture and plan your next steps. There’s more than one way to get to the cloud, and most organisations benefit from a blend of different approaches.
We’ve written a series of blogs on enterprise cloud adoption and migration. The following might give you some inspiration:
Or you can contact us on firstname.lastname@example.org if you’d like some specific advice for your own circumstances.