Software AG strongly recommends using cloned databases when testing your upgrade. You can clone only those database components that you will want to use in your new environment. Cloning operations are typically done at the level of the schema (Oracle) or database (SQL Server and DB2) that contains the product database components, or at the level of the database user that owns all the database components. Data cloning is usually performed using export and import tools that are bundled with the database. For cloning procedures, see your database vendor documentation.

Installing Software AG Products describes the basic grants and privileges needed to work with product database components. Before cloning your databases, give the database users that will work with the cloned databases the same basic grants and privileges that were given to the database users that work with the live databases.

In some cases, one database user grants permissions to a second user (for example, the process audit database user grants permissions to a second user to archive process audit data). Before cloning the databases, create the second user in the new schema or database.

Use a separate database user (Oracle) or database (SQL Server or DB2) to host the cloned databases.

Some products offer features to archive or purge data from their database components. You can reduce the amount of time needed to migrate database components if you archive and purge them beforehand. For instructions on archiving or purging database components for Integration Server, Microservices Runtime, or Process Engine, see the Monitor product documentation. For instructions on archiving or purging database components for other products, such as Optimize and Trading Networks, see the product documentation.

Make a backup of the product databases. Shut down all ActiveTransfer, Integration Server, Microservices Runtime, My webMethods Server, webMethods OneData, and Optimize instances that connect to database components before making the backup. If you are upgrading My webMethods Server, back up the My webMethods Server installation directory at the same time you back up the database. If you have problems, you will need to restore data from both types of backup.

If you are upgrading Trading Networks, and you created custom indexes for your Trading Networks database components, check whether those custom indexes conflict with indexes that will be created when you run the Trading Networks database migration scripts in the next step. The database scripts are located in the new_Software AG_directory/common/db/TradingNetworks/TradingNetworks/scripts/old_release_number/RDBMS directory. If there is a conflict, drop the custom indexes.