General prerequisites

To perform any type of upgrade or data migration, you must have:

• A general understanding of aPriori. You must also have a working knowledge of the database management system you are using with aPriori (either MySQL, Oracle, or SQL Server).

• Super user access to aPriori. If a super user does not exist, you must designate one before starting the upgrade.

• Administrative access to the database server.

• Installation files for the new version of aPriori. For more information, see Acquiring the Installation Files in 1.

• System access to your DBMS tools. That is, the system where you are performing the upgrade or migration must have access to the tools for your database. For example, for Oracle, you must set the ORACLE_HOME environment variable and add it to your Windows PATH. Ensure that you (or a script) can run SQL*Plus (for example, %ORACLE_HOME%\bin\sqlplus.exe). Likewise, for Microsoft SQL Server, you must ensure that SQL Server Management Studio is installed on the machine where you are running the updatedb.cmd script so that it can access sqlcmd.exe. Running the script on the SQL Server host ensures that this is the case.

Note: If your upgrade requires upgrading through multiple releases (for example, from 2018 R3 to 2019 R1 and then to 2019 R2) you must start a fresh command console window each time you run updatedb.cmd. Otherwise, the old window may have environment variables set for the previous upgrade which cause the next upgrade to fail.

• Hardware: For an upgrade, the staging and testing computer must be comparable to the production server, with enough disk space to accommodate the size of the current database. Supported operating systems: See the latest edition of the System Requirements document.

It is a best practice to observe these precautions as a part of any major upgrade:

• Back up everything before you start.

• Create a testing environment where you can upgrade and extensively evaluate the upgrade before putting it into production.

• Only perform the upgrade on your production environment after you are 100% confident that the upgrade does not introduce any unexpected changes for your users.

• When you do upgrade your production environment, do so during an extended period of low system usage (such as a weekend) so that you do not interfere with the production work of your users.