Check your RDBMS against System Requirements for Software AG Products. If the RDBMS version you are using is not supported by your new products, upgrade to a supported RDBMS version.

Some products, like Integration Server, Microservices Runtime, Optimize, Process Engine, and Trading Networks, offer features to archive or purge data from their database components. You can reduce the amount of time needed to migrate database components later in this procedure if you archive and purge them now. For instructions, see the product documentation.

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.

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 the 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.

The new release might require changes to the database components, such as new tables, columns, keys, or indexes. You will run database migration scripts that update the existing database schemas so they are compatible with the new product release. The scripts might modify the existing database components, or might create parallel database components with the new structure and then insert, select, rename, and drop the tables, columns, keys, and indexes. These changes might increase the size of your database.

Database migration may take many hours, depending on the volume of data, and is often the critical path for upgrade.