Is Azure Lift and Shift Right for You?
Azure lift and shift migrations get you into the cloud quickly, but they generally only provide a minimal range of benefits compared to using cloud-native applications. It is, therefore, advisable to consider all your options before choosing your migration method.
The basics of Azure lift and shift
Technically, Azure lift and shift are known as Azure rehosting and both descriptions give a fairly accurate summary of the migration method. Basically, you make an exact copy of your existing on-premises environment and replicate it in a cloud-based platform.
For the sake of completeness and clarity, it is essential that the lift and shift itself is exactly that. In other words, resist the temptation to try to resolve any issues with your migrating applications during the migration itself, no matter how simple the fix might seem. Either resolve issues before you migrate the applications to the cloud or wait until the migration is complete and tests show clearly that it is exactly replicating your existing systems. Then do whatever it is you need to do to deal with the matter.
As you may have guessed from this description, Azure lift and shift migrations are often the best option when you’re fairly happy with what you have already and just want to migrate to the cloud for the business benefits it offers, especially the potential for quick, easy, cost savings. Sometimes a lift and shift migration may be all you need to do, but a lot of the time, it’s just the start of a journey of improvement toward cloud-native architecture.
Azure lift and shift versus refactoring
Refactoring is sometimes known as repackaging, possibly because it often involves the use of containers, which are essentially virtualized operating systems which can be stacked, one on top of the other, on a virtual machine. You also have the option to use infrastructure as a service (IaaS) and platform as a service (PaaS) products.
Refactoring basically means changing the design of an application but making few, if any, changes to the underlying code. Basically, it’s one (small) step beyond lift and shift and is used for many the same reasons. If you’re fairly happy with what you have but do want to give it a bit of a wash and brush before you migrate to the cloud, then refactoring is probably the way to go. As with lift and shift migrations, most of the work will probably come after you have migrated to Azure.
Azure lift and shift versus architecture
The architecture migration method basically means reworking an application’s code so that it really can take advantage of what the cloud has to offer. It’s only usually feasible when you can devote an extensive amount of time and/or resources to getting it right.
In fact, it’s probably best if you have your own in-house developers who are familiar with the application(s) and/or extensive documentation (preferably and) because otherwise, you could end up finding that it would have been a whole lot quicker, easier and more affordable, just to have done a plain-vanilla lift and shift and then worked on the development of the app(s) when it/they were already in the cloud, probably in an agile manner, so staff had the benefit of incremental improvements while the company, as a whole, benefitted from incremental cost savings, which would help to offset the development costs.
Opting for the re-architecture migration method is a big decision and is probably only really advisable in situations where companies have already made a significant investment in their existing applications and believe that spending a bit more would be justified on the long-term return and where those existing applications are so important that companies want them to be cloud-ready from the moment of cloud deployment.
Azure lift and shift versus rebuilding
Rebuilding means exactly that. You create (or recreate) an application from scratch using cloud-native technologies so that what you end up with is something that is both resilient and highly scalable and which can be deployed without the hassle of needing to manage software licenses, underlying application infrastructure, middleware or any other resources. Basically, the application is all yours, and Azure platform as a service (PaaS) and/or infrastructure as a service (IaaS) takes care of everything needed to make your application run.
Perhaps rather ironically, there are two ways rebuilding can be used. The first way is similar to the architecture migration method. Basically, if you’re happy with what you have and you think it’s important that it can take full advantage of everything the cloud can do, right from the moment of deployment, then rebuilding can be the way to go.
Alternatively, rebuilding can be what happens after a lift and shift migration as part of a continual process of improvement. The downside to this approach is that you will have to shoulder the costs of the lift and shift migration and then the costs of the rebuilding, but the upside of it is that these costs will be, at least in part, offset by the cost savings you can make through being in the cloud.
See Also
Limitations of azure tco calculator