As more infrastructure and applications are experiencing a shift towards cloud in reinforcing digital transformation, one of the most critical decisions that enterprises must make well ahead of time is the best approach to cloud migration for the long-term success of their enterprises.
As per the survey conducted by Netscouts in 2018, majority of the enterprise, i.e., 56% of respondents had already started workload migration. Besides, there were 14% respondents who were in the planning stage and rest 15% had plans to carry out the migration process in less than 6 months to 1 year.
Source: Netscout
And as apparent that there’s no one-sit-fits-all answer; up-front planning would make the migration process easier, and rather the whole cloud transition smoother.
So which is the best cloud migration approach for your business?
This blog takes a look at the three distinct migration approaches to help you choose the right one.
It’s time to reach the cloud
Additionally, this report also predicts that 80% of the companies are feeling the need to move their workloads to the cloud as soon as possible. And although there are multiple approaches for the same, but we will discuss the three most common here. Naturally, there are benefits and disadvantages to each:
- Lift and shift aka Rehost
- Lift, Tinker, and shift aka Replatform
- Refactor
1. Lift and Shift or Rehost
Rehosting or the lift and shift approach is a forklift approach to migrate applications to the cloud without any modifications in the code. The approach involves lifting either some part of the whole application from on-premise or existing cloud environment to a new cloud environment.
Currently, it is considered as the most common migration methods. It comprises 40% of all migrations because of its agility, simplicity, and speed in comparison to re-platforming and refactoring. 
This is beneficial for the large enterprises who want to migrate quickly with minimal or no disturbance in the existing application workflow.
And once the migration is done, it becomes quite easier for them to optimize the applications as they are already done away with the difficult part.
When to choose this approach?
“This works best for organizations looking to reduce their on-premises infrastructure expenses immediately”
Here are some common instances when enterprises should choose the rehosting approach-
- Large number of migrations over time
This lift-and-shift approach should be opted if it's simple, quick, and cheap and you have a lot of migrations to do overtime. Additionally, you need to factor the plan, and budget all of the post-migration work involved, like in case you have lifted and shifted non-cloud tools, processes, and people into the cloud.
- Urgency or pain point
A common compelling event could be the urgent evacuation of a data center or hosting provider.
This works best for organizations looking to reduce their on-premises infrastructure expenses immediately, those bearing too much cost in maintaining physical infrastructure or if you have been faced with some cloud disaster (e.g. corrupted database). They should opt for application rehosting to get their applications on the cloud with minor or no modification and also enjoy back up of these for smooth and fast running.
- Commercial and off-the-shelf applications
It forms as an apt choice for organizations having some applications on-board that need to be running without any intervention or modification. These are generally commercial and off the shelf applications, and rehosting is a good strategy to first move it onto the cloud with this approach as it is and then optimize.
- Virtualization and IaaS skillset
If the available resources are skilled in virtualization and infrastructure as a service, then rehosting matches their skill sets (whereas Replatforming and Refactoring need more skills)
- Test environments
Application testing makes an important environment to run the apps successfully. However, if they aren’t managed well, it can be done easily with a lift-and-shift approach to avoid disruption.
Benefits of Rehosting
The benefits of the lift-and-shift approach are-
- Quick migration
- Reduced risk (simplicity)
- Application, hypervisor, and hardware agnostic
- Can be highly automated with limited or zero downtime
- Imports configuration and scripts if these are not documented/ hard to reverse engineer
Limitations of the Rehosting approach
“The rehosting method does not let you reap benefits from the native cloud functionality and tools like elasticity”
The rehosting approach works because it is simpler in terms of migration. However, it involves risks and limitations with it-
- Migrating brittle processes
When you migrate an application, you also inherit the operating system, generally undocumented configurations, and non-cloud people and processes with it. So, if these processes are not clearly understood pre-migration, this will lead to a fragile application and a brittle end product.
- Cloud-native features
The rehosting method does not let you reap benefits from the native cloud functionality and tools like elasticity. The app functions the way it should in a single physical server but does not let you to take advantage of added flexibility and scalability offered by cloud environments.
- Rehosted applications are black boxes
Simply copy-pasting the applications and data without understanding what’s in them implies that you are pulling out everything into the cloud, including malware or insecure configurations.
- Unbudgeted/planned post rehosting activities
There are always post-rehosting activities that need to be taken care of. This involves additional cost beyond the basic migration process, in regards to money, time, and resources. These activities, if avoided, will prove costly in the long run, with high expenditure incurred on over-provisioned resources.
- Ingest known and unknown problems
If the application is facing problem outside the cloud, known or unknown, Rehosting will likely bring that problem to the cloud. Retiring technical debt is a big plus of more advanced migration methods like Replatforming and Refactoring or drop-and-shop technique of Repurchasing.
2. Lift, Tinker, and Shift or Replatform approach
In replatforming migration, a part of the application or the entire application is optimized with a small amount of up-versioning in API before moving to the cloud.
This varies from adding one or two functionalities to it to completely re-architecturing them before they can be rehosted or refactored and eventually deployed to the cloud.
“Developers can also reuse the resources they are accustomed to working with”
The replatforming approach ensures an interim solution between rehosting and refactoring, allowing workloads to take advantage of base cloud functionality and cost optimization, without the level of resource commitment required.
Developers can also reuse the resources they are accustomed to working with, such as legacy programming languages, development frameworks, and existing caches in the application.
Replatforming can be used to add new features for better scaling and leveraging the reserved resources of your cloud environment. There are even ways to integrate the app with native features of the cloud while little or no code modifications.
When to choose this approach?
Take a look at these scenarios when to opt for this approach-
“Replatforming allows you to reshape them to make it compatible with the cloud”
- Modification of applications is required
Replatforming is suitable when organizations want to make changes in the API of the applications (up-versioning) and then deploy it to the cloud. This may be because the source environment is not supporting the cloud, or the organizations want some minor changes without hampering the application’s functioning.
In such cases, some fine-tuning is required and for that re-platforming is the optimum choice.
- Avoid post-migration work
Organizations who deployed rehosting method realized that there is a slew of tasks that needs to be done post-migration to realize the full potential of the cloud. So, the feasible solution is to simply make the changes in the application during the migration itself. Hence, re-platforming works best in such a scenario.
- Leverage more cloud benefits
Organizations looking forward to leveraging more cloud benefits like scalability, elasticity, and cost-efficiency rather than just moving the application to the cloud, prefer the lift, tinker, and shift approach.
- Experience with more cloud skills
If you have the resources available in your organization who have been working with cloud-based solutions lately and can now shape applications for cloud compatibility, or take shortcuts in the migration process, consider using the Replatforming approach.
- Most apps are common three-tier web apps
When most of the apps are three-tier web apps, Replatforming allows you to reshape them to make it compatible with the cloud. And once you have reshaped one, you can leverage this far and wide, making significant efforts to improve efficiencies in migration as you move forward.
Benefits of Re-platforming
“Enterprises can leverage cloud-native functionalities without worrying about the risk, complexity, cost, and time of a full refactor”
Replatforming is a cost-efficient solution. It is an optimal place of action between rehosting and refactoring, where enterprises can leverage cloud-native functionalities without worrying about the risk, complexity, cost, and time of a full refactor.
This approach does not require to adjust the cloud server to match the previous environment. Instead, you have the flexibility to start small and scale up as needed, which indicates that you can save a lot while the cloud environment grows with the app itself.
Its benefits include-
- Use of cloud-native functionalities
- Apps can leverage the base cloud cost application
- Helps achieve tactical benefits, like reducing the amount of time spent managing database instances
- Reduce/ replace the common application components with a better cloud service, such as replacing Nginx in a VM with AWS Elastic Load Balancer.
Limitations of Replatforming
“If the cloud service used to replace a component is inappropriate or poorly configured, then the re-platform migration can go wrong”.
The major risk associated with re-platforming is that the project scope can grow and change if unchecked during the process, to become a complete refactor. Managing scope and avoiding unnecessary changes is key to mitigate this risk.
Secondly, if the cloud service used to replace a component is inappropriate or poorly configured, the replatform migration can go wrong.
Other limitations include:
- Overly aggressive change
Every individual shape during re-platforming increases the risk of causing problems: be circumspect and choose common, well-known shapings. Avoid exotic changes unless it’s a niche opportunity or unavoidable. The goal is a successful re-platform, not an exotic one. - Automation is required
Although the re-platforming approach can be done manually, it has limitations as modifications could be time taking. A better solution, therefore, is to model the application needs using an automation platform and then make modifications to the model to represent the platform shapings.
A summary of the pros and cons of each approach include:
|
Pros |
Cons |
|
|
Lift-and-Shift |
|
|
|
Partial Refactor |
|
|
|
Complete Refactor |
|
|
3. Re-architect or Refactor approach
Refactoring is the process where you run your applications on the infrastructure of your cloud provider, also referred to as Platform as a Service (PaaS).Refactoring is a bit more complex than the other two as while making changes to the code in the application, it must be ensured that they do not impact the external behavior of the application. For example, if your existing application is resource-intensive, it may cause larger cloud billing because it involves big data processing or image rendering. In that case, redesigning the application for a better resource utilization is required before moving to the cloud.
This approach is the most time- consuming and resource-demanding, yet it can offer the lowest monthly spend of the three approaches. And also the full potential of cloud to increase performance, resilience, and responsiveness.
When to choose this approach?
Refactoring comes in handy for the enterprises in the following scenarios-
“Refactoring method helps in reducing cost and improvements in operations, resilience, responsiveness, and security”
- Enterprises want to leverage cloud benefits
Refactoring is the best choice when there is a strong business requirement of appending features, scale or enhance performance by deploying cloud- which otherwise is not possible in the existing non-cloud environment. Simply put, the old ways don’t qualify the criteria and if you still stick to the old ways; your business might flip-over as an existential threat in this phase of cut-throat competition.
- Scaling up or restructuring code
When an organization is looking to expand its existing application or wants to restructure their code to draw off the complete potential of their cloud capabilities. - Boost agility
If your organization aspires to amplify agility, improve business continuity by moving to a service-based architecture, then this strategy does the trick. And that’s despite the fact that it is often the most expensive solution in the short-medium term. - Efficiency is a priority
Refactoring method helps in reducing cost and improvements in operations, resilience, responsiveness, and security.
Further, you have the option to choose between partial or complete refactor, depending upon your needs. Partial refactor involves modification of the small part of the application which results in faster migration compared to complete refactor.
Benefits of Refactoring
The benefits of refactoring are observed in the future. The current application and its environment configuration determine the complexity of refactoring, and that impacts the time-to-value from the project.
Its benefits include:
“This approach ensures an over-time reduction in costs, matching resource consumption with the demand, and eliminating the waste”
- Long-term cost reduction
This approach ensures an over-time reduction in costs, matching resource consumption with the demand, and eliminating the waste. Hence, this brings a better, and more lasting ROI compared to the less cloud-native applications.
- Increase resilience
Decoupling the application elements and attaching highly-available and managed services, the application inherits the resilience of the cloud.
- Responsive to business events
This approach lets application leverage the auto-scaling features of cloud services that scale up and down as per demand.
Limitations of Refactoring
The limitations are here-
- Vendor lock-in
The more cloud-native your application is, the more tightly it is coupled to the cloud you are in.
- Skills
Refactoring demands the highest level of application, automation, and cloud skills and experience to carry out the process.
- Time
As refactoring is the complicated method of migrating from a non-cloud application to a cloud-native application, it can consume a considerable amount of time.
- Getting it wrong
Refactoring involves changing everything about the application, so it has the maximum probability of things going the other way round. Each mistake will cause delays, cost imbalances, and potential outranges.
Refactoring is a complex process but it is well worth the results and improvement that you get in return. It is a resource-demanding process, one that requires plenty of time to complete. Some companies even go as far as refactoring parts of their business solutions to make the whole process more manageable. This compartmentalization could also lead to refactoring becoming longer and more resource exhausting.
Final words
Which one is the best approach?
There is no absolute answer to the question, especially since different use cases require different things. Picking one among the three approaches is a matter of finding the best that suits your specific needs. That said, start by checking if the app can be moved to a cloud environment in its entirety while maintaining cost and keeping operational efficiency in check. If the answer is yes, start with the rehost method.
If rehosting doesn’t seem like a fit for you or if cost-efficiency is at a level that needs to be refined, you can also consider re-platforming as a good option. Remember that not all apps can be transitioned this way, so you may end up having to find other solutions entirely.
The same approach goes for refactoring. If you have enough time and resources to complete a full refactor of your current solutions, then take SaaS and other alternate solutions into consideration.
Nevertheless, you can certainly take most of the hassle out of moving to the cloud with the right cloud migration strategy. You can then devote yourself to finding new resources to use, better flexibility to benefit from, and a more effective environment for your apps.
Take account of these points in mind, and you’ll be able to find the best approach out of these. However, there is no defined path to success. Your organization needs may vary and delve you into adopting a combination of these approaches, i.e. hybrid approach.
For example, it is possible that after conducting a migration analysis for your organization, it is determined that:
- 50% of your apps need to be re-hosted
- 10% to be retained on-premises in a colocation facility
- 40% apps, which are maintenance-level yet business-critical, are flagged for re-platforming/refactoring
What is important in the end is to plan and roll out your migration plan by conducting a thorough analysis of your complete IT system, your infrastructure, and your application workload.
This assessment will help you determine which strategy to use and which part(s) should be moved to the cloud.
