What are the Main Cloud Migration Types?

Having enjoyed such positive feedback for our beginner’s guide to cloud migration, we thought now would be a good time to take a closer look at the cloud migration options that are available for your legacy applications.

As a leading multi-cloud vendor for the public sector, we know all too well that there is no one-size-fits-all approach when it comes to the cloud. Rather, public sector organisations must take an application-by-application approach when formulating their wider cloud migration strategy. You see, what works for one application, could be potentially disastrous for another.

We need to remember then, that a digital transformation is a continual process. And whilst you might have a clear idea as to where you want your applications to be, it’s quite possible that it will take several steps to get there.

A digital transformation is a marathon, not a sprint.

There are various pieces of published content online that all discuss the alternative cloud migration strategies that exist. Some claiming that there are five options, others six or even seven – however, the sentiment remains largely the same. For the sake of this blog, we’re going to discuss the various pros and cons for each of the following:

1. Rehost
2. Refactor
3. Rearchitect
4. Rebuild
5. Replace
6. Retire

And remember, should you ever want to discuss any of these options in greater depth, just head on over to our professional services page. Here we’ll be able to put you in touch with one of our multi-cloud experts.

 

1. Rehost

“Redeploy an application component to another physical, virtual or cloud infrastructure without recompiling, altering the application code, or modifying features and functions”

– Gartner, 2020

 

You’ve invested a lot of time, money and resource developing your current application portfolio – so the chances are that many of your enterprise applications are still fit for purpose. It doesn’t make sense to rip up all that IP and start again.

This is where rehosting comes in – or a lift and shift approach as it’s become to be known.

When end-users are largely happy, but application availability could be improved, rehosting your application is a great place to start your cloud migration journey. By moving your applications to an environment that mirror your existing setup – say, from VMware to VMware – the underlying infrastructure will not only benefit from a 21st-century facelift, but you’ll also only pay for what you use.

It may seem like an intermediary step. However, by divorcing yourself from infrastructure, you and your team will have more time to explore new and emerging technologies. Longer-term, this will mean your organisation can look to deliver better services at a lower cost. Helping you to deliver exponential value to UK taxpayers.

 

2. Refactor

“Restructure and reoptimize existing code without changing its external behaviour to remove technical debt and to improve the component’s features and structure”

– Gartner, 2020

 

You’ll find that as you work your way through this blog, each of the cloud migration options slowly become more and more complex. If rehosting an application serves as the base layer, refactoring goes one step further.

You see, when rehosting an application, the application’s code will remain largely untouched. However, when refactoring an application, you’ll need to update a proportion of your application’s code so you can utilize cloud-native features such as autoscaling.

A simple example would be to migrate an application’s database to platform-as-a-service (PaaS). Taking away the dependency on having to manage operating systems and patching databases. However, the rest of the application is likely to remain stable.

It’s also worth noting that whilst this methodology can be extremely cost-effective, it is assumed that your organisation is able to reuse languages and frameworks that they’re already invested in. Refactoring an application is a great way for organisations to dip their toes into the world of cloud-native.

 

3. Rearchitect

“Materially alter the application code so you can shift it to a new application architecture and fully exploit new and better capabilities of the application’s platform.”

– Gartner, 2020

 

As you might expect, rearchitecting an application will require significant changes to an application’s underlying code. Which in doing so, will enable you and your team to deliver to an ever-evolving feature set to your end-users.

Typically, this approach is reserved for high-value, customer-facing applications which would significantly benefit from incorporating a suite of cloud-native features as part of its makeup. As such, your organisation will need to make a long-term commitment to DevOps and agile best practices for this to become a viable option. Infrastructure and development teams will need to be much more aligned – utilizing cloud development best practices such as automated testing and automated deployment.

Whilst this approach will require significant investment upfront, application’s that have been rearchitected will become much more flexible moving forward.

 

 

4. Rebuild

“Rebuild or rewrite the application component from scratch whilst preserving its scope and specifications.”

– Gartner, 2020

 

You guessed it. Rebuilding an application is essentially starting from scratch.

Whilst the application in question might serve a specific need, refactoring and rearchitecting its original codebase might be more effort than it’s worth. In some cases, it’s just easier to start again.

Rebuilding an application will mean a new codebase, new languages, new frameworks, new ways of working. But sometimes it just makes sense. Sure, it might require a significant investment upfront – but don’t be so quick to rule out the potential opportunity cost of getting this wrong. The alternative? A development project which drags as you continually meddle with an existing codebase that doesn’t quite live up to expectations. Costs can quickly spiral if you’re constantly moving the goalposts.

 

5. Replace

“Eliminate the former application component altogether and replace it, taking into account new requirements and needs.”

– Gartner, 2020

 

Why build when you can buy?

As champions of innovation in the public sector – this mantra is very close to our heart. Too many organisations fall into the trap of building new cloud-native applications from the ground up, when a specialist SaaS-enabled solution might already exist.

At UKCloud, we’ve partnered with over 300 organisations who provide specialist solutions for the public sector. By incorporating one of these solutions into your application portfolio – rather than building your own – you’ll benefit from an ever-evolving feature set that enterprise teams rarely have the time to deliver. Shorter-term, you won’t need to make any provisions for any new hardware. That burden is with someone else.

However, remember to conduct a thorough audit before plugging your data into someone else’s solutions. Our data is a national asset. Make sure you put it in the hands of companies that you can trust.

 

6. Retire

Following an application deep-dive, it’s not uncommon to find orphaned applications that are no longer in use. Just ask our professional services team! For applications like these – applications that are diverting potentially useful resource to redundant workloads – it’s a valid strategy to delete them. Get rid and never look back.

 

Like what you’ve read but have a thirst for more?

Join UKCloud’s CTO, Leighton James, and Paul Houghton, a Senior Cloud Consultant from our professional services team – as they discuss the pros and cons of each in further detail.