he method you choose for migrating to Oracle Cloud Infrastructure depends on many things. Do your current applications meet functionality demands? Are they compatible with OCI? 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? In this article, the information will be provided to help you decide whether you should rehost, re-platform, or refactor your applications when migrating to Oracle Cloud Infrastructure.
Why Should You Consider Oracle Cloud Migration?
Though Oracle does cater strongly to native users, it presents low entry barriers for Non-Oracle users who are considering migrating to Oracle Cloud Infrastructure due to its demonstrated potential for excellent cloud performance.
For the EBS user, migrating to Oracle Cloud Infrastructure is easily the best course of action, even against commercial giants like AWS.
For the non-EBS user though, research shows the benefits of migrating to Oracle Cloud Infrastructure rivals benefits of migrating to AWS, especially in terms of Cost, Performance, and Security.
Migrating to Oracle Cloud Infrastructure leads to excellent flexibility, reliability, security, and performance, and since you can achieve a lower Total Cost of Ownership (TCO) than many providers (due to their advanced compute and 2nd generation cloud), it is a high-value selection and an excellent starting point for your Cloud journey.
What if You’re not a Native Oracle User?
This article provides support for migrating to Oracle Cloud Infrastructure with consideration for native Oracle users who run E-Business Suite. However, the material offered also applies to other Oracle-based solutions (PeopleSoft, JD Edwards, etc.) and non-Oracle based solutions as well, since non-Oracle based examples will be provided for context and the considerations included for selecting your migration strategy will be useful for all those pursuing Cloud IaaS.
Putting Cloud IaaS into Perspective Before Oracle Cloud Infrastructure Migration
Cloud IaaS is a pathway to modernization that requires heavy application consideration. The level of consideration depends on you and your business.
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 Oracle Cloud Infrastructure 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 Oracle Cloud Infrastructure.
For example, Acme corporation may have over 200 applications, and to migrate as little as half of them over to OCI (some may remain on-premise), each application must be carefully observed to determine what its role is in the business, whether it is performing at maximum capacity (delivering the most value to the business) and what type of migration to Oracle Cloud Infrastructure is most fitting to achieve their desired outcome [while still remaining within budgetary and timeline constraints].
With this in mind, it is evident that migrating to Oracle Cloud Infrastructure, and transitioning to Cloud IaaS in general, comes with a lot of considerations that are difficult to account for in the planning stages of the migration.
A possible reason why it is so difficult may simply be the lack of hands-on experience that businesses have in handling the cloud. In fact, this is a primary reason why Gartner predicts MSP usage to go up as businesses outsource to compensate for their cloud deficiencies and avoid sub-optimal migrations.
Irrespective of this barrier, most businesses are candidates for Cloud Infrastructure, so when the concerned CEO asks, “What is Cloud IaaS,” tell him it is a solution that leads to continuous value-added for the business (or, send him this).
Why Rehosting, Replatforming, and Refactoring?
For application leaders who already know the benefits of migrating to Oracle Cloud Infrastructure and are wanting more information about different migration strategies, it should be said that there are several commercial interpretations for application migration strategies.
Per Gartner, there are actually 7 strategies for modernizing your applications strategies, as discussed in the attached eBook. According to other sources, there are 4 or 5. This can create confusion. From Rehosting to Rearchitecting to Rebuilding, as you move further down the list, you embrace more transformation to your applications, and if you move far enough, you end up replacing your EBS / on-premise applications entirely with Cloud Native applications.
For this reason, in the context of Oracle Cloud Infrastructure migration, 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). While you are making changes to the architecture in refactoring, beyond these 3, you are shifting to new application architecture and functionality altogether to embrace significant change.
The essential difference is whether you are doing a simple migration to quickly enjoy the CAPEX to OPEX and other benefits of Cloud IaaS (Rehosting), or if you are making changes to your databases and tech stack as well through a PaaS layer (re-platforming and refactoring). We will discuss these strategies in the context of migrating to Oracle Cloud Infrastructure and then provide recommendations for how to select the right strategy to modernize your applications.
Re-hosting
What Does it Mean to Rehost to OCI?
According to Oracle, this migration to Oracle Cloud Infrastructure, 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 an Oracle Cloud Infrastructure-compatible format (qcow2, vmdk) and importing it on Oracle Cloud Infrastructure as a custom Image, and then re-instantiating the image.
What are Some Common EBS Use Cases for Rehosting to OCI?
- Organizations that, due to the nature of their business and conditions present while migrating to Oracle Cloud Infrastructure, 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 to Oracle Cloud Infrastructure but at the expense of some Cloud functionality.
- For some EBS applications, it might be a good strategy to rehost while migrating to Oracle Cloud Infrastructure then optimize further down the road.
- For projects that require fast provisioning of environments to support product development till deployment, migrating to Oracle Cloud Infrastructure using rehosting might be best.
- For organizations embracing the pay as you go model to avoid standing up on dedicated infrastructure for short term projects.
What are Some Examples of Non-EBS Applications Being Rehosted to OCI?
If you have non-Oracle applications running on a VM on Oracle Cloud Infrastructure Compute Classic, these applications cannot be rebuilt with ease. Here you would create a snapshot of the entire image (OS, application, configuration information, and data), import it into Oracle Cloud Infrastructure, and rerun it there. Essentially, you are rehosting the application server from Oracle Cloud Infrastructure Compute Classic to Oracle Cloud Infrastructure. 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 OCI. 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
What Does it Mean to Replatform to OCI?
Replatforming, 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.
What are Some Common EBS use Cases for Replatforming to OCI?
- 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.
What are Some Examples of Non EBS Applications Being Replatformed to OCI?
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
What Does it Mean to Refactor to OCI?
This strategy for migrating to Oracle Cloud Infrastructure 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).
What are the Best EBS use Cases for Refactoring to OCI?
- 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.
What are Some Examples of Non-EBS Applications Being Refactored to OCI?
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).
Which Migration Strategy Should You 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 Oracle Cloud Infrastructure (or the infrastructure of your selected provider). 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 Oracle Cloud Infrastructure, 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 Oracle Cloud Infrastructure 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.
For EBS to OCI, there is a lot of documentation provided by Oracle on how to decide between these three, and the tools you have available at your disposal are more than a non-EBS user. However, there are certain unique situations that are not accounted for, and if you pursue a migration unliterally or with limited 3rd party assistance, anticipate added difficulty to come from the hands-on experience of migrating.
What is the Migration Strategy Really Based on?
How do you decide when an application should be rehosted, modified, or replaced/rebuilt as a cloud-native application? That depends on which applications pose a legitimate obstacle to the business. If an application has a low business impact, high risk, sub-optimal value, and poor technological fit, which modernization approach is best to solve that problem? Is it the Lift and Shift Migration Strategy, or another methodology, such as refactoring?
The quality of your decisions will depend on the tools you use within the initial stages of cloud adoption to diagnose your applications. Failure to implement a documented methodology could lead you to incur additional costs and produce a sub-optimal cloud IaaS migration, therefore you’ll want to rely on trusted sources for selecting your application migration strategy.
Frequently Asked Questions
What does it mean to migrate a database from On-Premise to Oracle Cloud Infrastructure?
Similar to the logic of migrating your infrastructure to OCI, migrating a database from on-premise to Oracle Cloud Infrastructure entails migrating your on-premise Oracle Database to an Oracle Cloud Infrastructure database service. This deals more with the PaaS layer of Cloud. Some of the factors consider when choosing a migration method are database version, operating system, version, data CHAR set, and others.
You can read more about Oracle Database Migration here.
What are Oracle Cloud Migration services?
Oracle Cloud Migration services are services provided by Oracle or another 3rd party to support you in your journey from on-premise to Cloud. This can be for migrating to Oracle Cloud Infrastructure or another pillar of the cloud. Services will vary by provider/vendor. However, they are becoming increasingly popular as companies begin to recognize that the prospect of migrating to the cloud is no easy task and so they invest in services to not only reduce the risk of migration but to set them up for success after.
What are Oracle Cloud Migration tools?
There are several Oracle Cloud migration tools. For instance, there is Oracle EBS Cloud Manager. This is a tool for managing Oracle E-Business Suite when migrating to Oracle Cloud Infrastructure. It can be used to provision a new environment, providing an environment from a backup of an on-premises EBS instance as part of a lift and shift process, back up a previously provisioned Cloud environment, etc. To name some others, there is also OA Framework, a technology for developing new customizations, and Oracle Forms, a technology to maintain existing forms.
What are Oracle Cloud Migration Best Practices?
Best practices for an Oracle Cloud Migration depend on what you are migrating. Like all things, Cloud, best practices for migration, especially when migrating to Oracle Cloud Infrastructure, are rooted in proper planning. For Oracle Cloud, the 5 steps before migrating to Oracle Cloud include evaluation, planning/assessment, implementation, operations, and optimization/evolution. You can read more about it here.
What is Cloning Storage from On-Premise to Oracle Cloud Infrastructure?
Oracle Cloud Infrastructure is one of the only public cloud providers that support block storage cloning. Cloning enables you to quickly and easily create an identical copy of a block volume without having to first create a backup. While the cloned volume is being created or accessed, the original volume is not impacted in any way. You can clone an existing block volume, regardless of whether it is attached to a compute instance or not. You can clone any block volume regardless of its size, in a matter of seconds, without the associated costs and hassle of the backup and restore process.
What are Oracle Cloud Infrastructure’s Core Values?
Core values of Oracle Cloud Infrastructure include the 2nd generation cloud, enterprise expertise, price performance, and security first architecture. Oracle demonstrates a clear initiative to respond to customer concerns regarding Cloud. For this reason, they devote much of their resources to innovating around customer priorities such as price/performance (value) and top security. It is summed up well here. These are important points when considering migrating to Oracle Cloud Infrastructure.
