The R’s of Migration
Here are five different ways that companies can consider for moving their data and apps to the cloud.
Join the DZone community and get the full member experience.
Join For FreeThere are many ways by which you can migrate your applications to the cloud. In this blog, we will go over different strategies that any company can leverage in order to migration their production workloads to the cloud.
Before the migration phase, it is essential to determine the current environment, its dependencies, types of servers and applications, licenses and much more.
The most common migration strategies found these days are as follows:
1. Rehost
2. Refactor
3. Revise
4. Rebuild
5. Replace
Rehost
This strategy is also known as “lift and shift.” This is the most common approach when migrating applications to the cloud. This type of strategy can help achieve immediate goals set by the company. In this strategy, you do not optimize the application to work best in the cloud environment. Any company can save considerable operational costs when they go with this strategy and reap the benefits of cloud computing. However, there might be some applications which may be very complex to lift and shift and can require a specialized set of tools and software.
Refactor
This strategy is also known as “re-architecting.” With refactoring you take some time to think and re-architect your existing application to leverage the features and services offered by the cloud environments. This strategy can become an expensive option but can offer the best possible benefits of the cloud. You can re-architect your application to become highly available and scalable. This strategy can also turn out to be time-consuming since more knowledge is required about the cloud platform itself and the services offered.
Revise
This strategy is also known as “re-platforming.” In this strategy, you can move some of the application components to the cloud. A good example of this strategy is to migrate on-premise vendor based solutions to the cloud. This can also enable you to free your application of any possible vendor lock-ins and costly licensing models. The cloud services are fully managed and therefore allow you to save operational expenditures. This strategy can end up costing more money as compared to re-hosting.
Rebuild
This strategy dictates that you develop your application from scratch using all the cloud services and features while discarding any legacy components. Rebuilding requires you to have complete knowledge of the existing application processes and functionality. It also requires you to have a good grasp of the cloud services. With rebuilding, you can also leverage a microservice-based architecture. After rebuilding you end up with a completely new application with new and improved feature set and capabilities. You might also end up having a totally new application interface and design which can cause some trouble with users.
Replace
This strategy is also known as “re-purchase.” In this strategy, you completely replace your current application with some commercial software which provides similar functionality but is fully managed and supported by the software vendor. This makes sense when you have a SaaS offering available in the cloud which offers many new features. This option has the least administrative overhead and is a good value for the money spent. But like all vendor software you are exposed to limited customization and vendor lock-ins. You might also end up changing your internal business processes in order to become compatible with the offered SaaS product.
In conclusion, choosing the appropriate migration strategy is never an easy task for an organization. Deciding on the strategy cannot be made in isolation by any particular team. One has to factor in and weigh a lot of variables and options including choosing the right cloud service provider, optimizing application processes, migration strategy, costs, overheads and many more.
Published at DZone with permission of Moiz Arif. See the original article here.
Opinions expressed by DZone contributors are their own.
Comments