Unpacking the 6 cloud migration strategies

We’re breaking down the migration journey into 6 migration strategies so you can make the move to the cloud with ease

Your business is planning to migrate applications and services into the cloud, but you’re still unsure of what the steps should be, and what all each step requires. In this series, we’re breaking down the migration journey to make moving to the cloud even easier than it already is.

Having looked at security, tooling and necessary compliance you need to consider before migrating in the first article of this series, this piece dives into the six different migration strategies available, putting you in the position to begin planning your architecture.

Before anything else, the first step is to understand everything you have running in your current environment, and what the dependencies are. Armed with this information, you’re in a better position to decide what you should migrate first, and then work on how you’ll do the moving.

Portfolio discovery and planning

Jaco Venter, head of our cloud management team recommends leveraging a tool that can assess your environment and discover the various servers and applications currently running. Some of these tools will show you what resources are presently allocated and how they are being utilised.

Venter says that “when planning to migrate, this information will be vital as you would want to make sure that you move your applications in an optimised state”. He goes on to explain that it’s important to remember that the cloud allows you to deploy only what you need and then increase your resources when you identify additional demand or if your applications requirements change.

“Amazon Web Services (AWS) has a couple of great (and free) tools that can be used to help you understand what you currently have running, and these tools will also often show you what your recommended sizing is as well.”

By using this discovery process as an opportunity to identify what workloads would be easier to migrate and which would have a higher level of complexity, you’re putting yourself one step ahead of your plans from the start. If this is your first migration to the cloud, Venter suggests finding a non-business critical application in your environment that is ‘cloud-ready’, or in other words, “Don’t start by migrating your monolithic accounting system (yet!)”. Starting small or with easier workloads, will help you learn how to migrate while ensuring there is minimal impact to your users.

Some of the key questions to ask during your discovery phase:

• What servers do I have running?
• What applications do I have running?
• What databases do I have running?
• What are my storage requirements?
• Does my connectivity consistently allow for reliable access to cloud services?
• What licensing do I currently have in place?
• You will also need to understand if these licenses can be used on the cloud provider you ultimately choose

The 6 migration strategies

Developing your migration plan means understanding and planning how you and your migration team will handle each application throughout your migration journey. Essentially this means shifting your focus from a portfolio level to an individual application level, and why the discovery phase is so crucial as an initial step. Venter says that as a migration partner, we typically start with a table listing each running application, linking it to one of the six migration strategy “R’s”. This in turn then dictates the relevant architecture needed, as well as what you’re going to do with each application – resulting in an overall smoother process.

Rehost— otherwise known as “lift-and-shift”

When you rehost, you are essentially moving applications into the cloud without making any changes to them. It is the equivalent of carefully lifting your application and shifting it into the cloud. This is often a go-to strategy when you’re looking to quickly meet business objectives because it can be simpler to optimise and re-architect once an application is already in the cloud, mostly because the difficult part – the actual migration of the application, data and traffic – has already been done.  

Because they can be the quickest option to test functionality for a business, we often find that many early cloud projects either gravitate toward rehosting existing services or deploying net new workloads as their initial go-to cloud strategy. And although most rehosting can be automated with tools these days, it’s not always the best choice for your situation.

Replatform — also known as “lift-tinker-and-shift”

Replatforming is when you make a few cloud (or other) optimisations in order to achieve some tangible benefit, but you aren’t otherwise changing the core architecture of the application you’re looking to migrate.

Examples of some relevant “tinkering” include reducing the amount of time you spend managing database instances by migrating to a database-as-a-service platform like Amazon Relational Database Service (Amazon RDS), or migrating your application to a fully managed platform such as Amazon Elastic Beanstalk.

This is often one of the options we prefer when helping clients plan for their migrations as it results in improvement in performance, resiliency and operational costs.

Repurchase 

The third migration strategy involves moving a legacy system from a perpetual licence to a SaaS (Software as a Service) model that provides similar capabilities. Replacing your outdated on-premise software allows you to quickly migrate live data with little effort, and moves you away from needing to manage installed applications. If you’re looking to swap products or vendors for these services, this is an ideal opportunity.

An example of a repurchasing strategy would be to move from hosting your own email service to leveraging a product such as Microsoft 365.

Refactor / Re-architect

Rearchitecting is a strategy that allows you to re-imagine how an application is architected and developed using cloud-native features. This is typically driven by a strong business need to add features, scale, or improve performance that would otherwise be difficult to achieve with the application’s current architecture.

This strategy would see you moving from a monolithic to a micro-service oriented and server-less architecture to boost agility and improve business continuity. “This strategy tends to be the most expensive, but it is often the most rewarding as it could considerably decrease operational costs” notes Venter.   

For a more in-depth look at such a migration strategy and the benefits you could gain from cloud native development, read more here.

Retire

The best strategy often involves cutting the fat and rather focussing on what drives value for your business. After completing the discovery phase in your environment, it’s advisable to ask each functional area who owns each application. AWS is quoted as “Finding as much as 10 – 20% of an enterprise’s IT portfolio is no longer useful and can simply be turned off”. This allows the organisation to reduce the overall complexity of the system, it’s running costs and future maintenance.

Retain

Maybe you’re still riding out some depreciation, you aren’t ready to prioritise an application that was recently upgraded or are otherwise not inclined to migrate some of the applications in your environment. When this is the case, a workable strategy is to retain the situation as is, for now.

One of the biggest reasons companies opt to retain a specific application is due to the technical debt associated with a recent investment into that application. At this point, it wouldn’t make sense to move that application to the cloud, but that shouldn’t stop you from moving others while you sweat the new onsite hardware, networking or licensing you invested in.

Once you’ve completed the discovery phase, and have a completed table listing all applications and the associated migration strategy, it’s time to start designing your cloud architecture. This next step means understanding what you will be migrating, how you will be managing them during the migration, and most importantly, which services you’ll require to make it all happen. Having a trusted cloud partner can make the next stage a lot less daunting.

Remember, in the month or so after you’ve completed your migration, it really helps to monitor performance as you’ll find that more often than not your new cloud environment will outperform your planned resource requirements. This means you may not need as many resources as originally anticipated, making room for additional optimisation opportunities which result in further cost savings on top of the scalability, resilience and agility benefits you may have already reaped.

As part of the AWS Migration Capability Program, our migration strategies and processes have been validated by AWS, giving you confidence in our ability to swiftly bring your business the benefits cloud has to offer. If you’ve made the decision to migrate and are looking for a cloud enablement partner to guide you through devising a relevant strategy, implementing the migration, and optimising as your business grows – reach out to us.