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.

Scalability

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.

Modernization

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

---

Standardization

Standardization 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

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.

---

WorkForce Software migrates their workforce management solution to Oracle Cloud Infrastructure and realizes a 30% increase in performance.

"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

Learn more

---

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.

• Exiting legacy data centers: Running a data center is expensive. Buildings, people, power, cooling, maintenance, and upgrades are just a few of the day-to-day responsibilities. Many businesses are actively working to reduce or eliminate their data-center dependence by evaluating application portfolios for candidates to move off premises. The priority is to move applications out of colocated, managed hosting, or on-premises data centers in an effort to reduce or eliminate capital expenses. Often a lift-and-shift strategy is utilized whereby the application is migrated as is to a bare metal server or virtual machine in the cloud.
• Evolving the technology stack: In this case, companies begin making incremental changes to applications that will require additional investment—but are also expected to bring more value—over time. An example of this would be replacing on-premises versions of Oracle Database with the cloud-based Oracle Autonomous Database without making major changes to the application itself. This is sometimes referred to as a move-and-improve strategy.
• Going all in on cloud native: The benefits of re-architecting an application from the bottom up to be cloud-ready might outweigh the costs of keeping a less-mature application in tact while implementing one of the scenarios mentioned above. Cloud native applications are highly distributed in nature—often constructed utilizing 12-factor principles—and are thus designed to be independent of the underlying architecture, meaning applications continue to run even when the infrastructure underneath it breaks. In short, it is worth evaluating whether this path makes sense for the target application, as the move to cloud will certainly be easier than moving an application that is tightly coupled with its underlying infrastructure.

To find out about how Oracle defines cloud native, the origins of cloud native apps, and best practices to follow when constructing them, read this ebook.

---

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.

1. Infrastructure requirements: Cloud decouples software from its underlying hardware or operating environments. High-maturity applications are essentially independent of their environment, relying only on a general infrastructure resource—such as a CPU or Kubernetes cluster—that scales easily in the cloud. Low-maturity applications depend on specific equipment, components, or environments provided, such as managed infrastructure or other dedicated systems. The extent to which your application will have hard dependencies on infrastructure components and configurations in the cloud must be first documented and eventually eliminated. It is not uncommon to find customizations (either made by you or your customers) that are tied to/coupled with the underlying infrastructure.
2. Services components: Cloud delivers supporting capabilities as standalone services operated and delivered independently from the application. High-maturity applications are architected around discrete components with minimal dependencies across the stack, allowing targeted changes and upgrades and maximizing uptime. Low-maturity applications are architected with large, tightly coupled components, which become highly interdependent and must be managed as a single entity. These services relationships must be documented for each application.
3. Operational readiness: Cloud changes technical architectures as well as working processes, skill sets, available tools, and operating models. High-maturity applications already run like cloud applications and use processes, standards, and toolsets that will work well in the cloud. Low-maturity applications will find critical support services missing from the cloud, have teams supporting them with unsuitable skill sets for cloud work, or use processes that would be disrupted by a move to the cloud.

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.

---

Zoom quickly scales and activates millions of concurrent meetings on Oracle Cloud Infrastructure.

"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

Learn more

---

Financial objectives

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:

• Development investment: Development labor required to re-architect the product or create accelerators for the migration effort, including automation to support activities such as database migration and application provisioning
• Migration execution: Labor resources required to provision new assets, migrate existing environments and data, and decommission legacy inventories
• Infrastructure uptake: Subscription fees accrued through the IaaS ramp, which will transition to a steady state, but represent new increases through the migration period
• Stranded infrastructure: Lingering data center and CapEx depreciation costs that accrue through the migration effort until they can be eliminated or written off
• Workforce transition: Expenses associated with training, educating, or restructuring existing teams or for acquiring new resources with required cloud skill sets
• Customer transition: Costs associated with changes to environmental features or service terms that cannot be supported in the new model, including new development, incentives, renegotiation of contract items, or customer attrition

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.

---

Cisco Tetration moves its core application to Oracle Cloud Infrastructure and realizes a 60x performance increase.

"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:

• A context in which to validate (or challenge) assumptions about portability of technologies—especially in cases where the technologies have always run in the same environment. This helps teams understand whether they are ready to migrate and identifies what needs to change in order to do so.
• An opportunity to confirm application/database readiness to integrate with services in the target environment. This tells teams what changes are required and when both the application and target services environment are ready for the migration to occur.
• The ability to build for the target environment, creating a foothold, which becomes a jumping-off point for the rest of the portfolio as they move to new services and a new environment. This gives teams strategic targets for their portfolio.

---

Manhattan Associates migrates their supply chain solutions to Oracle Cloud Infrastructure and saves 50% in costs over previous cloud solution.

"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.

• Training: Pilots test existing skills, revealing how prepared the organization is for the technical migration work. Management should use the pilot to evaluate technical proficiency, understand which tools and capabilities are most important to learn, and plan how to rapidly build (or hire for) skills in these key areas.
• Collaboration: Pilots expose how development, operational, and support teams will work together differently. Management should ensure that these teams actually work together during the pilot, exposing new requirements and building an understanding of how to operate in this new environment.
• Appetite for change: Pilots are a chance to find cultural barriers that will affect the broader migration. A group that has trouble in a pilot will have the same reaction at scale. The pilot is a chance for management to identify issues, deploy training, and adjust plans to account for the realities of their particular organization.

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.

---

8x8 keeps the world connected, lowers costs 80%, and improves services by moving to Oracle Cloud Infrastructure.

"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

Watch the video

---

Business impacts

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.

1. Replace CapEx-intensive physical infrastructure management with OpEx-oriented forecasting models that account for short-term fluctuations and long-term expectations
2. Evolve security and compliance teams that have been freed from traditional responsibilities to focus on delivering services components

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.

Customer alignment

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.

---

CMIC migrates their construction enterprise software to Oracle Cloud Infrastructure and sees 10x faster deployments.

"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

Watch the video

---

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.

1. Determining premigration development efforts
   Preparing an established application for cloud release can involve an extensive investment, particularly to bring a product to a cloud native state. Investment in cloud native application principles yields the highest benefit you can obtain from cloud while consuming a large amount of time and development resources to meet the end state. The longer it takes to get a product ready for the cloud, the more you delay access to the inherent, incremental benefits of moving to the cloud and potentially prolonging exposure to risks typically associated with legacy environments. At the same time, not all products will benefit equally, depending on their lifecycle phase and customer posture. Fully understanding and documenting the amount of development work to undertake prior to the migration is key to a successful move.
   
   The GBU fleet of applications is diverse, including products at all levels of the cloud maturity and lifecycle phases. While all the applications needed to be migrated to the cloud, they struggled with how much product change should be made prior to the cloud release. Finding the correct balance required the organization to assess each product’s lifecycle stage, growth potential, and the effort required to bring the product to the cloud. Based on these combined assessments, the GBUs determined the level of priority and expense that would be given to each product.
2. Determining the development mix
   How much engineering bandwidth to give to cloud investment readiness versus the development of new features and functions in response to market demand presented a difficult balance for the GBUs to strike.
   
   The GBUs did not lack alignment around the priority of cloud transition, but product teams did struggle with understanding how much work should be given to cloud capabilities that would improve customer experience and performance but weren’t replacements for the features that customers demand. Cloud development requires investment in underlying operational capabilities that potentially distract from the organization’s ability to respond to customer demand for new features. These trade-offs make it difficult to figure out how to distribute time between cloud readiness and product-enhancement initiatives.
   
   To respond to this challenge, the GBUs relied on the cloud maturity frameworks discussed in Chapter 1 to provide insight into the relative development investment required for each path. They then examined the ROI of each potential cloud transition stage and weighed that outcome against potential revenue contribution expected from new-feature development. This provided a common evaluation framework that could be used to determine the correct mix of effort, maintaining visibility to the target business outcomes.

   ---

   Altair chooses high-performance computing on Oracle Cloud Infrastructure and improves price-performance by 20%.

   "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

   ---

3. Understanding the fleet
   Whether your company has a single application or a large portfolio, there are many factors to be tracked and inventoried during a cloud migration. In order to fully comprehend what changes need to be made, you must fully understand the current inventory across existing application repositories as well as what is planned to be utilized in the cloud. If you have many applications to move, an existing inventory may not exist, or you may rely on tribal knowledge regarding the state of specific applications. Even companies that have a single, customer-facing application still need to inventory the entire application stack to determine what aspects will need to change upon a move to cloud. Understanding what requirements will change in the cloud and what the design needs to look like are critical aspects for documenting the work required to transition.
   
   Different types and amounts of work are required with respect to each application instance, depending on the characteristics of the instance (version, hardware/platform dependencies, customizations, customer access model, etc.). Further, application data may be spread across multiple systems of record.
   
   The Oracle GBUs are a consolidation of more than 30 acquisitions with a fleet that extended across 80 data centers and more than 12,000 application instances. Critical data related to these instances was highly fragmented and not necessarily managed in a consistent way across component product teams. Without this information, they could not effectively organize and plan migration labor. In order to create a clear understanding of what needed to be migrated, the GBUs had to launch a dedicated data collection and consolidation effort.

   ---

   "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
   

   ---

4. Prioritizing and organizing the migration effort
   Actually moving workloads can take a number of paths, ranging from copying images of existing VMs to installing a new instance and replicating the data; but all require some level of technical investment or labor commitment to complete. Multiplied across each product environment in the organization’s fleet, the amount and varying types of labor involved in migration easily become overwhelming. The resources available to complete it are finite and often also responsible for managing day-to-day operations.

   ---

   OceanX moves their business intelligence systems to Oracle Cloud Infrastructure from Amazon Web Services (AWS) and sees a 3x performance improvement.

   "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

   ---

   The GBU cloud transition required more than 3,000 individual migration projects. These projects were originally prioritized based on customer preference (i.e., prioritizing migration time frames based on consolidated customer feedback) or the migration readiness of a particular environment. Ultimately, this approach failed to help drive incremental business benefits over the course of the migration. Without common prioritization or coordination frameworks, the GBUs saw an inconsistent volume of migration activity. This burdened the teams responsible for completing migration work with alternating periods of high resource contention and wasted resource availability.
   
   In order to resolve these challenges, the GBUs created both a central program management office dedicated to migration and an executive oversight committee, responsible for prioritizing migrations against target business outcomes and identifying pivot opportunities.
5. Managing organizational change
   The changes involved in cloud transition require new areas of knowledge, skill sets, and process as well as other areas of cultural change. Managing these human-resource challenges can be more difficult than the technical components of cloud transition. To address this, the Oracle GBUs helped existing teams evolve into cloud teams by focusing on training. Managing the question of when to bring in new talent versus when to find mechanisms to otherwise evolve the organization required the GBUs to conduct workforce assessments against their major functional areas and product groups and then map the appropriate improvement initiative against each use case. If your company has multiple applications to move, consider where you can create foundational cloud knowledge that spans all products, such as security and general IaaS.

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.

• Consolidated 80 data centers to 11
• Lowered CapEx by 80%
• Reduced infrastructure costs by 64%
• Reduced software vendors from 28 to 10
• Reduced software expense by 42%
• Moved to daily releases of software
• Decreased provisioning time by more than 98%
• Decreased planned downtime by more than 98%

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.

• Infrastructure – Achieved 99.99% availability across our portfolio of applications with 30% cost savings and 2x–10x performance improvements
• Finance – Gained the capability to close books and report earnings in less than 10 days
• Human resources – Reduced talent review cycle time by 70%
• Supply chain – Reduced supply chain planning cycle from 1 week to 48 hours—a 71% improvement
• CX – Reduced campaign lead time from 4 weeks to 5 days—an 82% improvement
• Sustainability – Reused or recycled 99.4% of the decommissioned equipment collected at Oracle in FY19

Partnering with Oracle

We are helping ISVs expand their addressable market while increase their topline revenue growth potential. Send us an email at: oraclecloud-isv_ww@oracle.com to learn more.

To learn more about why ISVs are choosing Oracle Cloud, please consider the following resources:

• isv.oracle.com
• Oracle@Oracle program for ISVs
• Explore the Cloud Hosting Considerations and Patterns microsite

---

Körber consolidates warehouse management systems onto Oracle Cloud Infrastructure and runs 40% faster.

"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ö

Watch the video

---