Lift and shift cloud migrations are often the most pragmatic way to move to the cloud. While they are the simplest approach to cloud migrations, they do usually require significant advance planning in order to be successful.
The basics of lift and shift cloud migrations
The basic idea behind lift and shift cloud migrations is that you literally create an exact replica of your existing on-premises infrastructure. This means that you absolutely must create a full and accurate map of what you already have, down to the last dependency. In particular, you need to look at all the connections in and out of the application and its data.
In a true “lift and shift” migration, all coding (and data) will be lifted into the public cloud exactly “as is”, but if you want to push a point, you could also look to include applications which require only minor adjustment to work in the cloud, although technically this would be refactoring rather than a genuine lift and shift approach.
It is impossible to overstate the importance of backups
In all probability, if you have put in the necessary advance planning, then your lift and shift cloud migration will go without a hitch. If it doesn’t, however, then back-ups may save you a lot of blood, sweat and tears, not to mention overtime hours. In addition to backing up your databases, back-up your support files as well.
Containerization is often the way to go
Containers are basically virtualized operating systems and they have all kinds of benefits. Whole articles could be written about just why they’re so great, but in terms of the lift and shift approach to cloud migration, the key point to note is that they make it straightforward to test your software configuration in the cloud before you actually deploy it into production.
Thorough testing is as important as backups
Even if everything looks like it has gone perfectly, test it thoroughly. In a worst-case scenario having to roll back your cloud migration is still probably going to be a whole lot less hassle than waiting for an issue to start impacting your production environment, especially if it is the sort of issue which could be noticed externally and/or which could get you into trouble with regulators. Remember that the fact that an existing application runs perfectly on virtual machines hosted on-premise does not totally guarantee that it will work when you switch to cloud computing at least not at first.
Pro tip – resist the temptation to add in any new features as part of the migration. This is the complete opposite of the lift and shift approach. The whole idea behind the strategy is that you take something which you know is already working and just move it, as is, to the public cloud. You then test to confirm that it is still working. If you add new features, you are basically setting yourself up to have to deal with a situation when you need to do hours and hours of work just to figure out whether an issue relates to the migration itself or to bugs in your new code.
Triple-check you have met all legal requirements
These days most companies have to abide by stringent data-protection requirements and many have to abide by other legal requirements as well. Before you retire your old systems, triple-check that you are still in the clear for all of these. It would be rather ironic if all the cost savings made by using cloud computing were to be completely outweighed by and entirely-avoidable regulatory breach.
The real work usually starts after lift and shift cloud migrations
Lift and shift cloud migrations move your workload to the cloud, but that’s basically it. In some cases, that will be all you can do, at least in the short term. If your company has been in existence for some time and has had bespoke applications created, then there’s a good chance that some of them will be poorly documented and/or close to impossible to reverse engineer. In such cases, the most pragmatic approach can be to work in the cloud so you get the full advantage of all of the cost savings it can offer (not to mention its general flexibility) and then create a new, cloud-native, application which replicates the functionality, but applies modern standards (and is appropriately documented).
In many cases, however, existing applications can be successfully adapted so that they effectively become “cloud-native” and hence can really maximize the cost savings which cloud computing has to offer. This isn’t necessarily easy, although there are often some “quick wins” to be had, such as adapting existing applications to auto-scale instead of using a single server, but it can make a massive difference not just to your cost efficiencies but also to your overall productivity.