Suggested system configuration

The system includes the following main components: The OpenText Application Quality Managementserver, the database server, and the project repository. For details regarding the function of each component within the system, see Technology and Architecture.

When planning your installation and upgrade strategy, decide whether to install the new OpenText Application Quality Management system on new system components, or to reuse components from the existing system.

It is strongly recommended that you not use any of the existing components as part of the new system.

• Application server. To install the new version of the OpenText Application Quality Management server on the same machine where the existing server is installed, first reformat or reinstall the machine's operating system. You can also uninstall the old version. For more details on uninstalling, see Uninstall.

• Database server. Install an updated version of the database server on a separate machine, or create a new instance of the existing server on the machine on which it is currently installed.

• Project Repository. Create a copy of the existing repository to be used by the new system.

Advantages

Following this best practice produces two functioning systems:

• The original system that can open and work with existing projects.

• The new system to which existing projects will be upgraded.

Each system is totally separate, and any problem encountered in one does not impact the other.

This best practice has the distinct advantage of enabling you to incrementally upgrade your projects. Since there are two functioning systems, there is no need to deactivate all projects at once. You can deactivate projects individually in the old system, back them up, and then reactivate them in the new system, upgrading them one-by-one. Without two functioning systems, all projects would remain inactive until their upgrades are complete, a significant amount of project downtime.

The following are two examples of critical problems that may arise when you do not follow the suggested upgrade approach:

• Unnecessary project downtime. If a project becomes corrupted before you complete its upgrade, there will be no option but to retrieve a backup copy of it. Depending on organizational policy this process may take a few days, meaning that the project is not available at all for this amount of time.

  If the original system is functioning however, you can go back to a working version of the project immediately and not be dependent on waiting for the backup to arrive, thus avoiding unnecessary project downtime.

• Damaged project repository. If you install the new version of the server on the same machine, you must first uninstall the existing server. It is possible that you may subsequently discover a problem with the project repository that requires the original server to repair it.

  Your only course of action is to:

  1. Uninstall the new version.

  2. Reinstall the old version.

  3. Fix the project repository.

  4. Uninstall the old version.

  5. Reinstall the new version.