The following table describes how to upgrade projects from previous Quality Center and ALM versions. Note that not all projects can be upgraded directly to ALM 12.55.

Review the following before you upgrade projects to ALM 12.55:

• Version Control:

  • Upgrading Quality Center 10.00 and ALM 11.00 or later version control enabled projects. Version control enabled projects from Quality Center 10.00 or ALM 11.00 or later cannot be upgraded to ALM 12.55 while there are checked out entities. All entities must be checked in to the corresponding version of Quality Center or ALM. To determine if there are checked out entities, see this KB article.

  • Upgrading from legacy version control projects. To work with projects from Quality Center 9.0 or Quality Center 9.2 that use version control, you must first upgrade to ALM11.00, migrate legacy version control data, and then upgrade to ALM 12.55.

• Server Locales: Before upgrading a project, ensure that the system locale on the ALM server, database, and file servers, all match.

• Performance Center: If you were working with Performance Center 11.00 or later, before upgrading other Performance Center projects, you must first upgrade LAB_PROJECT, and then any Performance Center template projects. For details, see Restoring LAB_PROJECT.

When upgrading projects from Quality Center 10.00, the project file repositories are migrated to a new optimized folder structure. Review the following to ensure that the file repositories are migrated successfully to the new structure:

• Allow for approximately twenty percent more space on the database.

• Before running the upgrade tool, make sure that all project files are saved in the default project directory.

  To find out whether project files, such as tests and test resources, are outside the default project directory, log in to Site Administration. In the Site Projects tab, expand each project and click the DATACONST table. For each of the *_directory entries in the DC_CONST_NAME column, verify that the corresponding DC_VALUE is a folder name in the default project directory, and not a path to another directory. For example, verify that the DC_VALUE for tests_directory is set as tests, and the DC_VALUE for resources_directory is set as resources.

• Move any folders or files from the project repository that are not connected to ALM (for example, backup folders, and scripts that are not part of workflow) to a directory outside the repository. Any unrelated files remaining in the repository will be accessible via FTP only after the migration is completed. For details, see Browsing the Project Repository.

• Make sure the ALM server has full permissions to the file server.

• For information on configuring the resources allocated to building the index, see this KB article.

• Make sure there is no folder on the file system named ProjRep.

• During and after the repository migration, no direct access to the file system is allowed. After the migration is completed, you can browse and edit the optimized file system using an FTP client. For details, see Browsing the Project Repository.

• To backup a project during and after the repository migration, follow the guidelines in this KB article.

• When restoring a project to the new version of ALM, be sure not to change the <PR_SMART_REPOSITORY_ENABLED> property in the dbid.xml file.

• The space saving and performance benefits of the optimized repository are realized only after the repository is fully migrated. Therefore, you should resolve any errors or warnings that occur during the migration, and ensure the migration is complete.

• If the ALM, database or file servers are over WAN, the migration process takes many times longer than over LAN.

The upgrade workflow consists of the following steps:  

1. Verify project. Detects problems in your environment, schema structure, and data integrity that could cause the project upgrade to fail.

   The verification process generates a report which indicates problems that can be repaired by ALM and problems that you should repair manually. For details, see Verifying Domains and Projects.

2. Repair project. Fixes data and schema issues found by the verification process. If the verification process finds problems that can cause data loss, the repair process does not fix them automatically. You need to repair these problems manually. For details, see Repairing Domains and Projects.

   Before you start the repair process, you should back up your project. For details, see Backing Up Projects.

   In the event that the repair fails, you must restore backed up projects before trying the repair process again. For details, see Restoring Projects.

3. Upgrade project. Upgrades your project to the current version of ALM. For details, see Upgrading Domains and Projects.

   Before you upgrade the project, back up your project. For information, see Backing Up Projects.

   In the event that the upgrade fails, you must restore backed-up projects before trying the upgrade process again. For information, see Restoring Projects.

4. Manage project repository migration. After upgrading a project from Quality Center 10.00 to ALM 12.55, ALM migrates the project repository directories to a new file structure in the default project repository location. If the migration process fails, you must fix the problems manually in the project repository. You can also configure the speed at which the migration is performed. For details, see Migrating the Repository.

For detailed information on the problems detected and fixed by the verification and repair processes, and help with repairing problems that cannot be fixed by ALM, refer to the Upgrade Preparation Troubleshooting appendix in the Micro Focus Application Lifecycle Management Installation and Upgrade Guide.