P2T vs Cloning : Choosing the Right Fusion Applications Tool for Your Project


Oracle Fusion Applications (FA) comes with two very useful tools –  Fusion Applications Production to Test (P2T) and Fusion Applications Cloning (Cloning).  These help customers implement multiple FA environments for different purposes like production, testing and  development on Enterprise level projects.

These tools come under the topic of Content Movement and are detailed in the FA documentation and fall under the maintenance phase of Applications Lifecycle Process (discussed here).

P2T and Cloning have similarities – especially both duplicate a Fusion Applications system to mimic another such system.  Yet, they differ in their purpose, applicability and implementation.  This can raise questions on which tool is the best choice for a specific purpose or a project step.  This article helps make that decision by providing detailed comparison of the two tools from intent to usage.


Main Article

The Fusion Applications Content Movement book provides detailed information on the requirements and process of P2T and Cloning.

Cloning is the process to replicate a complete Fusion Applications environment into a similar one.  Thus, all Fusion Applications binaries, configuration, databases and data including security are duplicated from a source FA environment to an empty (just the OS) target environment.

P2T stands for Production-to-Test.  The P2T process copies data including security (but not binaries or deployment configurations) from a source FA environment into an existing target FA environment.  The main envisioned usage of this process is to copy production data into a test environment so that testing can be done separately without impacting the production system.  Hence the name P2T.  Technically, P2T can be used to move data from any FA source to any FA target.

The major aspects to consider in choice of the method would be the requirements of the project work at hand and the resources available including the time to accomplish it.  It is strongly suggested to start by charting out of the project requirements and then use key points from the comparisons below to get clarity in making decisions.

Uses of P2T

Some examples of where P2T can provide key benefits to an enterprise FA project :

1. Validate patches using production data in a test environment before applying that patch to a production environment.
2. Test functional or development tasks and external integrations with actual production data including security data (users/roles/policies).
3. Perform performance load testing with production data to size, plan for and minimize load issues in actual prod environment.

Key benefits of P2T are :

1. A clean way to periodically refresh production data to another environment for testing patches and diagnosing issues without impacting production environment.

2. Using production data for development to eliminate risks from new/changed software.

3. Conduct performance tuning and sizing with latest data but outside of production to maximize production system availability.

Uses of Cloning

Some examples of where Cloning can provide key benefits to an enterprise FA project :

1. To copy a freshly installed system to create a test or development environments instead of fresh provisioning.
2. To diagnose production issues without impacting production by cloning the system and using the clone for diagnostics.
3. To preserve a copy of a system and refresh periodically from it after some development or QA use.
4. To distribute one copy to multiple users so all can have the same setup for further development or training.

Key benefits of cloning are :

1.  Rapid creation of a Fusion Applications environment (typically in a day) instead of provisioning a new one.  In cases where an environment is fully configured and ready for functional use, this can save several days or even weeks of work.

2.  Replicating an existing environment for purposes of testing or training.  The new environment will have all the functional features and data in it unlike a fresh install.

3.  The work is done at data center level using just infrastructure knowledge ((hardware/VM/network/storage/OS/DB) and personnel. Fusion Applications functional knowledge is not needed and makes the process simple.


P2T vs. Cloning

The following table provides a detailed comparison of the P2T and Cloning processes grouped by topics different phases of the work involved.






  • Replicate FA data quickly for other uses (eg. functional, development, performance tests, patch test, audit etc.).
  • Periodically refresh production data to another environment
  • Replicate full FA system including all security details to make a new environment.
  • Clone a FA system (typically once) and avoid fresh install – but allow for external URL change so they can run in parallel. Used for deploying new environments.


  • Source & target can run in parallel before and after P2T.
  • Copies just source data (including security / customizations) to target.
  • Reconciles IDM one-way from source to target with exceptions allowed.
  • Does not change target system user passwords and also blanks out functional user passwords in target by default to not carry over prod passwords.
  • Source and target can run in parallel before and after cloning.
  • Copies complete source environment (binaries and all data) to target.
  • Copies complete IDM data from source to target with no exceptions allowed.
  • Carries over all passwords from source to target as is, and then, resets system user passwords in target (for better safety and to preclude any end user errors). Normal functional user passwords remain as is.


  • A working FA target and source FA DB backup must exist – often they already do and so additional resource need is rare.
  • Source and target should be working and allow for IDM replication (ldap calls) between them.
  • Source and target FA must be same version/patch levels.     
  • A cold backup of source FA DB (not IDM DB) and export of some target schemas are needed. Source FA DB will be copied over target during the P2T followed by import of the few exported target schemas.
  • The FA deployment topologies and configuration of source and target must the same – eg. what FA servers run on what hosts, the LDAP location of IDM and FA jpsroot entities, FA filesystem directory etc.
  • The hostnames used for FA internal endpoints need to be identical in source and target (ie. internal FA hostname entries need to be copied into target /etc/hosts files to not conflict with DNS).
  • Typically target infrastructure does not exist and provisioning hardware/network/storage/OS needs cost/time resources.
  • Target is an empty environment with just OS running and hardware setup and sized to mimic and host the source FA.
  • Target starts without FA and ends with same FA as source.
  • A complete cold backup of entire FA source environment (filesystems and DBs) is needed. It will be copied into the empty OS environment of the target.
  • The FA deployment topologies and configuration of source and target must the same – eg. what FA servers run on what hosts, the LDAP location of IDM and FA jpsroot entities, FA filesystem directory etc.
  • The hostnames used for FA internal endpoints need to be identical in source and target (ie. internal FA hostname entries need to be copied into target /etc/hosts files to not conflict with DNS).


  • Once initial process is streamlined, periodic refresh is quick (typically done within a day).
  • Short downtime needed for target during P2T.
  • P2T time taken is mainly for (not in any order) :

   – manual prerequisite work, especially to sync source/target patch levels.
   – copying FA DB into target and packing of source data.
   – IDM LDAP replication from source to target

  • Needs admin access to FA, IDM, DBs, filesystems and OS.
  • Once the prerequisites are ready including discovery workbook (ie. FA source/target info and target hardware/OS/storage) the actual cloning process itself is relatively quick (about 2 days).
  • No source downtime needed during Cloning work.
  • Cloning time taken is mainly for (not in any order) :

   – manual prerequisite work especially to create target hardware/OS/storage.
   – copying source FA files and DBs into target
   – post-clone steps

  • Needs admin access to FA, IDM, DBs, filesystems, OS & storage.


  • Best used to refresh production data into test environment. While periodic repeat of P2T is perfect usage, avoid any possibility of cycling data back to source (production) environment.       
  • Transaction data is copied from source to target but some historic logs and pending notifications that may conflict with source environment are left out and this needs to be minded for corner-case system audits.
  • Source data is copied to target and so data issues may spill to target and functional validation is always good. However, P2T does allow exceptions to IDM reconciliation.
  • No limitations on how often to replicate (even cyclically) provided each target environment is self-contained by ensuring that FA internal hostnames do not conflict between environments.
  • Complete data is replicated from source into target, but in-flight transactions are truncated to preclude any target transactions pointing to source and this needs to be minded for corner-case system audits.
  • There are no exceptions in moving data from source to target – complete data comes through and only changes made are to delete pending transactions and change target system passwords.


The key factor that dictates decision making would be the purpose of creating the duplicate system – especially if it is a permanent setup that will repeatedly refresh data or if it is a one time effort for a specific purpose, such as quickly stamping out a new environment.

Best Practice Tips

1.  To perform Cloning or P2T (at least the first time to setup the process) admin access is needed in all FA layers – hardware/VMs, Storage, Network, OS, DB, IDM and FA and so if the work is spread between different teams be prepared to chart a project plan to keep resources ready to avoid delays.

2.  Once Cloning / P2T process is streamlined, they can be automated quite a bit to maximize data center workflow and efficiencies and the resource needs can be limited to just the data center infrastructure teams with minimal or no FA technology knowhow.  Cloning using EM 12c is discussed here.

3.  One of the best ways to ways to validate the target environment is to apply the latest patch bundle or even upgrade to a later release if possible as these steps often include data validations within FA.


P2T and Cloning are two tools that help Enterprise Data Center operations maintain multiple Fusion Applications environments.  This article provides the overview of their purpose, benefits and usage including a detailed comparison to help make the right choice based on the project requirements and resources.



  1. Noha Khalil says:

    I would like to know if the cloning is the T2P which is not possible via the standard Cloud Ops process? For example, if the production configurations after the upgrade went bad and there’s urgency for the customer to work on production instance for payment and other activities whereas the test is working perfectly after the upgrade, is it possible to do test to production? Can this considered FA cloning? Do we need an exceptional approval for it? Please elaborate.

    • This article and the LCM tools discussed are mainly for on-premise use. Since this article, the Oracle SaaS Cloud offerings have enhanced and made deeper in-roads with customers where these LCM tools have slightly different scope. In SaaS Cloud, the focus is P2T (not T2P) from business and data integrity perspectives. Your specific issue on upgrade corruption may not be a good example as upgrades are well tested and either they fail or pass (ie. cannot pass and be corrupt) and so if there is indeed an issue with upgrade, they will fix it right away or revert to pre-upgrade backups and redo the upgrade. Using T2P as alternative for such cases is not recommended.

Add Your Comment