DevOpsGroup has joined Sourced, an Amdocs company. Read more about this partnership and what this means for the future in our blog.

DevOpsGroup Blog How to break analysis-paralysis and enable cloud migration

How to break analysis-paralysis and enable cloud migration

Analysis-paralysis is a common problem for largescale cloud migrations. There is always an element of uncertainty surrounding costs, and the performance of the organisation is also at stake. Decision makers often lack the information needed to take the initial leap of faith.

Encouraging new ways of thinking

It’s easy for advocates of cloud computing to talk about cloud as a utility, and the need to switch from CapEx to OpEx financial modelling. But that doesn’t make it easy for CFOs and CTOs to switch to this way of thinking. They generally want to understand the full projected cost of migration before giving it the green light.

However, simply calculating Total Cost of Ownership (TCO) in the cloud based on the number of physical assets that need to be moved rarely gives an accurate – or appealing – picture. Combine this with the need to optimise workloads for the cloud environment and short-term costs become higher still, making decision making even more complex. It’s no wonder so many cloud migration initiatives get stuck in a deadlock.

To overcome this, it helps to take a step back and break largescale cloud migrations down into a series of smaller migrations. This reduces risk and enables various migratory approaches to be tested, proved and costed. It also provides opportunities to upskill inhouse teams so that diminishing levels of external engineering support are required as the migration gathers momentum.

With these smaller migrations, the secret is to do just enough planning and provide just enough information to get things moving. The phased, systematic approach of AWS’ Migration Acceleration Program (MAP) provides an excellent framework to help make this happen.

‘Assess’ and ‘Mobilise’ cloud migration

AWS MAP involves three consecutive stages: ‘assess’, ‘mobilise’ and ‘migrate and modernise’. The methodology evaluates inhouse capabilities and existing environments ahead of migration, and it’s a great way to reduce cost and manage risk. The first two phases are especially valuable in situations where cloud migration decision making has encountered difficulties. They give the C-suite a clearer picture of what will be involved in the migration and what engineering is needed upfront to realise cost savings and wider benefits later.

Assess: An initial Migration Readiness Assessment identifies any areas where the organisation needs additional capabilities to complete a successful migration. This is based on the six dimensions of the AWS Cloud Adoption Framework (business, process, people, platform, operations, security). It underpins a more sophisticated TCO model than a simple formula based on the number of existing servers.

Mobilise: The next phase involves building an operational foundation for the migration, fixing any capability gaps that have been identified. This might be achieved through pilot migrations, building cloud landing zones or the creation of migration blueprints. Clarifying what technical work is needed reduces uncertainty and accelerates decision making.

Together, ‘assess’ and ‘mobilise’ provide critical information and insights about the migration and modernisation of specific workloads. Importantly, they frame this from a business perspective so budget holders and decision makers understand what they’re signing up for.

Building a bridge to the cloud

When cloud migration decision making stalls, an overambitious strategy is often the root cause. There’s nothing wrong with having ambitious goals, but it’s important to be pragmatic about how they will be achieved.

Take serverless computing – the gold standard that many organisations want to achieve in the cloud. If the strategy involves transforming everything at once, the levels of risk will be extremely high. Planning will take ages, decision makers will be nervous, and it’s likely that the project will get stuck in a loop of analysis and reanalysis.

An alternative approach is to look at serverless as a journey with stopping points along the way. Some parts of the architecture might go fully cloud native from the start, others might take advantage of container technologies, and some might undergo a lift and shift with modernisation happening later.

When the process is broken down into discrete stages it’s easier to make a robust and persuasive business case that’s more likely to be approved. It’s about building a bridge to the cloud and modern ways of working while allowing time for reflection and development of skills, confidence and trust. All these factors help ease the decision-making process for future stages of the journey.

Getting better all the time

It’s important to understand that TCO calculations always present a worst-case scenario. Equally, it’s only by investing in people and technical skills upfront that full cost optimisation and cloud performance benefits can be realised later. Together these factors mean that cloud migration will always require a leap of faith. But when it’s deconstructed into manageable stages, there’s not so far to fall.

Colin is a cloud solutions architect at DevOpsGroup and an Amazon Partner Network (APN) Ambassador.

We offer everything from cloud consultancy and hands-on engineering to training, mentoring and coaching for the development of cloud-ready engineers. As an AWS Migration Competency Partner, we conduct the ‘assess’ phase of MAP free of charge as part of our AWS Cloud Migration Assessment.

Leave a Reply

Your email address will not be published. Required fields are marked *