According to Gartner, end-user expenditure on public cloud services is projected to reach nearly $600 billion in 2023. Cloud migration is all the rage among companies, thanks to on-premises environments that are increasingly expensive to maintain and undermine the power of the software they host.
There are multiple ways to get your applications on the cloud and consequently reap the benefits of such remote hosting. The strategies all vary in the extent to which your services are modified through refactoring or re-platforming to be compatible with the cloud environment. Of these, lift and shift is the most straightforward approach, given that all or most of your software is already cloud-ready.
Lift and shift is used when you want to move your resources to the cloud as soon as possible or during a data center shutdown procedure. During this type of digital transformation, if your software and services are not cloud-ready, you should plan the optimization later.
In this article, we dive deep into lift and shift and related best practices to successfully migrate your on-premises services to the cloud infrastructure.
Understanding lift and shift
Lift and shift is a specific type of cloud migration strategy that requires you to take your on-premises infrastructure and move it to the cloud without any changes to the code. It utilizes the IaaS migration model and is also called rehosting, as the underlying technology or type of configuration remains the same but is merely hosted in a different place. Because you are uploading the exact copy of the existing services and application codes, there are massive cost savings. This is also a faster process than if you are refactoring your existing applications for the cloud. However, your on-premises infrastructure needs to already be cloud-ready for this method to work, and you need to plan optimization after the migration. If this is not the case, the software is unlikely to function properly once migrated and might create latency issues.
When cloud computing was still a novelty, all applications but the most complex ones were lifted and shifted to the cloud as-is. A complicated architecture would likely need to be modified to work efficiently and be compatible with the cloud. With the evolution of cloud-related tools and practices, cloud platforms have become more accessible. Even though re-architecting your software to be cloud-native may involve more effort than a simple lift and shift cloud migration strategy, the flattening of the learning curve has contributed to the decreasing popularity of rehosting as a viable choice within a cloud journey. This is because even if an infrastructure is already compatible with the cloud, unless it is modified, it may not be in the position to make use of all the facilities that the cloud service provides.
The benefits of rehosting
Speed, effort, and cost: Due to the lack of effort required compared to other migration strategies, it is both a faster and more cost-effective process. It also requires less manpower, and there are no costs associated with purchasing any hardware as you pay-as-you-go to the cloud service provider.
Scalability: The pricing model and no need to buy hardware make it easier to scale your software as and when required by increasing capacity or storage.
Flexibility: In addition to scaling up the cloud resources your services use, you can also scale down your IT operations to meet lower demand on some occasions.
Performance: Oftentimes, the hardware on-premises is obsolete and therefore inefficient or unreliable. In comparison, the popular cloud platforms offer computing resources that enable your software to improve performance.
Hybrid management: Certain services may require re-architecture before they can be moved to the cloud. Others may only be able to function on legacy hardware. In either case, you can continue to run some services on your existing physical hardware and shift others to the cloud. The evolution of cloud computing has birthed tools that allow you to manage apps across different spaces together.
Downtime: During the process of rehosting, your on-premises infrastructure can continue to run, ensuring that the end user's experience is not impacted.
When to do it
Its decreased popularity does not eclipse the value that lift and shift continues to hold in a variety of use cases, such as:
Containerized services and applications built using microservices are cloud-compatible to a certain degree, making them suitable candidates for a lift and shift migration process.
Lift and shift can be the first step in a longer strategy. The aim would be to get the actual exportation out of the way so that you can re-architect the software later on in the cloud itself. Here, cloud compatibility is not a barrier to migration. One contributing factor to this situation can be the high costs associated with running your applications on-site. Keep in mind, however, that you will be paying as you go when you migrate to the cloud. This can get expensive if you are temporarily migrating resource-heavy workloads or applications.
Mass-produced, ready-to-use software that is part of your infrastructure, but cannot be re-architected as it was not built by your team.
Lift and shift is a popular option for executing backup and recovery processes. It can function as a highly available alternative site for disaster recovery. Not only is it cheaper, but also scalable, which is necessary as time progresses and your database expands.
Note that if an application cannot function independently in your on-premises environment, it is unlikely that shifting it to the cloud architecture as-is will change that.
How to do it
Lift and shift is a fairly straightforward approach to exporting your on-premises applications to the cloud. The first step is to take account of all your services. Look at your inventory and decide if you need to retain any of it in your on-premises environment or get rid of something entirely. Of the ones you choose to move to the cloud, it is good practice to assign each of them a priority level so that they can continue to work together effectively once migrated. This is the classification process, which sets a baseline that will inform your next steps.
Your team may be comfortable taking a piecemeal approach to the migration. You might, for example, move your entire internal infrastructure to Kubernetes and then to an auto-managed Kubernetes environment. If this is not the best approach for you, you might benefit from containerizing the services first and then moving them to the cloud. Some vendors might impose legal or technical restrictions while moving your workloads to different service stacks, called a vendor lock-in which you must be careful to avoid. Or, you may already be in the position to export everything together. Even though a lift and shift approach does not necessitate a large team, it is important to devise a strategy that the developers in charge can effectively carry out.
Often, tinkering and experimenting with the new cloud technologies is a powerful way to ease into the exportation process. Most teams are not familiar with them, making migration seem daunting. We recommend taking a small, simple service and seeing if it works on the cloud. You can try different tools and approaches to acquaint yourself with the cloud. Many cloud providers offer automation tools that are worth looking into, as these are designed to make your development processes even faster. Such experimentation, even if at a small cost, is ultimately beneficial as your team gains confidence to move other services to the cloud.
Choosing your cloud environment
For a successful lift and shift, you must carefully consider all the cloud environment options available to you. The primary requirement is a cloud that has tools which are most representative of your current on-premises environment. That being said, be careful not to get carried away by all the features and tools that are at your disposal on the cloud. Some may not be relevant to the needs of your software. Having a strong vision for your applications and a well-defined scope can go a long way in focusing your efforts.
Take some time to consider the differences between your current environment and your cloud environment. For instance, your on-premises Kubernetes cluster could be using a particular type of API gateway or service mesh that may not be available in the cloud environment. Perhaps you would like to use AWS or Azure virtual machine as a load balancer, but at present, you are using an open-source load balancer on-premises. By identifying and keeping in mind the differences between those two workload balancers, you will be better positioned to envision and map out your migration path.
Adopting best practices
Once you have decided which services you want to shift over to the cloud, here are some key things to consider as part of your cloud migration strategy.
Long-term vision: In addition to avoiding temptation with regards to cloud features, having a migration plan and goals for the long-term also provides clarity on the lifespan of your applications. Before moving everything over to the cloud, it’s worth considering whether you are likely to continue using these services.
Compliance: Cloud compatibility, as mentioned before, is of utmost importance in a lift and shift migration approach. This includes compliance requirements, which your applications must adhere to during migration and after it.
API tools: Similarly, the cloud environment should be such that it does not pose any issues for your existing API tools. There is no room for re-architecting in a simple lift and shift, so your APIs must be accounted for.
New services: Another aspect of thinking long-term is planning for the new services you build after rehosting your current services. The path for those services may look different than what you have already built. If they are to go on the cloud, will they be exported to it eventually or hosted there from the beginning? They will have to be built in a cloud-ready way.
Templatization and standardization: Creating templates and establishing standards for microservices can be especially useful to facilitate the process of creating new services. Your developers need not worry about whether they are on the right path. After deciding to build a service for the cloud, they can simply choose the appropriate template and start redesigning their workflow around it to have a cloud-compatible service ready. Developers already have their hands full, and these practices make it easy to both build new services as well as maintain existing ones.
Governance: Keeping track of all the different aspects of your strategy may seem like a mammoth task, but it is essential to ensure a smooth migration to the cloud. It is beneficial not only for leadership but also for developers to be in the know about their current position and understand what they must do to meet their goals. Today, there are a number of programmatic mechanisms and tools available to make governance easier. A few examples of questions that such automation can take care of are:
If you are currently maintaining an on-premises Kubernetes environment, are there new annotations you need to add to your Kubernetes clusters or Kubernetes deployments for them to work on the cloud?
What are the specific security policies that your development and security teams should enable? How can you take account of that?
Visibility: Relatedly, make sure you are reporting on the process. Both leadership and developers need visibility on the migration strategy to be on the same page. Leadership is also in charge of planning the product and the OKRs, so they must be kept in the loop. If they are unaware of the current status of the migration process and the projected path forward, they will be making uninformed decisions that could harm or be at odds with what is going on.
How Scorecards can help
Cortex’s Scorecards allow you to define and enforce standards across your teams with ease. Informing your team about these uniform expectations helps them prepare for the lift and shift process. Using automation to track these standards and your team’s progress towards the goals gives you an accurate idea of your current standing.
Without automated tracking, it is difficult to identify how much of your existing infrastructure is ready to be migrated to the cloud. When everyone in your team has this knowledge, the process of lifting and shifting your software to the cloud becomes much easier.
