The method you choose for migrating to Cloud Infrastructure depends on many things. Do your current applications meet functionality demands? Are they compatible with cloud infrastructure? If not, what is required to make the application cloud-ready? When should you perform the different migration strategies, and what do you stand to gain from each?
For smaller businesses with less stock in the game, there may be fewer considerations to be made for the migration strategy. Firstly, if they are very young, they might start in the cloud altogether (SaaS solution, for example). But even if they have a small on-premise footprint and want to pursue cloud infrastructure, for the time being, they still might be able to accept a packaged approach to migrating to cloud because the structure of their ecosystem comes with fewer complexities and therefore less risk. This would serve them well because they would shift more responsibility over to their cloud providers with less cost and difficulty, allowing them to handle things on the business end.
For moderate and larger size corporations who have already gained commercial momentum with an in-house IT team, they might have applications developed years ago on which the business relies. These may even be legacy systems that have endured high configuration, repatching, and improvement over time. For them, there are much greater considerations to be made within their application modernization strategy that will directly influence the overall cost and impact-to-business of migrating to cloud.
For application leaders who already know the benefits of migrating to cloud and are wanting more information about different migration strategies, it should be said that there are several commercial interpretations for application migration strategies. If you want to focus on the technology and avoid altering too much of the code, architecture, and functionality of your EBS applications, there are 3 great options to choose from to retain much of your EBS: Re-hosting, Re-platforming, and Re-factoring (not to be confused with replacing or rebuilding).
Rehost vs Replatform vs Refactor
Re-hosting
Re-hosting, also known as lift and shift, involves taking a snapshot of the application server VM’s on the source environment including the OS, boot record, converting into a cloud compatible format (qcow2, vmdk) and importing it as a custom Image, and then re-instantiating the image.
Rehosting EBS on Cloud
- Organizations that, due to the nature of their business and conditions present while migrating to cloud, require low costs and quick time to market for their EBS applications.
- Organizations who are concerned with switching from CAPEX to OPEX and do not feel the need to improve the functionality of EBS applications (through re-platforming or refactoring) because the application is not disrupting the end-user experience or posing additional technical challenges to IT on the backend.
- Organizations pursuing a hybrid environment may have certain EBS applications that they must keep running without disruption or modification.
- In the case of commercial and off-the-shelf applications, it might be impossible to do code changes on the EBS applications without re-platforming or refactoring. They may be able to perform a lift and shift while migrating but at the expense of some Cloud functionality.
- For projects that require fast provisioning of environments to support product development till deployment, rehosting might be best.
- For organizations embracing the pay as you go model to avoid standing up on dedicated infrastructure for short term projects.
Rehosting Non-EBS Applications
If you have non-Oracle applications, those cannot be rebuilt with ease. Here you would create a snapshot of the entire image (OS, application, configuration information, and data), import it, and rerun it there. The application can also be an on-premise database deployment, which was installed and configured on the source virtual machine.
Consider a web application as a simple example. Imagine you have an ASP.NET application running on Windows and you want to rehost it on Oracle cloud. You can create a Windows VM that meets the size requirements and deploy the application. With a change to the DNS record, you’re pretty much ready to go live. In this way, rehosting is an easy way to move to the cloud.
Re-Platforming
Re-platforming, also known as, “Lift, Tinker, and Shift,” involves rebuilding or redeploying the application on an upgraded operating system. Here you will make slight changes to code, but do not change the code structure or the functions it provides.
Re-Platforming EBS on Cloud
- Older EBS applications that are not within the latest version and require improvements in their IT functioning and limited change to the end-user experience.
- Organizations are willing to automate certain tasks within their EBS applications that are essentials to operations but not business priorities.
- Organizations looking to leverage more cloud benefits other than just moving the EBS application to the cloud.
- If while moving an EBS application to the cloud the source environment is not supporting the cloud, then a slight modification is required.
- If the EBS infrastructure is complex and hinders scalability and performance, tech stake changes might be required i.e. re-platforming to produce changes to internal architecture.
Re-Platforming Non-EBS Applications
You create a new Oracle Cloud Infrastructure virtual machine, based on a new version of the Oracle Linux operating system with the latest security updates. You can then redeploy your application on the new operating system. For example, consider the task of migrating PeopleSoft using Cloud Manager. This operation reinstalls PeopleSoft on a new Oracle Cloud Infrastructure VM and moves the configurations and corresponding data over to the operating system
Re-Factoring
Refactoring to cloud involves improving existing code to strengthen nonfunctional attributes and the structure of the component. It does involve changes to the tech stack but it does not involve significantly altering the code so you can shift it to a new application architecture altogether (rearchitecting) nor does it involve rewriting the application code (rebuilding).
Re-Factoring EBS on Cloud
- Your EBS applications require some changes to the tech stack because they are lacking in IT functionality that hinders operations in a significant way.
- You want to exploit more features of the cloud by optimizing existing code and are willing to accept the additional costs and labor.
- You want to scale an EBS application to maximize performance and are seeking to improve the structure of the component.
- You have the resources and time to adjust your EBS applications but are not willing to materially alter the application code and do not want to embrace a new application architecture.
Re-Factoring Non-EBS Applications
Examples may include moving from single node to RAC DB, from single node application configuration to a load-balanced cluster configuration, incorporating DR ability with RPO/RTO meeting business requirements, and needed the ability to provide auto-scaling to match performance to load. For some of these cases, however, it may be the case that they require a new architecture (rearchitecting) entirely, not refactoring (partial architecture).
Re-Host or Re-Platform or Re-Factor: Which One to Choose
Contrary to the common commercial understanding, the migration strategy selection process is not as straightforward as you think. It requires intense negotiation and internal diagnosis.
For companies who want to put their apps in the cloud quickly, rehosting is a straightforward option. You redeploy the application component to other (physical, virtual, or cloud) infrastructure without recompiling, modifying the application code, or modifying its features and functions. However, it must be confirmed whether the application (as is) is operable when migrating to cloud.]
Is a lift and shift migration even an option for the application? If it is, you must consider if this exposes you to risk or reduced performance and whether you are willing to tolerate this forfeiture. If it is not operable when migrating to cloud, you must determine what changes are needed and the lengths you’re willing to go to make it cloud-ready.
Is it due to an issue in the tech stack (i.e. do you require some level of re-platforming?) Here you will have to decide if you would be better off keeping this application as-is on-premise, or if you’re willing to make the investments needed to optimize it for the cloud or take this migration as an opportunity for tech stack/application version upgrade (i.e. re-platforming / refactoring).
For those who wish to retain majority of functionality for end users but want to improve the underlying IT behind the applications, re-platforming is fitting. By incorporating PaaS for application re-platforming, you make minimal changes to code in order to mold it to a new platform, but you do not change the code structure or its features. This will improve the IT end without significantly changing the usability for end-users. There may be slight modifications to how the system works for end-users, but in exchange, you’re able to enjoy more of the benefits of the cloud at less risk that you will run into obstacles down the road (such as is with lift and shift). The question is, at what expense?
Whether you are re-platforming as a technical requirement to make the application operable when migrating to cloud or because you want to optimize your IT architecture for better use of the cloud, you must leverage the added time and cost needed for the re-platforming migration.
Depending on your database size, characteristics within your data set, your operating system, and other features of the tech stack, re-platforming could be cost-intensive or lead to more disruption to the business (i.e. downtime). Even for the added benefits of the cloud, does this fit within your current conditions? Did you require a speedy migration, or did you set time and money aside for this additional transformation? The effectiveness will also depend on the skill you have available at your disposal. Are you performing this with little support from 3rd party? If you’re migrating through an MSP, are they experienced / to what extent do they reflect a maturity in your area?
Through containerizing, rehosting, or re-platforming, you can maintain your legacy app with a relatively easier and less costly process. This is excellent for companies who wish to fill functional gaps, streamline operations, and reduce costs WITHOUT complete alteration to the ecosystem and how end-user engages with it. For rehosting and re-platforming, both create change to the technology platform that the component is running on and can solve problems that are caused by the technology as opposed to the interior elements and functionality. Still, re-platforming does involve some level of change into the underlying architecture that will cause you to incur additional cost and labor that, if mandatory, you will have to account for, it just recommended, you will have to perform a gap analysis to compare the differences within each course of action.
For those who wish to take greater advantage of the cloud and solve issues within the application architecture without completely replacing its architecture, refactoring is an option that will alleviate significant challenges in IT. However, as you may know, Refactoring is a more complex process and deals more with the underlying architecture. Unlike rehosting and re-platforming, this entails changes in the technology platform and the architecture structure. It can solve problems in the technology and architecture domains and possibly address issues in your functionality. It may be well worth the improvement that you get in return, but it will require more cost and labor, and if you choose a rearchitecting strategy or above, this correlation persists.