Prepare Database Components for Migration
![*](chapterTOC_bullet.png)
The instructions in this guide assume you are using the same type of RDBMS in the new environment that you used in the old environment. If you want to use a different type of RDBMS in the new environment, there are special requirements that must be met before you can upgrade your products. Contact Software AG Professional Services for more information.
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.
![*](chapterTOC_bullet.png)
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.
![*](chapterTOC_bullet.png)
Use a separate database user (Oracle) or database (SQL Server or DB2) to host the cloned databases.
![*](chapterTOC_bullet.png)
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.
![*](chapterTOC_bullet.png)
Make a backup of the product databases. Shut down all
ActiveTransfer,
Integration Server,
Microservices Runtime,
My webMethods Server,
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.
![*](chapterTOC_bullet.png)
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.