I’ve been in and around cloud migrations for a number of years, both from the side of the service provider but also as a direct consumer of cloud, building out a Cloud Centre of Excellence, planning application migrations and eventually migrating those workloads to cloud.
Across all industries companies are investing millions of pounds and euros planning and migrating to the public cloud, but in many cases the programme of work takes far longer than expected and a large percentage of workloads end up being left as-is, or migrated above the anticipated cost.
What Does Good Look Like?
For me an overall cloud migration programme looks something like diagram 1 below, starting slow during the early days of business case and Proof of Concept/Proof of Value, and accelerating to maximum velocity as you hit the mass migration phase (represented by the grey bar).
Diagram 1 – Example cloud adoption curve over time
In a stalling migration programme however, you can see that the ideal velocity is never reached, and instead of a rapid period of mass migration it’s a much slower journey (represented by the dotted blue line). Before I go through my thoughts on how to avoid this great stall from happening, broadly I believe the underlying reasons that slow velocity can be to bundled in to 3 main areas:
- Issues with the fundamental migrations strategy that’s forged in the early days of planning
- Issues with overall organisation structure and the cloud Target Operating Model used once a workload has been moved
- A lack of stakeholder support and buy-in
Cloud Migrations Strategy
Assessing and planning and your cloud migration is extremely important step early on in the adoption journey, and must be well informed with the right insights in order to achieve success.
A good Cloud Readiness Assessment (CRA) assessment will be a cornerstone of building the migration plan, but I often see the CRA being flawed in its scope, or by the skills of the person/people running it. For me a CRA is more than a re-skinned capacity assessment and takes in to account the wider business drivers around criticality, security, compliance, scalability etc. etc. A CRA should also include an assessment of licensing is informed of the wider projects and initiatives – so its recommendations align to the longer term view rather than a shorter term ‘win’
Once a workload is assessed the migration type is then important, with most using the Gartner 7 R’s to identify how a workload will be moved. Rehost (often otherwise known as ‘lift & shift’) is an approach still regularly used, but in my experience it rarely aligns with business goals nor delivers the benefits that public cloud promises. It is easy to see why lift & shift is a go-to migration type as it potentially delivers quick cost savings with the least addition of investment in changing code, and also creates the least amount competing goals for the applications owners themselves. The challenge with this method however, is that it typically a 1-to-1 translation of the on-premise workload to the cloud platform, and in that instance is often highly unoptimized and ill-prepared to take advantage of the elasticity and scalability the new platform can offer.
Related to the migration type chosen, in the past I have seen stakeholders with unrealistic expectations on the return on investment (ROI) for a workload to be moved, often with the miss-understanding that “cloud is cheaper”. For stalling cloud migrations it is not uncommon to see ROI horizons either being set too short (under 3 years), or not taking in to account the value of alternate benefits such as speed of innovation for future projects, reduction of risk, unlocking of future capability
How to Get Back on Track
In this area I would recommend any organisation stalling on their cloud migration do the following:
- Re-investigate alternate migration approaches – invest the time and energy to look at app modernisation
- Revisit & re-prioritise desired downstream benefits detailed in the business case
- Evolve and learn from CRA mistakes. Re-run with lessons learnt
- Invest time in cloud framework (CAF) development – standardise deployment portfolio
Organisation Structure & Target Operating Model
Many organisations still see cloud as a different platform/set of technologies rather than an entirely different way of managing your IT, and therefore see cloud migrations as a technical project rather than as a business change. For any organisation to make a success of mass-adoption of cloud it must evolve its structure and challenge the current thinking in terms of functional layout, governance, standards, and processes. When I look at a stalling cloud migration, often the signs that the structure and operating model are a contributor are:
- There is a growing lack of efficiency, with existing teams spending are more time keeping the lights on, not less.
- Existing toolsets and ways of working have issues. There are gaps appearing and multiple, isolated ‘standards’ emerge with different teams deciding on different tools and management practices.
- Costs are ahead of projected levels, with a lack of clarity on why this is the case
- Staff attrition rates have increased, and there are higher costs than budgeted for to hire, train & retain top talent.
How to Get Back On Track
In this area I would recommend:
- Audit your cloud management structure – consider dedicated roles in a Cloud Centre of Excellence to establish think different, do different
- Invest in growing skills inhouse. I believe in investing and growing from within, and although you may need to bring in external talent to think different and do different, you should always invest in your own people and reward their loyalty and hard work. Training budgets & test/dev budgets will need to be increased to enable your teams to stay abreast of the rapid change in cloud.
- Establish a single set of cloud management standards and aligned toolsets. Common and inefficient management tasks need time ahead of mass-adoption to be Codified till repeatable.
- Establish cost governance cycles – develop additional reports to analyse and allocate spend, so you have complete clarity on who is spending what, on what, and how it related to the original budget.
Stakeholder Support and Buy-In
With any large programme work, typically spanning weeks if not months, the teams involved need their leaders to understand why the move is happening, what the drivers were in the first place, and are laser focused on success. What is very common when I have leant in on stalled migrations in the past is the feeling of a tangible disconnect between the front line teams involved in the migration, and the leadership levels above.
During cloud migrations a strong communications plan is often overlooked and under-valued. Front line Engineers need to be ready to execute with the understanding of the top level ‘why’ and desired state. With this information all layers from front line to middle management can flag issues and recommend how to correct course should momentum slow. At the same time top level stakeholders recognise the role all the teams have in make the migration a success, and have working feedback loops that trigger to flag issues early on.
I always recommend that a well invested business case is the strongest tool any company has to guide in a large programme of work. A strong business case, laying out the drivers, challenges, expected benefits and risks, should be in place at the start of the migration and transparently communicated to all teams involved. Once a cloud migration is underway, the business case should be revisited and re-communicated at each major milestone. It is also key that the business case identify the true measures of success, beyond simple cost savings, and that these measures are reported upon and played back across the business.
How to Get Back On Track
In this area I would recommend:
- Revisit and refine your business case – re-visit drivers and objectives. Prioritise according to business strategy
- Grow your steering committee with representatives from the wider teams
- Showcase success during early lighthouse migrations and at each major milestone
- Establish and report relevant KPIs attached to business case driver
Summary
Hitting the great stall in a large scale migration project does happen, and you won’t be the first organisation to do so. Most stalls occur in the early days of the overall progamme of works, and identifying why momentum is being lost is key to getting back on track.
Advanced has a long history in enabling and accelerating migrations, so if you have read the above and think you need help, please do not hesitate to give us a call.
