Over the last few years, we’ve migrated more than 60 SaaS-based applications to Oracle Cloud Infrastructure. These applications support core enterprise functions across eight industry verticals and more than 199,000 customers across the globe.
In this playbook, we'll share key challenges, lessons learned, best practices, and the benefits we’ve experienced on our own journey to cloud. Put the insight of our cloud transformation to work for you.
If you run your own data center and hosted environment, moving to the cloud is a major shift. While cloud offers enhanced resilience, scale, and scope of infrastructure services, completing this journey requires you to re-examine and adapt technology, organizational structure, and business practices. This impacts a wide matrix of variables from long-term product roadmaps to planned technology investments.
In making the transition, you must address unique challenges, answer foundational questions, and seize far-reaching opportunities. The road to cloud is not clearly paved. No single approach, architecture, or set of services will be useful for all cloud applications.
This Software-as-a-Service (SaaS) Migration Playbook for Independent Software Vendors (ISVs) is based on the learnings we've accumulated in migrating more than 60 SaaS-based applications to Oracle Cloud Infrastructure (OCI). These applications support core enterprise functions across eight industry verticals and more than 199,000 customers across the globe. Many of the challenges our teams navigated and the solutions we implemented are the same ones that you may encounter when migrating to a cloud model. This playbook distills our experiences across all stages of the transition and provides powerful insights and observations to assist you with your journey. You can also visit our Oracle@Oracle website to reference more than a dozen white papers and blogs that discuss our cloud transformation journey and share best practices, challenges, and lessons learned along the way.
We believe any ISV—or any enterprise offering internal- or external-facing, SaaS-based applications—can experience similar benefits by moving to the cloud.
Navigating your cloud journey
Any cloud transformation process that includes application migration will be complex. Yet among this complexity, there are a few clearly defined destinations on the journey to cloud. One such destination involves how "cloud-ready" to make the target application. How cloud-ready do you want/need the application to be in order to move to cloud at the desired time frame? Throughout this paper, we will outline some of these destinations and highlight best practices and lessons learned based on our journey. The key to success is to clearly define your migration goals in advance so that you can make optimal decisions about how to reach them. You’ll find yourself confronted by many potential paths. Over the course of your migration, developers, delivery teams, and executives will need to evaluate and make many choices about how to proceed.
We recommend focusing on the following technical and business drivers to frame the decisions you need to make to meet your business objectives.
Cloud services provide compute power at scale—far beyond what is possible for managed infrastructure—enabling your business to grow to meet market opportunities. Cloud-based infrastructure as a service (IaaS) and platform as-a-service (PaaS) enables ISVs to focus on building scalable architectures utilizing modern components. An added benefit of migration is that by freeing internal development teams from managing and scaling IT operations, focus can be directed to tuning and optimizing performance.
Modernizing toolsets, services, and architectures eases integration between components, helping applications realize the full value of the tools and technologies available in the cloud. Such tools range from infrastructure upgrades to automated deployment pipelines to integrated machine learning models that improve application performance. Modernization is most important where markets are experiencing rapid and consistent change, as applications must be dynamic to keep pace. In some cases, services can be completely rewritten and rebranded, leveraging the latest technology stack to offer lower costs or more-streamlined service options. Such changes can refresh aging products and disrupt established markets where licensed offerings are the norm. In other cases, products may be overhauled with new approaches, improving service while preserving brand awareness and customer loyalty. This does not necessarily require a complete change to the product suite.
Moving to the cloud becomes a trigger for a broad-based modernization push. As cloud provides you and your teams with access to services, technologies, and expertise that were not previously available in your organization, it becomes possible to achieve new goals and deliver new capabilities. Your teams can move “up the stack” to focus on new, generally applicable product features rather than custom code linked to specific deployments with distinct customers. With service provisioning, product updates, and customer support all happening faster than ever, resources can be refocused on developing new features. In this way, cloud migration sets the stage for a broad wave of modernization activities, transforming everything from the execution of product upgrades to the quality of customer service.
"The migration to the Gen2 Cloud has enabled Oracle to ensure successful delivery of our services via a robust DevSecOps model and allowed us to support our customers' business transformations. We now release software daily and have decreased provisioning time by more than 98%." — Karthic Murali, Senior Principal Product Strategy Manager, Oracle Global Business Units
StandardizationStandardization across IaaS and PaaS allows you to reduce overhead and make teams more flexible and fungible. As organizations grow, your teams will adopt tools of various maturity levels. Consolidating these toolsets within the cloud service abstracts much of the complexity associated with this layer of IT management. It permits the development and use of standard operational practices for tasks that can map across the portfolio. Standardizing also makes routine activities simpler and more predictable, reducing labor demand for basic tasks. Resources previously tied up in navigating varied, possibly incompatible processes across applications are freed to focus on more-important problems, including the development of next-generation products and services for customers.
Notably, standardization makes it simpler to enforce global policies and practices around security, risk, compliance, and other operational activities that your teams can easily apply to existing and new products. In fact, many of the intrinsic capabilities of the IaaS platform, such as accredited compliance certifications, can be inherited by the application.
Revenue optimization can be achieved in two primary ways. First, and most obvious, are cost reductions. Eliminating data centers by utilizing IaaS not only shifts the financial model from CapEx to OpEx, it also typically results in meaningful TCO savings. What may not be as obvious are the cost savings achieved by rationalizing the technology stack used across a portfolio of applications that have been migrated to cloud. Common toolsets create institutional knowledge and eliminate the expense associated with ad hoc training for nonstandardized tools. Along these lines, common toolsets that treat infrastructure as code provide automation that ultimately saves time and labor costs. Finally, teams who are specialized in foundational areas that apply across the portfolio, such as security, eliminate the need to create experts within each individual product team.
Secondly, the move to cloud can ultimately optimize revenue by helping you get to market faster, as product development timelines are typically shortened once an application is cloud-ready or cloud native. Getting to market quicker means faster revenue realization. Once an application is cloud-ready, it can be deployed anywhere across the globe in a matter of minutes.
Combined, the principles discussed above should result in standardized product and service architectures as well as improved deployment speed and quality. Scale results from design for repeated patterns, which contributes to revenue optimization, quicker time to value, and the resulting ability to refocus resources on enhancing the quality and integrity of the service for customers.
"We saw a financial performance that allowed us just out of the gate to save 30 to 35% in our CapEx expenditure, and with the great performance we're getting from OCI, the ROI that we deliver with our suite continues to get better and better." —Mike Morini, Chief Executive Officer, WorkForce Software
Paths to value in the cloud
Cloud computing can include an array of IaaS and PaaS resources as well as multiple software deployment models, ranging from access to bare metal instances to integrated containerized environments to fully functional service stacks. At the most basic level, cloud computing refers to the replacement of physical infrastructure components with core IaaS resources.
Most enterprise applications were not originally built for the cloud. For many applications, converting or conforming to cloud patterns is time consuming and difficult. Replatforming can be expensive from both a time and labor perspective, so it is not surprising that it can sometimes be easier to design for cloud native principals from scratch. Taking that into consideration, companies typically find themselves in one of three main scenarios when considering a cloud migration.
Another way to envision these scenarios is to look across the spectrum of actions you could take to move an enterprise application closer to a cloud native architecture while moving it to Oracle Cloud Infrastructure. See Figure 1 below.
Figure 1: Cloud migration change and investment levels
The left side of Figure 1 represents the least amount of change, the shortest time to value, and the lowest initial investment. The level of change, investment, and time generally increase as you move to the right, but the realized value is also greater. This model helps you frame a way to predict what kinds of investments to consider making during the move phase. Note that the scenarios aren’t necessarily discrete and overlap a bit as applications are built in a myriad of ways.
The scenarios described above become key reference points for assessing existing maturity levels and cloud-transition objectives. The gap between your current state and target state provides a rough estimation of the scope of technical and process change required for the cloud transition. In a perfect world, the cloud transition should result in all applications transitioning to cloud native delivery models. However, given resource and time constraints, few organizations are positioned to transition their whole portfolio to a cloud native model in a single process. Even simple replatforming efforts can be resource intensive and require significant investments just to replicate legacy capabilities.
The cloud transition is thus a question of identifying the trade-offs between the optimal cloud maturity level (where the applications sit in the cloud-hosted to cloud native continuum shown above) and the engineering investment needed to re-architect the product and its associated business processes. At this stage, the key step is identifying each application’s current and target maturity levels with a rough estimate of the development investment required to bridge the gap.
Applications that change maturity levels during migration also have to change operational patterns and expectations. The changing of maturity levels affects the teams, processes, and policies that support the service.
Evaluating technical readiness for the cloud
A technical understanding of the target application—or entire application portfolio for companies offering multiple SaaS-based applications—is vital to understanding requirements and dependencies for the migration. At this stage, the key area of focus should be on identifying the capabilities required by the application and how they relate to these dependencies. This will drive the relative timing of migration activities and help identify key areas of focus. The assessment should address three critical dimensions.
Starting a migration by evaluating an application's maturity with respect to these factors permits you to plan appropriately and avoid downstream surprises that create delays, increase costs, and lead to missed targets. It is difficult to understate the complexity of a migration, as current production environments, suites of supporting services, and the targeted cloud environment will continue evolving throughout the process. Uncovering linkages between services and applications not only allows intelligent planning upfront but enables that planning to flexibly respond to the changes that will inevitably occur during migration. When documented effectively, this evaluation should result in a clear to-do list for the migration process. This will help ensure projected migration schedules continue to align with ever-changing roadmaps.
"We recently experienced the most-significant growth our business has ever seen, requiring massive increases in our service capacity. We explored multiple platforms, and Oracle Cloud Infrastructure was instrumental in helping us quickly scale our capacity and meet the needs of our new users." — Eric S. Yuan, CEO, Zoom
As with any IT initiative, the cloud transition requires a series of investments to achieve its full value—especially if the targeted application was built for an on-premises hosting model. Applications deemed worthy to move to cloud will eventually become cloud native over time or be discontinued. However, the initial goal is usually to get an application to a cloud-release state.
What it takes to get your application from its current state to its cloud-release state is a product of a series of decisions and initial investments. Are you planning to simply lift and shift the application to a bare metal server (in which case most of the investment is in cloud infrastructure), or do you have plans to make the app cloud-ready prior to the move (in which case some investment will be required to move parts of the application stack to a cloud-based model (moving the database from on-premises to DBaaS or Oracle Autonomous Database for example)? If you've created hard-coded customizations to enable customer-specific capabilities, they will have to be refactored for a model where platform components are encapsulated and delivered via APIs as productized features. Hardware or platform dependencies will need to be removed in order to scale a highly distributed application in the cloud. Understanding these investments is a critical factor to planning for and achieving the financial objectives associated with the move to cloud.
The initial investment involves the development time and labor needed to make the required product changes associated with the stage of cloud migration we just discussed. Yet additional expenses must also be accounted for. A broad array of expenses that your organization is likely to incur during the transition include:
To a greater or lesser degree, each of these costs is a necessary component of the transition to IaaS. Each stand to impact your cost profile in a different manner. Development investment and migration execution expenses, for example, can fall within one-time buckets—even if the resources associated with this work may be fixed. The uptake of new infrastructure will result in a net increase in expenses for a period of time until stranded infrastructure expenses are eliminated. Some workforce and customer transition expenses, such as training or migration incentives, will represent one-time expenses. Others, such as workforce expansions or changes in customer contracts, will potentially result in new ongoing expenses.
Understanding how these dynamics will play out over time is essential for your organization to prepare and set expectations for the cloud transition. If your organization is enthusiastic about the dramatic benefits of cloud but lacks a clear understanding of the transition risk, you will be surprised by the initial, early-stage increases in expense, particularly as you absorb migration, overlapping infrastructure, and transition costs up front. Setting the right expectation and maintaining the visibility of incremental progress as it occurs are essential elements for maintaining alignment and discipline as the organization moves through the transition.
Cloud migration inventory
A cloud migration inventory is imperative for a move to cloud. What is a cloud migration inventory? In short, it's a list of all of assets in the fleet and associated critical data elements describing each asset. It's the application(s) targeted to move and all of their dependencies. The medium used to capture that data is irrelevant, and it is not uncommon to utilize several tools as the data will often span departments within a company. The required information is usually scattered across a range of production, sales, and operational databases. For example, a configuration management database may track technical dependencies and asset location in detail, down to physical servers and rack locations. However, it will not include the business and customer considerations that are vital to determining when and how customers will be notified of the transition. That information is often contained in repositories that are designed for operations and support stakeholders. Additionally, acquisitions, special use cases, and product silos may mean that information is further fragmented across multiple repositories.
The key purpose of the migration inventory is to provide a centralized view of the factors that you need to manage your transition to the cloud. For example: What is the asset? Where is the asset? What product does it support? What does it do? What customers does it support?
From the onset, it's important to realize that the blueprint is a living document. It must be flexible, as it will evolve over time—especially for companies with multiple applications or multiple versions of applications. The inventory will evolve as new issues surface and new needs are discovered. Even the underlying cloud infrastructure may change during the course of a migration, thus evolving the inventory yet again. The migration inventory should capture as much available data as possible—allowing you to begin initial planning—and then add layers of detail as the transition reveals new requirements.
Managing the migration inventory is a cross-functional project in its own right that must balance the need for detailed data with the work of collecting it. It also includes elements that identify dependencies, constraints, and resources, which will affect timing and speed, such as granular technical specifications, architectural approaches, customer requirements, and data transfer pathways. Too little information and the inventory is not useful. Too much, and it becomes a burden to maintain, which may rapidly fall out of date and use.
We recommend the following migration inventory framework as a starting point for cloud migration.
Migration inventory to operational inventory
While we have focused on migration inventory, the cloud transition ultimately presents two challenges. Most directly, it creates the need to plan, prioritize, and track migration activities. However, the migration itself will force changes to the data required for its day-to-day operational tracking. For example, postmigration configuration details about physical servers and racks will become irrelevant—even information about individual instances will become less important. At the same time, metrics such as overall usage and data egress may become critical, particularly as organizations adopt self-service models.
The creation of a migration inventory should begin the transition to these new, cloud-centric data schemas and processes. While the twin challenges of creating the inventory and migrating the application are separate projects, they should not be pursued in isolation. The migration effort is the leading effort, and it may be the first time an organization has created a detailed, consolidated view of its assets. It is a transformative moment that should form the template for new, postmigration inventory views. As discussed above, the migration inventory will need to be flexible and adaptable. If managed properly, the migration inventory will evolve into a valuable postmigration inventory management tool.
Piloting your way to cloud
Designing the infrastructure for hosting SaaS applications
As an ISV providing SaaS-based applications, you need secure, scalable, enterprise-grade infrastructure to host your services and manage your customers in an isolated fashion. The reference architecture depicted in Figure 3 below provides a validated framework that incorporates best practices, enabling you to host your SaaS applications on Oracle Cloud Infrastructure.
In this reference architecture, you deploy and manage multiple, isolated application instances. Each deployment is for a specific tenant and these individual tenant application instances are managed through a common management layer.
You can choose to either build all the tenant application instances from a single code base or offer customized versions of the application to each tenant. This pattern is ideal for SaaS customers that require complete isolation of the application environment.
Figure 3: A best-practices reference architecture for SaaS applications on OCI
For more details regarding the above reference architecture, please visit the Oracle Architecture Center. Further, we've created Terraform-based tools to assist in deploying the architecture for four tenants, along with a step-by-step guide. Finally, we always recommend following the Oracle Cloud Infrastructure best practices guide, which provide guidance across four common business goals: security and compliance, reliability and resilience, performance and cost optimization, and operational efficiency.
In addition to architecture changes, you need to think about how your services stack will change in the cloud. Core toolsets used for monitoring, network management, or security deployed in legacy environments developed for on-premises architectures will evolve for the cloud. Moving to the cloud provides the opportunity to expand the scope of what these tools address. Instead of primarily monitoring end points, cloud-based tools offer monitoring throughout the stack. Sometimes a cloud service provider will offer cloud or hybrid-based monitoring tools on top of core capabilities. In the case of Oracle Cloud Infrastructure, a combination of native monitoring, tagging, and auditing capabilities provide the ability to monitor the full service stack and often automatically remediate abnormalities found outside of specified norms. If you are using third-party monitoring tools today on-premises, those vendors may offer hybrid or cloud-based tools as well.
"The partnership with Oracle has been fantastic. This is why this whole magic with Cisco Tetration is happening." — Navindra Yadav, Founder, Cisco Tetration
Standing up your pilot program
As with any engineering effort, beginning with a small pilot program or prototype maximizes the odds of success by providing the piloting team and your organization with a sense of what can be done and how to proceed. Pilot and proof-of-concept programs identify and troubleshoot challenges without the time and financial pressures that come with full-scale, organization-wide change. By moving slowly and gaining familiarity with the new operational environment, pilot programs can help you manage the rate of change.
The pilot is an opportunity for a core group of developers and operations staff to explore the target cloud environment, learning the architectures, services, and operational models. This team builds a seed of practical knowledge, useful tools, and best practices as well as confidence, expertise, and experience. At the same time your team is building this knowledge, they are evolving the rules of the road for cross-team collaboration in a cloud-based environment. Cloud migration requires application teams to evolve from direct resource managers to consumers of services provided by other teams. A pilot lets application teams understand how service boundaries will change, build relationships with operations teams providing the services they will use, and learn how to advocate for their needs with these operations teams.
Pilots provide the following benefits:
"The versatility and the flexibility of Oracle Cloud at both the app and the database layer has resulted in about 50 percent savings from our previous cloud solutions in terms of infrastructure." — Jeff Demenkow, Vice President, Manhattan Associates
Managing a pilot program
The pilot is a learning experience for technical and operational staff as well as your executive and management teams. Executive and management teams should have continuous communication with pilot teams to help remove organizational roadblocks and ensure that the organization maximizes the learnings that come out of the pilot project (i.e., what worked, what failed, best practices, lessons learned, and standard patterns or antipatterns identified). This valuable information can be captured and then shared with the rest of the organization, ideally making subsequent cloud projects more effective and efficient. A pilot lets management test the assumptions that went into building their plans and clear up areas of uncertainty. While these assumptions will vary from organization to organization, pilots surface a few key challenges in any migration.
The key to a smooth migration is creating a solid foundation. The first phase of the migration will drive the development of a core set of services and platforms, which will gradually expand as the migration proceeds. Eventually, these core capabilities will need to scale to support the entire migration portfolio. As a result, it is vital that initial cloud releases not only succeed but create a runway for all of the following releases and upgrades.
Adapting to organizational change
Designing the infrastructure for hosting SaaS applications
Changes in your organization's delivery model and customer relationships can require new skills, knowledge, business processes, and mindsets. These changes can have a sweeping impact across the organization, which is why culture change is frequently said to be the most-difficult aspect of the cloud transition.
The sheer scope of these changes can create the impression that a cloud transition requires reorganizing on a large scale and bringing in workforce replacements with cloud experience and expertise. While changes in internal functional specialization and new hiring that is focused on cloud skill sets are major components of the cloud transition, you cannot afford the loss of the established processes, dynamics, and contributors that have been key to your success to date. It is essential that you balance the speed of organizational change against potential disruptions to ongoing business and customer experiences. Maintaining this balance involves a realignment of structural changes to the career-development capabilities that will allow existing employees to transition to the new operating model.
Transitioning a long-standing software business to cloud delivery models requires a tremendous shift in assumptions, technical know-how, and standard operating processes across numerous key business areas. While the amount of change required may be daunting, our experiences suggest that it is generally better to retain and invest in existing teams than to attempt a complete overhaul of cloud experts. Organizations planning similar transitions should look at how our GBU organization began with a decentralized, bottom-up assessment of change needs—permitting each team to create their respective migration inventories and service stack roadmaps—and thus identified the steps required within their respective areas of control. This approach allowed teams to align their programs to tangible change drivers while avoiding high-level assumptions about what they might require.
"As video meetings quickly became the connective tissue of today's new world, we saw our user count soar. To support that exponential growth, we looked at several platforms and chose Oracle's Gen 2 Cloud infrastructure for its strong security, outstanding price-performance, and world-class support to serve this new surge of users." — Vik Verma, CEO, 8x8
A successful pivot to the cloud both enables and is enabled by changes across the organization. Moving from a predominantly hosted or on-premises portfolio to a cloud-based business will require fundamental shifts in how your organization engages with its customers. However, the degree to which established business practices and assumptions change will be largely shaped by the scope of product change undertaken in the cloud transition.
Even in low-change scenarios, shifting to IaaS will drive shifts in business processes. Our GBUs identified two key opportunities for change in this context.
Organizations that address these changes—along with the technical change in their applications—will be better positioned to realize the full potential of the cloud migration.
Transitioning from offering a "shrink-wrapped" product, or even from a hosted product to an actual cloud service, is a journey that you and your customers will undertake together. In fact, it is this change to an as-a-service model that differentiates cloud from all previous hosting modalities. Every change to a cloud service will impact a customer's experience, from scalability to uptime to resilience. In some cases, the customer may be asking for—even demanding—the change to a new delivery model. In others, expectations for features, capabilities, and cost may be evolving in ways that can only be supported through a cloud-based delivery.
As you begin to involve your customers in your cloud strategies, you must prepare for both perspectives, excitement for the roadmap and reluctance to leave what is familiar. Responding to these perspectives requires clear, measured communication that indicates where the effort is headed without getting lost in technical details or raising red flags. This is a key moment to engage customer-facing teams inside your organization to ensure they understand the effort underway, the investment being made by the business, and the expected outcomes for the product and delivery. In doing so, your customer-facing teams need to be enlisted to translate this change into terms that will strengthen customer confidence in the service.
For customers who will be consuming the cloud service, the scenario can become a bit more complicated. There are customer segments that demand a cloud service; who understand the benefits that SaaS provides them in terms of efficiency and agility. However, as cloud or SaaS options have become table stakes, customers need to be educated about the capabilities and service-level agreements that distinguish a vendor's service rather than the value of cloud itself.
Not all customers are eager for a cloud service though. In particular, existing customers on hosted or managed services models may be satisfied with the current state, especially if they have bespoke service components or nonstandard environments and access models that are inconsistent with cloud delivery. Even customers that see the benefits of moving to a cloud service may be uncomfortable with changes to delivery terms or the service interruptions needed to migrate their environments.
Reassuring customers requires coordination and consistent communication across marketing, sales, support, and customer success teams. In an ideal world, the customer would not be aware that their workloads were migrated at all; one day noticing a performance improvement with no awareness of the changes that took place. The reality is that migrating services to the cloud often requires upgrades and periods of downtime, and potentially, changes in service terms or available functionality. Guiding a customer through these events—while also maintaining alignment to the overall transition timeline—is a complex feat, requiring more than an understanding of the benefits of the change. It requires buy-in on the changes taking place and alignment on the migration steps that have the potential to impact the customer's business.
"Besides the cost benefits of OCI over other cloud providers, we're now more agile. OCI has given us a new level of technological flexibility. We're moving into the future with technologies like Oracle Container Services and Oracle Autonomous Database so that we can continue to concentrate on delivering the best construction ERP software available." — Vince Di Piazza, Director of IT and Cloud Infrastructure, CMIC
Once a customer supports the benefits and changes that will accompany the cloud transition, the final step facing your organization is to actually move the customer's workloads to the new environment. This becomes a challenge of determining the optimal time for the migration and validation testing of the new environment. A customer that accepts that it will face a period of downtime will often still have strong opinions about when that downtime should occur.
While customer preference will be important to you, a host of other concerns must be balanced. Planning migrations involves a tradeoff of multitude of factors, including technical attributes of a product or service, the reconciliation of the preferences of all customers, internal resource limitations, and business objectives such as the consolidation/elimination of existing legacy data centers or the termination of deprecating product lines. To balance these conflicting priorities, include customer-facing teams in migration-planning activities, as they will be a key voice in representing market expectations.
Just as your organization must prepare itself for both a period of investment and migration as well as the ongoing technical and business process changes of a cloud delivery model, it must also prepare for both how it engages customers with regard to the migration and for a new status quo in the product and customer relationship.
Our GBUs responded to these needs first by reviewing how the transition would affect customers technically, operationally, and in terms of delivery commitments, isolating those that would require special attention, engagement, and potential changes to the commercial relationship. Efforts made to ready customer-facing teams are built on a similar perspective, involving collaboration between product, operations, strategy, and other teams to provide general cloud literacy while addressing specific product and customer changes.
This effort was about more than simply preparing customer-facing teams to engage customers. Bringing together core, cross-functional leadership to align on customer engagement also created valuable opportunities to expand what had been largely technically led programs into broader initiatives about revisiting the core value of our solutions, re-articulating what differentiates our products, and planning the best ways to preserve and grow that value within the market.
Preparing in advance
Designing the infrastructure for hosting SaaS applications
Throughout this playbook, we've provided best-practice guidance based on the lessons we've learned through migrating more than 60 GBU applications hosted across thousands of instances. Below we summarize the top-five challenges faced throughout our journey, as we believe they are applicable to any organization migrating applications to the cloud.
"When we looked at all the cloud vendors out there, we found that Oracle was very focused on HPC. Their bare metal offering, which was I believe the first in the industry, and had high-speed, low-latency networking, which is very important for us." — Piush Patel, Senior VP of Strategic Relations, Altair
"The Oracle GBU team was able to lower capex 80%, and reduce infrastructure costs 64% by migrating to OCI." — Mike Prindle, VP, GBU Cloud Architecture
"We needed our data platform to scale and deliver high performance at a lower cost. The migration of the data platform from AWS to Oracle was one of the most successful migrations at OceanX, and coupled with a significant performance gain with substantial cost savings meant the entire program was a tremendous accomplishment. This ultimately enables us to deliver to our clients a platform that allows them to make more-informed decisions, faster." — Vijay Manickam, Vice President of Data and Analytics, OceanX
Celebrating the results
This playbook is based on the learnings our Oracle GBU teams accumulated in migrating more than 60 SaaS-based applications to Oracle Cloud Infrastructure. These applications support core enterprise functions across eight industry verticals and more than 199,000 customers across the globe. A diligent, planned, and well-executed migration led to substantial benefits.
While this ISV playbook was based on the learnings achieved by our GBU teams, their effort was only one of several large migrations to Oracle Cloud Infrastructure. Taking into account revenue and number of customers across all of our SaaS applications, Oracle can be viewed as one of the largest ISVs in the world, and we understand the migration process. We have actually moved our entire portfolio of products, including Oracle Fusion Cloud ERP, Oracle Fusion Cloud EPM, Oracle Fusion Cloud HCM, Oracle Advertising and CX, and Oracle Fusion Cloud SCM to Oracle Cloud Infrastructure. These migrations are part of our transformation initiative that we call Oracle@Oracle. It was a multiyear project involving tens of thousands of applications spread across dozens of data centers.
Here are a few of the benefits we've seen as a result of these efforts.
Partnering with Oracle
We are helping ISVs expand their addressable market while increase their topline revenue growth potential. Send us an email at: email@example.com to learn more.
To learn more about why ISVs are choosing Oracle Cloud, please consider the following resources:
"When we evaluated the different decision points, OCI was very strategic to what we were trying to do in terms of our go-to-market strategy." — Rick Schrader, Senior Vice President of North America Sales and Alliances, Körberö