Lift and Shift

You’re evaluating a number of different cloud provider options. You have an existing application in mind you want to move to the cloud, but you don’t have the luxury of rewriting it. The application may have dependencies on existing databases, or may be written using middleware that is not available from a PaaS provider, or may simply be architected in a way that makes it incompatible with refactoring using the Strangler Application approach. In other situations, the development team is not available to work on refactoring the application - as may be true if the application is a COTS application or if the development team is an offshore team.

In this case, how do you gain the advantages of cloud by deploying an application to the cloud while minimizing the changes needed to be made to the application? You need to make the application environment in the cloud match as closely as you can to the environment it originally ran in on-premise in order to avoid changing your application code.

Therefore,

Choose an IaaS cloud provider that can create the closet possible match to the environment the application was originally built for. Then perform a Lift and Shift of an existing application onto the cloud platform.

A Lift and Shift migration is the most straightforward of the types of cloud migration that you can take on. In particular, the first rule of a Lift and Shift migration is in this migration approach you try to avoid changing any of the code of your application - the point is instead to change the cloud to match your existing environment. There are three basic steps that you need to ensure in order to make a Lift and Shift possible.

1. You need to ensure that the runtime environment that the application was built for can be duplicated by your cloud provider. In almost every case this means you will be running your application components within virtual machines on the cloud. This also means that you need to ensure that guest operating system vendor and version you are currently using can be supported by your cloud vendor, or that the application dependencies on version are so minimal that no code changes would be necessary to run on a new version.
2. You need to ensure that the networking dependencies of your application can be duplicated in the cloud. This is again an application-dependent requirement. If your application has specific network addresses and configuration that it relies on you may be forced into setting up a Virtual Private Cloud in order to maintain those dependencies. However, most applications are not quite that restrictive and may simply require updates to configuration files in order to allow application components to connect to one another. An important subset of this type of dependency to consider is connection into existing corporate security components such as single-sign-on products. In many cases, even if the application runs entirely in the cloud, all requests to the application must come up through a direct connection to a corporate internet and not through the global internet in order to meet corporate security requirements.
3. You need to ensure that any data dependencies that your application has can be satisfied either through databases provided by the cloud vendor, or through connection to existing back-end databases through a direct connection to the corporate internet. In nearly all cases, the former option will generally be faster than the latter option, but data residency requirements or dependencies on databases that are shared across many applications may require the latter.

Note that a Lift-And-Shift is just the starting point in a cloud journey. It’s not where you want to end up. Even to be successful with a Lift-And-Shift you need to adopt several Cloud-Native DevOps practices. At a minimum, Automating VM Deployments will be required in order to improve your overall ROI and begin to gain any benefits from Cloud. Likewise, the same thoughts about reliance that apply in cloud-native applications such as Three Data Centers and One Coast apply to traditional application resiliency as well, although the implementation choices may differ on which technologies you choose to perform data replication. A common approach, for instance, is to use existing approaches like Oracle DataGuard for replication across two datacenters, with backups being regularly taken and restored to a third datacenter.

Finally, a Lift-And-Shift is an opportunity to begin thinking about how you can then move on to a more cloud-native approach. After the Lift-And-Shift is completed, you should begin the process of looking for Hairline Cracks and consider taking a Strangler Application approach to refactoring in place.