X

Best Practices from Oracle Development's A‑Team

An approach to separate your Oracle Fusion Applications Cloud for divestiture

Bala Mahalingam
Consulting Solution Architect A-Team

Suggested reading time: <15 minutes

Introduction

As you are currently using Oracle Fusion Applications Cloud, separating your existing application, functional processes, and data to enable the divestiture is a project. This blog is updated in continuation from my previous blog and will provide you with an approach and guidelines that you may use to plan your implementation.

Implementation approach

 

Fusion applications environment refresh & Deployment

Approach

  • Leverage environment refresh (P2T, T2T) to create a new instance for the implementation.  Export the required setup data, configurations, and required master, transactional and operational data and import to target instance for a new entity (company).

Advantages

  • Existing functional configurations to be migrated from the production instance

  • Required data only will be migrated with no clutter inside the new system.

  • Purging/deletion of existing company’s data not required

  • Easier to test and troubleshoot on technical issues

  • Clean cutover with segregation of data. (New company’s production instance will have only required data)

  • Additional security rules setup required

  • Historical GL data can be migrated over as needed as a post-implementation task.

Disadvantages

 

 

  • Regression testing for all technical components (integrations, custom reports, PAAS extensions)

  • Additional setup and configurations will be required after FSM import

 

This blog is focused on providing an implementation approach for separating currently deployed Oracle Fusion Applications Cloud for divestiture by leveraging environment refresh & migrating your required setup and application data. 

Fusion applications environment refresh & Deployment

Let us consider a fictitious customer “Vision Corporation” is planning to separate part of their business to a new company named “DIVESTED Corporation”. Currently “Vision Corporation” is running their business with Oracle Fusion Applications Cloud. With its business decision, their  application should be separated along with the relevant data.

The diagram below represents the target state of the divestiture requirement.

Assumptions

The following assumptions were made for the solution discussed here:

  • One or more modules of Oracle Fusion Applications Cloud (Example: Financials, Human Capital Management, Order Management, Sales Cloud) have been deployed in one Global Single Instance (“GSI”) production instance.

  • The existing functional or process will be used in the new company as-is

  • Only new company-related data will need to be migrated, including historical data if required from your existing Oracle Fusion Applications Cloud.

  • All other applications and technology used for integration migrations will be handled separately and not included in the scope of this blog.

  • Any self-service applications such as supplier portal, supplier product portal will be handled separately and not included in the scope of this blog.

  • Each “entity (company)” has its ledger and business unit(s) configuration. Both entities may or may not share the same chart of accounts (COA) and accounting calendar.

  • The existing production instance will continue to have both entity's data, and the new production instance will have only relevant data required for the new company.

  • New company’s employees will be migrated to the new application and will be disabled in your existing production application.

High-level solution

The best approach for enabling your divestiture with Oracle Fusion Applications Cloud is combining the standard environment refresh process and migration of required setup data, configurations, master, transactional and historical data as required to create a new Production instance for the new entity.

This may be achieved with 2 phases

  1. Readiness phase – Plan your divestiture implementation processes, test the process and get ready for the launch.

  2. Launch phase – Launch will complete the enablement of deployment with a new Production instance for the new entity.

The table below provides guidelines for both phases:

Readiness Phase

Launch Phase

  • Plan to review the approach with Oracle and discuss the environment refresh (P2T, T2T) feasibility and provisioning requirements

  • Clearly define your solution architecture and thoroughly plan and prepare the implementation tasks

  • Subscribe additional non-production instances as needed

  • Choose the right & trusted implementation partner

  • Design and thoroughly document the enterprise structure model for the new company

  • Develop a repeatable process for setup and data migration

  • Create a checklist with the required steps to be used for iterations

  • Start planning the launch phase checklist

  • Plan readiness phase for at least two iterations

  • Plan to handle the privacy and sensitive data (PII) and compliance (GDPR or other)

  • Plan & procure licenses for the new company

  • Make sure that provisioning is appropriately done by Oracle to help environment refresh (P2T, T2T)

  • Tune the launch activities

  • Plan for incremental data loads (if needed)

  • Do not miss out on the post-launch tasks such as disabling new company users in the existing product instance, create users and roles in the new company instance if needed.

 

 

 

Readiness Phase

The objective of the readiness phase is to plan and prepare Oracle Fusion Applications Cloud for the divestiture launch.

You will be refreshing your TEST (VTEST) POD/instance/environment with your existing PROD (VPROD) instance using the P2T (Production to Test) environment refresh process. Then you can migrate setup and configurations using Functional Setup Manager (FSM) export and import functionality. Refer to the best practices for setup data migration between environments in the FSM documentation. After verifying the functional setup & configuration, Export only required data from the TEST instance and import into another TEST (VADDL) instance. Thoroughly test and iterate the process as needed. Record all the additional setup or configurations that need to be performed. This process is repeatable and will be reused for the launch phase.

Note: VPROD is your existing production Oracle Fusion Applications Cloud instance. VTEST and VADDL are your TEST Oracle Fusion Application Cloud instances. During the readiness phase, you may use existing TEST instances or subscribe to additional TEST instances to design and develop the repeatable process for the launch phase. For example on the diagram below, VTEST and VADDL are two TEST instances of your VPROD production instance.

The diagram below provides high-level process/steps:

High-level steps of readiness phase are given below:

SL #

Step description

1

Production to Test (“P2T”) - VPROD to VTEST

2

Migrate setup & configurations from VTEST to VADDL using Functional Setup Manager (“FSM”) export and import process. Perform additional setup and configurations as needed. Document the configurations.

3

Test the functional setup & configuration migrations in VADDL

4

Export required business/application data for the new company from VTEST;

  • Migrate or setup and verify the required users, roles in the new instance

  • Extract/export required for master, transactional/operational data

  • Prepare data for import templates**

5

Import required business/application data to VADDL using FBDI

  • Consider approval rules, custom BIP reports, users, roles

6

Test functionality in VADDL

7

Document additional setup/config as needed

8

Document additional data alignment as needed 

** File Based Data Import (“FBDI”) for Enterprise Resource Planning (“ERP”), Import Management for Sales/Service/CDM and HCM Data Loader for Human Capital Management (“HCM”)

Additional guidelines

  1. Create an enterprise divestiture strategy that covers all the required applications and integrations that needed to be separated for divestiture. This blog is focused only on Oracle Fusion Applications Cloud. If you are using other Oracle cloud services (for example Enterprise Performance Management (EPM), Marketing (Eloqua), B2C Service cloud, Integration Cloud, Oracle Infrastructure Cloud, etc.) consider additional planning for the migrations.

  2. Plan your integration strategy for divestiture (migration & testing integrations)

  3. Explore the options of exporting selective data, and plan your data export & preparation effort

  4. For importing application data, please refer to the appropriate module’s documentation. (File-based data import (FBDI), Import/Export Management, Data Loader, etc.)

  5. For high volume data, plan your effort for optimizing the migration (export & import) processes.

  6. Make sure that all required users, roles are available and created as per the business needs

  7. Subscribe to additional instances if required.

  8. If you have Single Sign-On (SSO) capabilities, you need to plan to configure & enable SSO for new and existing users.

  9. Do not miss out on the configurations of whitelisting or other security-related setup that are required for the new company.

  10. Plan your P2T tasks based on your needs well in advance and create environment refresh requests based on your dates to avoid delays.

  11. Plan your T2T tasks if needed for training / other testing activities as needed.

  12. Do not miss out to test reports, scheduled jobs, external-facing modules (like supplier portal)

  13. Additional information on configuring and extending Fusion applications is available in my other blog.

Launch Phase

The objective of the launch phase is to enable Oracle Fusion applications cloud in production for the new entity.

You will be refreshing your TEST (DTEST) POD/instance/environment with your existing PROD (VPROD) instance using the P2T (Production to Test) environment refresh process. Then you can reuse both the setup & configurations and application data migration process to migrate from DTEST to DPROD. After completing the launch, request a P2T from DPROD to DTEST. This will replace the DTEST instance with only the new company data.

Note: VPROD is your existing production Oracle Fusion Applications Cloud instance. DPROD is the new production instance and DTEST is the non-production (TEST) instance for the divested company. 

High-level steps of the launch phase are given below:

SL #

Step description

1

Request environment refresh P2T to VPROD to DTEST

  • Note: This P2T is a special request from your existing production instance to the new company's TEST instance. You need to specify the details on your environment refresh (P2T) request. As mentioned in the readiness phase guidelines, you would have reviewed the approach and discussed the special request for P2T with Oracle as specified in the Readiness phase guidelines. 

  • Test the refresh, and make the required configurations or setup changes by reusing the test scenarios from the readiness phase

2

Migrate setup & configurations from DTEST to DPROD using FSM export & import

3

Export required business data from DTEST (only the new company’s data)

4

Import required business data into DPROD using FBDI

5

Verify functionality, integrations, reporting in DPROD (Quick test) before cutover

6

Request and perform P2T from DPROD to DTEST. This will replace DTEST with the new company's production data. 

 

Additional guidelines

  1. Make sure that all required users, roles are available and created in the new company’s production instance as per the business needs.

  2. Do not miss out on the Business Intelligence Publisher (“BIP”) reports, approval rules, and integration-related setup changes

  3. Plan your post-launch tasks to be performed both on the new company’s instance and existing instance (for example disabling the new company users in the existing production instance, assigning the right roles on the new company’s instance)

  4. Plan your P2T tasks based on your needs well in advance and create environment refresh requests based on your dates to avoid delays.

Conclusion

When Oracle Fusion Applications Cloud is currently deployed, this blog provides guidelines for your organization’s divestiture readiness. This approach, which is repeatable and scalable, can be leveraged for any type of divestiture initiative. You may use this approach as a baseline and tweak it with additional instances and plan accordingly based on your requirements. I hope this blog will help you plan your existing Oracle Fusion Applications Cloud separation project efficiently for your successful divestiture. Finally, I would like to convey a special thanks to Sanjay Sil (sanjay.sil@oracle.com), Oracle Consulting, for his contribution and support.

References

Note: Always refer to the latest documentation.

  1. Support Documents

    • Oracle Applications Cloud Service Definition - Environment Refresh (Doc ID 2015788.1)

    • Cloud Hosting: Scheduling Environment refresh for OCI Pod (Doc ID 2658462.1)

    • Oracle Applications Cloud Service Entitlements (Doc ID 2004494.1)

  2. Functional Setup Manager documentation

Be the first to comment

Comments ( 0 )
Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.Captcha