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

DevOpsGroup Blog Cloud migration: 5 common traps & how to avoid them

Cloud migration: 5 common traps & how to avoid them

For most organisations, migrating to the cloud happens in four broad phases.

There’s the opportunistic phase: skunkworks projects and new systems start to use public cloud, with or without the blessing of corporate IT. Next there’s the cloud-first stage. Early cloud projects are performing well, so new ones are deployed there as a matter of course and a cloud strategy emerges. Before you know it, your organisation is heading towards the ‘all-in’ phase where the bulk of the IT estate is migrated to the cloud and datacentres are closed. Then comes the cloud-native chapter, when applications are refined to ensure they exact maximum benefits from the environment.

It all sounds so simple. But so much can go wrong. Especially when heading towards that all-in, large-scale migration.

With early cloud projects, teams have the luxury of time to explore new approaches and implement best practice. This can rarely be maintained in the throes of a deadline-driven migration of the entire estate. But, in our experience, many organisations strive for the impossible because they underestimate how much change will be required. They declare themselves ‘all-in’ too early or invest too much time and energy preparing for the migration without getting anything moved. This can have significant financial repercussions. Suddenly datacentre closure looms, with a very real possibility of overrun extending the ‘migration bubble’ of dual running costs. Or once in the cloud, deriving the expected benefits becomes much harder than was anticipated.

Four phases of cloud adoption
Four phases of Cloud adoption

Here’s how to avoid five of the most common factors that can undermine cloud migration success:

1. The never-ending rewrites

In an ideal world, you’d rewrite every application destined for the cloud. It’s the surest way to embrace all those qualities that make the environment so attractive. But you have to be pragmatic. Rewrites take a long time, and you need to compromise if you’re going to complete on schedule.

There are many schools of thought about the best way to approach this. But arguably, if your migration is handled well, and has smart objectives for the short, medium and long term, you can avoid extensive rewrites during the move. A core benefit of cloud-based platforms is the capacity for continual improvement and ongoing modernisation. So, move applications in a format that’s conducive to future work, and come back to them once the migration is complete.    

2. The mindless lift and shift

Lift and shift, referred to as ‘rehosting’ by AWS and Gartner, echoes the automated VMWare migrations of the late 2000s. It’s the quickest and easiest route to the cloud. But it also replicates legacy headaches and you will severely constrain the benefits of migrating if you simply recreate hundreds or thousands of snowflake VMs in someone else’s datacentre. What’s more, once you’re in the cloud, running costs will almost certainly work out higher. You can do a lot to manage this with rightsizing and reserved instances, but then you’ve lost much of the flexibility you came for.

Putting all of that to one side, there are times when lift and shift is the best course of action – providing it doesn’t equate to ‘move it and leave it’. Before an application is migrated, decide how and when you will modernise it after the move. Take a mindful approach and ensure there’s a strategy in place to maximise the benefits of being in the cloud sooner rather than later. 

3. The analysis-paralysis trap

While some level of preparation is critical, there’s risk attached to over-planning. Fear of getting it wrong can (and very frequently does) result in analysis-paralysis. Your portfolio discovery process should take a matter of weeks, not months. Otherwise, plans risk being dated by the time you start and redundant before you finish. 

To avoid this, develop a straightforward set of criteria aligned with specific business requirements, then rank each application in terms of its value and complexity. From here, you can establish a priority order and decide which migratory approach is best suited to each application. And then get started. The best way to address the unknowns is to start moving workload.

Here at DevOpsGroup, we’ve rationalised the various possible routes to the cloud into three simple paths – you can read about them here.

4. High-value apps and high-profile failures

It’s tempting to put applications with the most to gain from cloud at the top of the mass-migration worklist. But this is a high-risk strategy as those applications tend to be old and complicated. It’s far more prudent to hone team capabilities and build confidence on less critical areas first. Prioritise applications that will be relatively simple to move but have the potential to deliver tangible benefits soon afterwards.

This approach facilitates quick wins, creating a positive and progressive environment where teams feel energised and empowered. Work iteratively, moving from one application to another with similar characteristics. In this way, recent learnings are reinforced and skills are gradually taken to the next level. When you turn your attention to the more complex, high-risk migrations, they’ll seem a lot less difficult and risky. A methodical approach gathering momentum over time is the surest route to success.

5. The legacy ways of working

The 2018 Accelerate: State of DevOps report showed a clear link between the National Institute of Standards and Technology’s five essential characteristics of cloud computing and IT’s highest performing teams. Yet, despite the capabilities of today’s hyperscale cloud providers, many organisations are so shackled by legacy ways of working that they fail to embrace them.

On-demand self-service is a classic example of a feature that can be blocked by well-intentioned infrastructure and operations teams. They’re accountable for spend, tooling and standards, but lack the means to govern them in a self-service model. This is a complex issue, but it can be addressed if measures are put in place during or soon after cloud migration. Organisations acknowledging that cloud migration requires more than just technical re-platforming, and tackling cultural barriers, are in a stronger position to realise tangible commercial benefits. 

How to avoid cloud migration failure

If one or more of the above scenarios sounds painfully familiar, you’re not alone. We’ve stepped in to support many established enterprises and experienced teams who found their cloud migration was going awry. Even the most robust and talented teams are put to the test by the scale and complexity of a full cloud migration.

There’s no single fail-safe route to the cloud. But the methods deployed to move your estate have a direct bearing on future success. With care and consideration, you can devise the most effective route for your own organisation’s circumstances and goals.

We’ve developed a free whitepaper to help you rationalise the options and give your large-scale cloud migration the best chance of success. You can download it here: Supercharge your cloud migration with DevOps

Can Cloud and DevOps adoption accelerate growth? Why not download this whitepaper to see how it can help.

Leave a Reply

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