As of today, businesses are in the middle of their journeys to migrate their workloads to the public cloud. There are multiple strategies and paths to follow. Some follow a very strict plan, while others tend to choose a more iterative approach. Whatever you chose, it’s good to consider the various scenarios which are at play. There are two approaches which vary very differently: the lift and shift approach and the cloud-native approach.
A lot of companies adopt lift and shift approach, as it’s relatively simple and quick. It’s good to know the considerations of this approach before you start so you can make an informed decision.
Comparison
Before we do a deeper dive into the topic, let’s first compare both approaches to set the right context.
Lift and shift
Simply said, this is all about moving the existing architecture to the cloud datacenter without modifying it. The most simple scenario is to set up similar VMs in the cloud as in the on-premises data-center and deploy your applications on top of it. This approaches mainly utilizes the IaaS services, and treats the cloud as yet another datacenter.
All major cloud providers offer tools to help you to make this journey more efficient, especially if you have a large number of VMs. Google offers Velostrata, AWS brings in their Connector for vCenter and Azure offers a service called “Azure Site Recovery“.
Cloud-native
A completely different approach to lift and shift is cloud-native. With pure cloud-native services you only pay for the services for the time you actually use them. It’s like consumption-based services that do not run and incur cost while not being used. Provisioned infrastructure like using VMs is a thing of the past here and traditional data-centers which merely host VMs do not have this option.
This option requires you to re-architect your applications to fit within the new type of services: you need to refactor your applications. And to make things even more complicated: split up your big monolith into smaller chunks. All in all, it requires a number of technical challenges that slows down this migration path.
Back to lift and shift.
Potential benefits
Companies who choose the lift and shift approach seek and expect benefits in the short term. Some of them are relevant here are:
- No customization needed: they do not have to change their existing architecture or many processes. All cloud providers support VMs in a certain form or shape. This also means the system administrators do not have to learn new fundamental skills. Strictly speaking, they don’t even need to know much of the cloud providers’ console to operate their machines.
- The operating model does not change: since a pure lift and shift does not have a significant effect on the organization, the way you operate does not change (so much). It does not matter if your VMs are in your own data-center or in the public cloud (re-hosting), your organization knows already how to deal with it.
- Level of automation is high: since all major cloud providers offer tools to migrate big bunches of VMs in parallel, automation helps to speed the processes up.
Planning and costs
- Planning is not a big issue. For sure you need to have a basic plan in place which includes the priority of VMs, who does what and when etc. However, since there aren’t many complicated aspects, planning can be simple and straightforward.
- Lower costs at first glance: since all of the above helps you to speed up the migration, the costs are relatively low which makes it a very attractive choice. Bear in mind, we’re talking about initial costs here.
- It’s fast: perhaps the biggest benefit of all. You get your systems up and running in the cloud pretty fast due to the low number of differences compared to your existing situation.
All of the potential benefits reduce the organizational risks of migration. That does not mean there are no risks at all. The risks come from a different perspective.
Perceived risks
Nothing comes with a price. Some of the perceived risks are as follows:
- Overprovisioning. If architecture is not properly (re)sized for the public cloud, you risk selecting an over-provisioned VM which is under-utilized. Cloud providers bill you a certain amount per (type of) VM per period. Multiplied by the number of VMs which you have migrated, this can quickly result in a very high bill. You should really carefully determine which VM is right for your application or make the decision whether or not moving the application at all if the costs are too high. To get more tips on this topic, read our article on cloud cost savings.
- Underprovisioning. If, on the other hand, the cloud infrastructure is under-provisioned, your application can become very slow or even crash. This results in (additional) downtime and a bad experience for your customers. Consider an application that serves your most important customers, this can have a very negative effect on your cash-flow. It can also affect the other cloud migration activities.
Security aspects
- Security. In the on-prem world, the security perimeter is crystal clear. Very simply speaking: everything outside of your firewall is considered “hostile” and everything inside is considered “under control” (and thus perceived as secure). This frees the way to take security less strict than in the public cloud. Think of the following examples: secrets in configuration files or in application source code, static IP address which are (accidentally) whitelisted or highly privileged accounts which now have a much higher blast radius if exploited. You need to take extra care about security and before you pull everything over, you need to know what is what and what the potential impact will be within the context of the public cloud.
Given these, let’s take a look at some more considerations which might be less clear at first sight.
Additional considerations
It’s interesting to notice that some articles suggest to definitively start a “lift and shift” approach while others warn not to do it.
Two other major cloud migration considerations include the following:
- Choose your database wisely. Companies that tend to select the exact same database architecture in the public cloud as what they are running in their on-prem data-center might face a very high bill. Database type A in the cloud might not be optimized for the intended workloads and if companies don’t look at the price-tag per request (databases can incur a lot of requests) or for the amount of storage which is needed (also think of replication) this can lead to unexpected results. It would be better to migrate to a better database that is optimized for the intended workload and within the context of the public cloud offering. Perhaps a little bit of customization of the application is needed, here you need to calculate how much effort it would cost and how much money you can save.
Don’t underestimate DevOps
- Don’t use DevOps principles. Perhaps the folks of the data-center have not even thought of this, since it does not exist in their workplace. If you do not take into account the DevOps principles such as IaC, pipelines to rollout applications, do security checks and integration tests before you release a new version of your architecture and/or application you do miss the benefits of the public cloud.
Sooner or later the cloud teams need to talk to the application teams and vice versa. These worlds will blend and if you do not think of it up from properly, there will be a huge loss. Examples of potential loss:
- Disconnected cloud and developer teams: constant misunderstandings on who does what, when and how. Bridge that gap to avoid creating new silos.
- Not using DevOps principles slows down processes that could be automated pretty easily. Avoid manual work where possible.
- Expectations of the management are wrong: if you don’t set the right expectations, the management and other co-workers might lose their interest in the migration which will frustrate all who are involved. The management could even withdraw the budgets which have been allocated to your project.
Closing words
Lift and shift your existing architecture to the cloud brings a lot of potential benefits. You can start pretty fast and the initial costs are relatively low. However, there are other considerations to take into account.
