1. Stop all managed servers, the admin server, and the node manager.
2. Back up WebCenter Content file system. For detailed information, see Recommendations for WebCenter Content in Disaster Recovery Guide.
3. Back up WebCenter Content database using your preferred method.
4. Install the same JDK version on the new host as the one on the old host.
5. Install Fusion Middleware infrastructure's binaries to the same directory paths on the new host.
6. Install WebCenter Content's binaries on the new host.
7. Install the same patches on the new host as were applied to the old host.
8. If WebCenter Content is being migrated and the vault and weblayout directories are on a shared/remote file system, unmount them at this time.
9. If WebCenter Content is being cloned, copy the vault and weblayout directories from their old locations to their new locations.
10. Move the ucm directory out from the DOMAINHOME directory on the existing system. This directory typically includes the vault (DOMAINHOME/ucm/cs/vault) and weblayout directories (DOMAINHOME/ucm/cs/weblayout) of WebCenter Content that should not be included when the domain template is built. The domain template is written to a single .jar file which cannot grow to include the potential size of the vault and weblayout directories.
11. There are a few scenarios in which the database will be moving as well. One such scenario is when WebCenter Content is moving to the Oracle Cloud. A second scenario is when the database is moving to a new infrastructure for an on-premise migration. A third scenario could be that WebCenter Content is being cloned. In any of these cases, the database schemas are assumed to be available in their new database instance and reachable from the new hosts on which WebCenter Content will reside. When the Configuration Wizard (config.sh) is run, additional steps will need to be taken to ensure connectivity to the database schemas in their new location.There are three objects within the system schema that are required for Fusion Middleware to operate properly, especially when it comes to upgrades. These objects are: schema_version_registry view, schema_version_registry synonym, and schema_version_registry$ table. If any of these items are missed, you must follow the steps in Recover Lost RCU Database SYSTEM.SCHEMA_VERSION_REGISTRY Objects to recreate the missing objects in the new database instance to prevent issues in the future. In addition to that, you must also include all of the schemas whose names contain the prefix that you defined for the environment in question.

The SYSTEM.SCHEMA_VERSION_REGISTRY schema version registry table contains version data for all the schemas. Many operations such as upgrade cannot proceed if this table is not available.

1. Check if the schema version registry table/view/synonym are present:
   1. Run following database queries while connected to the repository database as user with the sysdba priviledge
   2. If SYSTEM.SCHEMA_VERSION_REGISTRY$.TABLE is present and only view/synonym is missing go to step 7.

      column OWNER format a10
      select owner, object_name, object_type from all_objects where object_name like'%SCHEMA_VERSION_REGISTRY%';
      
      OWNER OBJECT_NAME OBJECT_TYPE
      ---------- ------------------------------ -------------------
      SYSTEM SCHEMA_VERSION_REGISTRY VIEW
      PUBLIC SCHEMA_VERSION_REGISTRY SYNONYM
      SYSTEM SCHEMA_VERSION_REGISTRY$ TABLE

2. Use the same version of RCU that was used to create the schemas initially. Run RCU against the existing repository and create schemas with a new PREFIX. DEV1 will be used for the rest of the steps as the new prefix.
3. Create duplicate entries in schema_version_registry by making copies of the original schemas. DEV will be used in the rest of the steps as the original prefix.
   1. Display schema entries that RCU execution just created for DEV1.

      select rowid, mrc_name, owner from system.schema_version_registry$;
      ROWID MRC_NAME OWNER
      ----------------- ------------------------------ ------------------------------
      AAASqQAABAAAUmJAAA DEV1 DEV1_MDSAAASqQ
      AABAAAUmJAAB DEV1 DEV1_ORASDPM
      AAASqQAABAAAUmJAAC DEV1 DEV1_SOAINFR
      AAAASqQAABAAAUmJAAD DEV1 DEV1_ORABA

   2. Create duplicate entries in system.schema_version_registry$ from DEV1.

      insert into system.schema_version_registry$ select * from system.schema_version_registry$ where mrc_name='DEV1';

   3. Run query to display the duplicate entries.

      select rowid, mrc_name, owner from system.schema_version_registry$;
      
      Example:
      ROWID MRC_NAME OWNER
      ----------------- ------------------------------ ------------------------------
      AAASqQAABAAAUmJAAA DEV1 DEV1_MDS
      AAASqQAABAAAUmJAAB DEV1 DEV1_ORASDPMAAASqQ
      AABAAAUmJAAC DEV1 DEV1_SOAINFR
      AAAASqQAABAAAUmJAAD DEV1 DEV1_ORABAMAAASqQ
      AABAAAUmJAAE DEV1 DEV1_MDSAAASqQ
      AABAAAUmJAAF DEV1 DEV1_ORASDPMAAASqQ
      AABAAAUmJAAG DEV1 DEV1_SOAINFR
      AAAASqQAABAAAUmJAAH DEV1 DEV1_ORABAM

4. Alter the duplicate entries to match the original schema PREFIX in the MRC_NAME column. This is done by using the ROWID column to distinguish the newly created RCU entries from the duplicates just made. Note that these ROWID values will be different for your database than this example shows. Using DEV as the original schema prefix.

   update system.schema_version_registry$ set mrc_name='DEV', owner='DEV_MDS' where rowid='AAASqQAABAAAUmJAAE';
   update system.schema_version_registry$ set mrc_name='DEV', owner='DEV_ORASDPM' where rowid='AAASqQAABAAAUmJAAF';
   update system.schema_version_registry$ set mrc_name='DEV', owner='DEV_SOAINFRA' where rowid='AAASqQAABAAAUmJAAG';
   update system.schema_version_registry$ set mrc_name='DEV', owner='DEV_ORABAM' where rowid='AAASqQAABAAAUmJAAH';

5. Display the change showing the original prefix (DEV).

   select mrc_name, owner, status from schema_version_registry where mrc_name='DEV';
   
   MRC_NAME OWNER STATUS
   ------------------------------ ------------------------------ -----------
   DEV DEV_ORABAM LOADINGDEV 
   DEV_MDS VALIDDEV 
   DEV_ORASDPM VALIDDEV 
   DEV_SOAINFRA VALID

6. Commit changes

   commit;

7. Create public synonym and view for system.schema_version_registry$.

   create view system.schema_version_registry as select comp_id, comp_name,mrc_name, mr_name, mr_type, owner, version, status, upgraded, start_time,modified, edition from system.schema_version_registry$;
   
   create public synonym SCHEMA_VERSION_REGISTRY FOR SYSTEM.SCHEMA_VERSION_REGISTRY;

8. May need to grant proper privilege to some schemas (eg. If schemas privs were lost during export/import). This step is site-specific and will depend on your situation and schemas created.

   For example:
   grant select on system.schema_version_registry to DEV_IAU ;
   grant select on system.schema_version_registry to DEV_IAU_APPEND;
   grant select on system.schema_version_registry to DEV_IAU_VIEWER;
   grant select on system.schema_version_registry to DEV_MDS ;
   grant select on system.schema_version_registry to DEV_OPSS;

9. Run RCU again to drop all the schemas that were created when run in Step#2 above. This will leave just the modified schema_version_registry entries for the PREFIX (Example: DEV) schemas in the system.schema_version_registry$ table that were just added.

After you've performed the preliminary steps, build a template for the domain you plan to migrate on the old host and then copy it to the new host.

1. Run the Template Builder to create a domain template on the old host:

   ORACLE_HOME/oracle_common/common/bin/config_builder.sh

2. In the Template Builder dialog box:
   1. On the Template Type page:
      • Select Create Domain Template.
      • Select Use Domain as a Source.
      • In Source Location, provide the location of the domain directory whose template you're creating.
      • In Template Location, provide a name and location to save the new template.
   2. On the Template Information page, confirm the values and click Next.
   3. On the Template Summary page, confirm the values and click Create.
   4. On the Configuration Progress page, click Next.
   5. On the End of Configuration page, click Finish.
3. Copy the domain template you just created to the new host.

You'll create a new domain on the new host to which you're migrating your non-clustered WebCenter Content release 12c.

1. Run the Fusion Middleware Configuration wizard on the new host using the template that was just created:

   $ORACLE_HOME/oracle_common/common/bin/config.sh

2. In the Fusion Middleware Configuration Wizard dialog box:
   1. On the Create Domain page, select Create a new domain, provide a domain location and then click Next.
   2. On the Templates page, select Create Domain Using Custom Template, provide a template location, and click Next.
   3. On the High Availability Options page, click Next.
   4. On the Application Location page, provide an application location and click Next.
   5. On the Administrator Account page, provide values for Name, Password, and Confirm Password, and then click Next.
   6. On the Domain Mode and JDK page, select a domain mode and JDK, click Next.
   7. On the JDBC Data Sources page, do one of the following (as applicable):
      • If the database is not moving, select the MDS datasource and click Next.
      • If the database is moving, select MDS schema, then enter the new values for Host Name, DBMS/Service, Port, Username, and Password, and then click Next.
   8. On the JDBC Data Sources Test page, select the mds-WCCUIMDSREPO data source, click Test Selected Connections, ensure a successful test, and then click Next.
   9. On the Database Configuration Type page, do one of the following (as applicable):
      • If the database is not moving, select Get RCU Configuration, and click Next.
      • If the database is moving, do the following:
        1. Enter the new values for Host Name, DBMS/Service, Port, Schema Owner, and Schema Password.
        2. Select Get RCU Configuration and click Next.
   10. On the JDBC Component Schema page, do one of the following (as applicable):
       • If the database is not moving, select the schema and click Next.
       • If the database is moving, enter the new values for Host Name, DBMS/Service, Port, Schema Owner, and Schema Password for each of the data sources and click Next.
   11. On the JDBC Component Schema Test page, do one of the following (as applicable):
       • Select all of the JDBC component schemas, then click Test Selected Connections.
       • Ensuring a successful test, click Next.
   12. On the Advanced Configuration page, select Administration Server, Node Manager, Topology, and then click Next.
   13. On the Administration Server page, provide an updated value for Listen Address and click Next.
   14. On the Node Manager page, confirm the details and click Next.
   15. On the Managed Servers page, provide an updated value for the Listen Address of each managed server and click Next.
   16. On the Clusters page, click Next.
   17. On the Server Templates page, click Next.
   18. On the Coherence Clusters page, click Next.
   19. On the Machines page, provide an updated value for the Node Manager Listen Address.
   20. On the Assign Servers to Machines page, click Next.
   21. On the Virtual Targets page, click Next.
   22. On the Partitions page, click Next.
   23. On the Configuration Summary page, click Create.
   24. On the Configuration Progress page, click Next.
   25. On the End of Configuration page, click Finish.

If the database is moving, a couple of configuration files need to be modified using the steps below. However, if the database is not moving, ignore this procedure and continue with the next that describes how to copy the UCM directory to the new host.

1. In a terminal window, go to the DOMAINHOME/config/fmwconfig directory on the new host.
2. In the jps-config.xml file, update the jdbc.url property with the new JDBC connection string information for the new database location and then save the changes.
3. In the jps-config-jse.xml file, make the following changes, and then save your changes:
   • Update the jdbc.url property with the new JDBC connection string information for the new database location.
   • Update the audit.loader.jdbc.string property with the JDBC connection string information for the new database location.

A variety of tools are available to help you copy WebCenter Content directory to another host. In this example, we'll use rsync to copy from one Linux host to another.

1. Run mkdir ucm on the target host in the DOMAINHOME directory.
2. Copy the DOMAINHOME/ucm directory from the old host to the new host:

   rsync -avzh ucm/ oracle@newhost:DOMAINHOME/ucm

By default, both the vault and weblayout directories are located in the DOMAINHOME/ucm/cs directory. If you migrated WebCenter Content and the vault and weblayout directories were on some shared/remote file system, mount them at this time. But, if you cloned WebCenter Content and the vault and weblayout directories were on some shared/remote file system, mount their copies from the new location at this time.

1. Edit WebCenter Content's and Refinery's MANAGEDSERVERNAME_intradoc.cfg and intradoc.cfg files with the updated directory paths, if necessary. The intradoc.cfg file and the MANAGEDSERVERNAME_intradoc.cfg file are located in the DOMAINHOME/ucm/cs/bin directory for WebCenter Content and in the DOMAINHOME/ucm/ibr/bin directory for the Refinery.

   Note:

   The MANAGEDSERVERNAME_intradoc.cfg file is available in version 11.1.1.9.0 (2016-06-24 00:16:34Z-r144917) or 12c (12.2.1.1.0) or greater.

   Update the following:

   • IdcHomeDir
   • FmwDomainConfigDir
   • AppServerJavaHome
   • IntradocDir
   • VaultDir
   • WeblayoutDir
   • UserProfilesDir
2. Edit WebCenter Content's and Refinery's config.cfg files to include the updated host name for HttpServerAddress. On WebCenter Content, this file is located in the DOMAINHOME/ucm/cs/config directory. Inbound Refinery's config.cfg is in the DOMAINHOME/ucm/ibr/config. directory.
3. Edit WebCenter Content's and Refinery's config.cfg files to include the updated host name for SocketHostNameSecurityFilter or IP address for SocketHostAddressSecurityFilter.

Using the Admin Server and Node Manager to start the managed servers is one option. Another option is to just use the startManagedWebLogic.sh/cmd scripts from a terminal session.

1. Start the Admin Server on the new host.
2. Start the NodeManager on the new host.
3. Start the managed servers on the new host.
4. Create the boot.properties files for the Admin Server and each managed server.

1. Log into WebCenter Content.
2. Go to the Administration - Providers page. For the outgoing provider connected to the refinery, click Info and then click Edit.
3. Provide the new values for Server Host Name and HTTP Server Address, and click Update.
4. Restart the managed server for WebCenter Content.

1. In the Fusion Middleware Control, edit the PropConnectionUrl mBean value used for establishing the connection from the WebCenter Content user interface to the WebCenter Content instance so that it uses the new host name.
   1. Select the WCCADF_server1 managed server from the hamburger menu navigation bar in the upper left corner of the page.
   2. Go to the WebLogic Server - System MBean Browser.
   3. Navigate to Application Defined MBeans > oracle.adf.share.connections > Server: WCCADF_server1 > Application: Oracle WebCenter Content - Web UI > ADFConnections > ADFConnections > WccConnection > WccAdfServerConnection.
   4. Update the value for PropConnectionUrl and click Apply.
   5. Go to Application Defined MBeans > oracle.adf.share.connections > Server: WCCADF_server1 > Application: Oracle WebCenter Content - Web UI > ADFConnections > ADFConnections.
   6. On the Operations tab, click Save and then click Invoke.
2. Restart the managed server for the WebCenter Content user interface.

1. From the DOMAINHOME/ucm/cs/bin directory, run the SystemProperties application.
2. From within the SystemProperties application, update the database information on the Database tab so that the standalone Java applications in WebCenter Content's bin directory can be launched successfully.

1. Run IdcAnalyze to confirm there are no errors. On the Configuration tab, ensure the following:

   • Database is selected

   • Database → RevClassIDs is selected

   • Database → Clean Database is deselected

   • Search index is selected

   • Search index → Clean Search Index is deselected

   • file system is selected

   • Generate Report is selected

   For information, see Using the Content Server Analyzer in Administering Oracle WebCenter Content.
   If errors are reported, fix them as necessary.
2. Update other applications' configuration settings with the new host name for WebCenter Content.