How to Carry Out a Lift and Shift Migration
As we’re looking at one cloud migration strategy in a bit more detail, in this post, we’ll run through the various approaches to cloud migration and where re-hosting fits in. We’ll consider why you might consider a lift and shift migration strategy; and, finally, how to carry out one of these migrations successfully.
Following on from our recent post Replatform vs Rebuild: What To Do With Legacy Applications, we’re looking at one cloud migration strategy in a bit more detail. Re-hosting, or “lift and shift” as its often known, is the first step for many applications on a journey of modernisation.
In this post, we’ll run through the various approaches to cloud migration and where re-hosting fits in; we’ll consider why you might consider a lift and shift migration strategy; and, finally, how to carry out one of these migrations successfully.
Approaches to Cloud Migration
When you make the decision to migrate to the cloud, it’s just the start of a potentially long and complex journey. There are five main approaches you could take when migrating an application. Each has their place and purpose, however, that doesn’t make choosing the right one any more straight forward or any less daunting. The options you have include…
The 5 types of Cloud Migration
Re-hosting or “lift and shift” migration strategy
This is where the application is taken in its entirety from its current infrastructure and moved to the cloud, making no changes to the code. This is the one we’ll be focusing on in this blog.
This is where small changes are needed in the code to be able to move the application. Interested in refactoring? Check out this blog for more on refactoring legacy applications.
If an application isn’t compatible with the cloud for architectural reasons, or you’re looking at migration because of innovation and new features, then you’re going to need to do more than just tweak the code. The application might need to be rearchitected in order for transformation to take place, which is more involved than refactoring.
This is where the code of an application has to be rewritten so it can exist in a cloud environment. If the cost, effort or complexity of getting an application cloud-ready or cloud-native is too great, it could be worth rebuilding it from scratch.
An application is replaced when it can’t run in the cloud and a rebuild isn’t viable. A replacement for the application needs to be identified and deployed. In some cases, a SaaS equivalent could provide all of the necessary functionality of the hosted application without any of the development, management or infrastructure overheads.
Of these, re-hosting, where you lift the code out of an environment and shift it to another, is the most straight-forward. The lift and shift migration strategy requires less time and fewer resources to execute. It is the fastest way to migrate to the cloud because you don’t need to make changes to data or code modifications, however, it still requires careful consideration and planning.
Lift and shift vs. cloud-native
The lift and shift approach is often a company’s first step in their journey to becoming cloud-first. Companies are under increasing pressure to find cost savings and moving to the cloud is one way to achieve this. Lifting an application up wholesale and deploying it in the cloud may not bring all the cloud’s benefits to that application, for example, if the app was designed to run on a single server then it could not take advantage of auto-scaling. However, for many applications, this is not an issue, especially if they have patterns of resource utilisation that can be defined.
The lift and shift approach is great as an interim solution for mission-critical systems and, for the right applications, works well as a longer-term strategy too. However, to use the cloud efficiently, you need to work on modernising the application in order to get the most out of the cloud. This may require redesigning and fundamentally changing the application in order to become cloud-native.
Why lift and shift an application?
After making the decision to move to the cloud, companies usually look to address the quickest wins. Stand-alone applications often make the best candidates to migrate first as they can be most easily lifted and shifted. These have no complex integrations and can be migrated with little downtime.
Lifting and shifting an application is usually the fastest and cheapest method of migration. Speed is sometimes the main driver, as there may be a requirement to move from a data centre or hosting provider.
However, speed and cost aren’t the only benefits: because you are not changing anything about the application, there is also very little risk involved in the migration. It allows you to import configuration and scripts that may not be documented or are hard to reverse-engineer. This is attractive as the skill sets within a company may cover virtualisation and infrastructure but not extend to other migration approaches such as refactoring or rearchitecting.
The process of lifting and shifting an application is often made easier by providers who supply tools that can help migrate an application, allowing the migration itself to be carried out by migration experts and even automated, resulting in limited or even no downtime.
Lifting and shifting is often the first step in making a more complex application cloud-native as it can be easier to rearchitect or rebuild the application once it is running in the cloud. If you’re partnering with an organisation in order to help you modernise your application, the first step might be to have the application running on their cloud platform in its current state, even if the end goal may be to host the app on a public cloud platform.
We’ve said a lift and shift is one of the more simple migrations, but like all IT strategies, it still requires planning. Just because an application runs well on traditional servers or with on-premise virtual machines, it doesn’t guarantee that it will run as well in the cloud.
Cloud Migration Steps: Ensuring a Smooth Transition
- First chose which platform that you wish to migrate to.
- Examine all the connections in and out of the application and its data.
- If you are lifting and shifting more than one application, then you may need to consider automating the multiple migrations.
- You should consider containerisation to replicate the existing software configurations. This will also allow you to test configurations in the cloud before moving to production.
- Back up the databases from the existing system as well as supporting files. When the new database is ready, restore the backups.
- Once migrated, test the application.
- Check that all the current data compliance and regulatory requirements are running in the new cloud deployment. Run your normal validation tests against the newly migrated application.
- Don’t be tempted to introduce new features during the migration. This can lead to many hours of additional testing to make sure you have not created new bugs.
- Retire your old systems once testing is complete.
Finally, we would always advise working with a provider who are experienced in migrating applications. Even if you can carry most of it out yourself, having additional resource in the planning stages, or even on standby during the migration can be worthwhile having. Cloudhelix can help you decide which is the right approach for your migration, provide direction for the future of your application and make sure that this all ties in with your wider cloud strategy.
Considering a lift and shift migration strategy? If you need any assistance with a move to the cloud or want to learn more about modernising applications, talk to us today about our cloud migration and replatforming services.
Our specialists have the answer