Updated 19-May-25

Phasing Your Journey to Cloud

Typically, large or complex organizations break their journey to the Cloud into two or more steps. The objectives are:

  • Reduce the implementation’s complexity and hence, limit risk.
  • Allow incorporation of lessons learned into subsequent rollouts.
  • Deliver flexibility in terms of both scheduling and financial commitments.
  • Reap benefits of Oracle Cloud earlier.
  • Ensure that users and implementation teams have sufficient bandwidth.

We consider two phases of your overall Cloud implementation: the pilot and subsequent rollouts.

Pilot Implementation

The pilot implementation is the first Oracle Cloud applications’ implementation in a subsidiary or business unit. It establishes corporate standards, defines shared reference data, and develops common integrations / extensions. Subsequent rollouts will reuse many elements of the pilot implementation.

Global Business Practices

The pilot implementation presents an opportunity to refine and promote corporate business practices. Business process standardization boosts corporate visibility and control through improved data quality and ease of interpretation. It also lays the foundations for the introduction of shared services.

Avoid the temptation to lift and shift legacy processes and, especially, customizations to Cloud. Instead, carefully consider how legacy procedures address underlying business requirements. You may find, for example, that many existing procedures are no longer necessary, workaround legacy limitations, or are rarely used. Take advantage of Cloud ERP’s configuration and personalization features as much as possible. Adopting best practices offers enormous benefits since Oracle Cloud configuration is upgrade safe. You will no longer be constrained by the cost and risk of upgrades.

Note, however, that local regulation may necesitate limited exceptions to global corporate standards. For example, in some countries, invoices must be chronologically and gaplessly sequenced. Compliance with the requirement is burdensome from a business perspective. Therefore, it makes sense to configure gapless sequencing only for countries that need it.

We recommend that you document the applicable corporate business practices and procedures. Establish a procedure to assess and approve exceptions in subsequent rollouts.

Enterprise Structures and Reference Data

To support corporate business practices, the pilot implementation defines enterprise structures and reference data shared between subsidiaries and lines of business. Examples include a corporate chart of accounts (COA) or other setups that you plan to reuse in each ledger or business unit. Shared reference data reduces maintenance, minimizes discrepancies, accelerates consolidation, and eases corporate reporting.

Even though the pilot implementation’s footprint is limited, you should consider the global implications of the decisions you make. For example:

  • Is the corporate COA suitable for all geographies and lines of business?
  • Does the ledger design allow for secondary ledgers for highly regulated countries?
  • What are the requirements for reporting in corporate currency across all regions?
  • Should payment methods be global, regional, or locally defined?
  • More

Again, we recommend that you define and document a global design that contemplates local exceptions. For example, some European countries required locally registered legal entities to submit financial statements using a specific chart of accounts. A subledger level secondary ledger for these countries is an option.

Consider Enterprise Structures best practices and cross pillar dependencies. The white paper available on My Oracle Support (MOS) note Cloud ERP Enterprise Structures White Paper (Doc ID 2415848.1) summarizes enterprise structures best practices and highlights cross pillar dependencies. For example, it details considerations when implementing Cloud HCM before Cloud Financial Management and vice versa. You will also find enterprise structure best practices covered in ERP ACE blog posts.

End User Participation

We recommend involving end users in the early stages of the pilot implementation. Their contribution ensures that underlying business requirements are properly understood and proposed solutions address them. Participation boosts understanding and acceptance of design decisions. Failure to solicit comprehensive input prior to user acceptance testing (UAT) risks sub-optimal solutions and user reluctance to adopt Cloud.

Integrations and Extensions

Integrations and extensions built to support the pilot implementation can be reused or form the basis for subsequent rollouts. The ability to reuse integrations and extensions across the enterprise depends on shared reference data and common business practices.

Again, anticipate the requirements you will encounter in subsequent rollouts. For example, by separating transformation from validation logic in integrations and extensions.

Data Migration

Subsidiaries often use the same legacy ERP. The tools and lessons learned from the pilot implementation’s data migration will apply to subsequent rollouts.

Even if different ERP solutions are used in some subsidiaries, you can take advantage of the pilot implementation’s investment. Separate the data migration logic from its validation logic. Much of the validation can be reused in subsequent rollouts.

Training and Support

End user and support desk training can be prepared and reused in subsequent rollouts. Bear in mind that you will need to accommodate local exceptions and perhaps, languages.

Choice of Pilot Entity

Factors that influence the choice of initial subsidiary and / or business unit include:

  • Burning platforms or other IT infrastructure pressures. For example, recent acquisitions that have not yet  adopted corporate IT systems and policies are sometimes selected.
  • User numbers. A small number of users simplifies training and aids reaction to post go-live teething issues.   
  • Transaction volumes. Lower volumes offer greater agility and hence, ability to react to implementation and data migration challenges.
  • Applicability of the organization’s business processes to the wider enterprise. Selecting an atypical business unit or subsidiary will reduce the applicability of the pilot’s standards to other parts of the business.
  • Executive sponsorship. The availability of an empowered and committed executive sponsor is key.
  • Complex regulatory regimes. Assign those countries to later rollouts to allow more time to prepare.

Pilot Implementation Steps

The pilot implementation absorbs more time and resources than subsequent rollouts. It is common to break it up into discrete steps which go into production at different times.

To avoid building short-lived integrations, implement highly interrelated business processes in a single step. For example, procurement, invoice processing, and disbursements are highly interrelated within the procure to pay flow. Hence, they are normally implemented at the same time. PO matched invoice flows are rarely implemented without implementing Cloud Procurement.

Common groupings of applications include:

  • General Ledger. Optionally extended with selected Enterprise Performance Management (EPM) applications such as Financial Close (FCCS), Enterprise Data Management (EDMCS), or Profitability and Cost Management (PBMCS).
  • Procurement. Optionally extended with Expenses, Sourcing, or Procurement Contracts.
  • Assets.
  • Receivables and Advanced Collections integrated with external billing systems.
  • Order to Cash. Optionally extended with Subscription Management or Revenue Management (RMCS).
  • Supply Chain Management (SCM).
  • Manufacturing.
  • Human Capital Management (HCM).
  • Project Management and related features in Procurement and Financial Management.
  • Account Reconciliation (ARCS).
  • Accounting Hub (AHCS).

Note that above groupings do not necessarily dictate an implementation order. It is common for HCM to be implemented before or after Financial Management but, rarely in parallel.

Multiple discrete business processes may use an Oracle Cloud feature and hence, go into production at different times. For example, Cloud Procurement supports both direct and indirect procurement. Since they rarely share suppliers and purchasing policies, they lend themselves to separate implementation phases.

Order of Pilot Implementation Steps

Minimizing dependencies and hence, effort also determine the order in which business processes migrate to Cloud. Other factors include the desire to obtain a quick win or an urgent need to replace a burning platform.

General Ledger is a common first implemention project because journal entry data structures are similar across source systems, unlike customer or supplier invoices. Extraction of Oracle General Ledger journals and balances to the corporate GL and reporting platforms using BI Cloud Connect (BICC) is straightforward.

The indirect procure to pay flow often comes next. Depending on the industry, Project Management and Assets may be implemented together. To ease communication and bank statement reconciliation, disbursements for direct procurement are often included.

Simplified sample transition from legacy ERP to Oracle Cloud

Legacy GL and source system accounting re-directed to Cloud General Ledger

In the first implementation step:

  • Account in legacy ERP subledgers (for example, payables) and integrate journals into Cloud General Ledger. If highly complex transformation is necessary to convert the legacy chart of accounts (COA), the Accounting Hub Cloud Service (AHCS) could be considered.
  • Re-direct journals that flow in from upstream applications from the legacy general ledger to Cloud General ledger. If necessary, these migration can be staggered in separate projects.
  • Once, the external feeds have been re-directed to Cloud General Ledger, it becomes the General Ledger of record for the deploying entity.
  • Users take advantage of Cloud ERP’s General Ledger and financial reporting capabilities.
  • All manual journals, allocations and other financial processing is performed in General ledger.

Legacy Procure to Pay applications migrated to Cloud ERP

In the second implementation step:

  • Implement the first end to end subledger business process in Cloud ERP. For example, procure to pay.
  • Deprecate the corresponding feeds from the legacy general ledger.

All legacy subledger applications migrated to Oracle Cloud ERP

In the third implementation step:

  • Implement remaining subledger business processes in Cloud ERP.
  • Retire the legacy ERP.

The order in which business processes and applications are migrated to Cloud vary considerably based on the Cloud application footprint, industry, transaction volumes, and internal priorities.

Enterprise Performance Management (EPM)

EPM caters for centralized business functions such and consolidation, financial reporting and planning and budgeting. It is optimized to ingest balances from legacy and subsidiary ERPs and perform COA and calendar mappings. EPM applications are therefore ideal to deliver a consistent centralized processing and reporting platform across legacy and Cloud ERPs throughout the journey to the Cloud.

Subsequent Rollouts

Since much of the groundwork has been prepared during the pilot implementation, subsequent rollouts should demand less time and effort. Consolidate pilot implementation steps into a substantial functional scope before embarking on a subsequent rollout.

Fewer temporary integrations with external applications will be necessary. For example, once General Ledger becomes the GL of record for a subsidiary, outbound integrations from the legacy GL can be retired. A larger functional scope also means less go-live related disruption to the business.

A typical scope for subsequent rollouts is all ERP, HR or SCM related business processes.

Like the choice of pilot implementation entity, the order in which you extend the implementation to other subsidiaries and / or lines of business depends on many factors.

Finally, customers often select a different system integrator (SI) to support subsequent rollouts. Ensure that the pilot implementation’s decisions are adequately documented. Plan for an orderly handover to the new SI and affected user communities.

Continuous Innovation

Complex enterprises with multiple subsidiaries and business units often incrementally extend the implementation scope on an ongoing basis. New acquisitions are rolled into the corporate Cloud solution. Additional features or applications expand its functional scope.

The continuous innovation inherent in Cloud calls for a permanent business process to oversee the evaluation and adoption of new features. It also ensures that end users are aware of enhancements that will impact their area of responsibility.

For more details, see the ERP ACE blog: Harness the Business Value of Quarterly Updates

Conclusion

There are compelling reasons why a large or complex organization should break their Cloud implementation into several implementation steps. It will reap most benefit if the pilot implementation anticipates key requirements to be encountered in subsequent rollouts.