Share this page

# Migrate projects

This section describes how to migrate projects from versions earlier than 12.60.

Note: Direct migration is no longer supported. Instead, you must first migrate projects to version 2023, and then upgrade to the latest version.

In this topic:

## Project migration workflow

This section describes how to migrate projects from versions earlier than 12.60.

Upgrade projects to 12.60 (pre-installation)

To migrate ALM projects, you first need to upgrade your projects to version 12.60. For details, see Pre-installation project migration steps.

During the installation process, you need to migrate the configuration data that was stored in ALM Site Admin and LAB to OpenText Enterprise Performance Engineering. For details, see Configure servers and hosts.

Note: You can also perform this step post-installation from the Configuration wizard, provided that you specify a new Site Admin and LAB schema; if you use the existing schemas nothing happens. For details, see Post-installation configuration steps.

Migrate project data (post-installation)

After installation, you need to migrate project data and the file repository from existing projects using the migration tool in Administration.

Project data which includes scripts, attachments, run results, .xml files, and templates is migrated from ALM Site Admin and LAB to the OpenText Enterprise Performance Engineering server.

For details, see Migrate projects.

Back to top

## Migrate projects

This section describes how to migrate project data and the file repository from Performance Center projects to OpenText Enterprise Performance Engineering.

Note: Direct migration is not supported. Instead, you must first migrate projects to 2023, and then upgrade to the latest version.

For details on upgrading projects that were migrated from ALM, or that were created in 202x, see Upgrade projects to the latest version.

1. Prerequisites

   Requirement | Description
   --- | ---
   Upgrade projects/migrate schemas | Make sure that you have upgraded projects to 12.60 and migrated the Site Admin and LAB schemas as described in Project migration workflow.
   Project schema | We recommend that you migrate the project schema from a backup source to avoid any impact on the production environment.
   Oracle environment | When migrating project data from an Oracle environment: Make sure that the Oracle client is installed on the OpenText Enterprise Performance Engineering server. Make sure that the tnsnames.ora file is configured to connect to the Oracle server.
   MS-SQL environment | When migrating project data from an MS-SQL environment: For MS-SQL (SQL Аuth): You need to provide a password for the ‘td’ user with at least read permissions, or the login mapped to the ‘td’ user of the database. For MS-SQL (Win Аuth): Make sure that the account running the OpenText Performance Engineering Backend Service has access to the source MS-SQL Server with at least read permissions. Note: When determining how much space you need for storing script files and run results, note that the project's smart repository size is similar to the repository size required for OpenText Enterprise Performance Engineering.

2. In Administration, select Management > Projects.

   The Projects page opens, displaying a list of projects with their current state.

   State | Description
   --- | ---
   Not Migrated/Upgraded | The project has not been migrated or upgraded to the latest version. Note: When migrating projects, they are automatically migrated to the latest version and do not need to be upgraded after the migration has finished.
   Pending Migration/Upgrade | The project is queued for migration or upgrade.
   Migrating/Upgrading | Project migration or upgrade is in progress.
   Completed | The project was migrated or upgraded to the latest version. Note: Whenever an installation is upgraded to a later version, all projects in `Completed` state automatically revert back to the `Not Upgraded` state until they have been upgraded to the latest version. For details, see Upgrade projects to the latest version.
   Failed | An error occurred during file migration or upgrade, and could not be completed. Check the cause of the error in the project log (see Migration issues). Fix the error, and run the migration process again.

   The Project State indicates whether the project is currently available: `Active` or `Not Active`. If `Not Active`, users cannot connect to the project.

3. Select a project to migrate from the Projects list (it must be in `Not Migrated` state), and click the Project Name link to display the project details.

4. Click Migrate Project. The Migrate Project dialog box opens.

   Note: By default, the fields are populated with source data that was migrated from Site Admin and LAB schemas during the installation process.

5. In the Database details section, provide access details to the database server where the project’s schema is located.

   UI Elements | Description
   --- | ---
   Database Type | The database server type: Microsoft SQL (Win or SQL Auth) or Oracle.
   Project Schema Name | The name for the project schema as defined in the database. If you created a different project schema (for example, if you made a duplicate schema), enter the name of that project schema instead.
   Net Service Name (Oracle only) | The net service name found in the local tnsnames.ora file (make sure the name is valid).
   Database Server (MS-SQL only) | The name of the database server on which the database is located.
   Port (MS-SQL only) | The database server port number.
   User Name (Oracle and MS-SQL (SQL Auth) only) | The name of the user with the permissions required to access OpenText Enterprise Performance Engineering on the database server. Note that this is not the database admin user. Note: For MS-SQL (Win Auth), the Windows user running the OpenText Performance Engineering Backend Service is used to access the SQL server. For MS-SQL (SQL Auth): The login supplied to authenticate to the SQL server must be mapped to the ‘td’ user of the database. If you are using the same SQL server used by ALM, the ‘td’ user that is present in each database is by default mapped to the ‘td’ login, and this ‘td’ login can be supplied to perform the migration. If you backed up and restored the database of the project in another SQL server, make sure that you map the login supplied to perform the migration to the ‘td’ user of the database. For example, run the following SQL command: `--Map database user td to login John for database DEFAULT_PCPROJECT_DB USE DEFAULT_PCPROJECT_DB;` `GO` `EXEC sp_change_users_login 'Update_One', 'td', 'John';` `GO`
   Password (Oracle and MS-SQL (SQL Auth) only) | The password of a user with permissions required to access OpenText Enterprise Performance Engineering on the database server; this is not retrieved from ALM. For Oracle: Enter the source ALM/PC12.6x Site Admin or LAB_PROJECT schema's (Oracle user) password. For MS-SQL (SQL Auth): Password for the ‘td’ user with at least read permissions, or the login mapped to the ‘td’ user of the database.
   Connection String | Displays the database server connection string.

   Click Test Connection to check the connection to the source database project schema.

   Note: For a connection to an ALM project schema to work during project migration, the following conditions must be fulfilled:

   - The database server must be accessible.

   - The ALM database and user must exist.

   - The database schema provided for upgrade must correspond to a schema of a project (the DATACONST table must exist and can be queried).

   - The schema to upgrade must correspond to an ALM project schema with Lab Extension for Functional and performance testing enabled (the EXTENSIONS table must contain a record in which "EX_NAME"="PCPROJECT").

   - The version of the Project schema supported for upgrade must be either 12.60, 12.61, 12.62, or 12.63 (the DATACONST table must contain a record in which "DC_CONST_NAME"="version" and "DC_VALUE"="<one of the supported versions>").

   If you want to restore the source data, click Reload initial values.

6. The Repository details section displays the location of the project repository in the file system.

   Click Test Connection to check that the source project schema is accessible.

   If you want to restore the source data, click Reload initial values.

   Note:

   - This must be a shared folder that users have permissions to access.

   - Make sure that the OpenText Performance Engineering service has read permissions to the source repository.

7. Click Start Migration to start the project migration process.

   Only one project can be migrated at a time. Projects that are triggered and waiting for migration are put in a queue until the current one has finished.

   After migration is complete, the Project State and Project Status are updated in the Projects list.

   If there are script migration or repository errors, a warning is added to the log file. For details, see Migration issues.

   Only projects that are in `Completed` and `Active` state are available.

   For more details on project settings, see View or edit project settings.

Back to top

## Migration issues

If you encounter migration issues, you can view the migration events associated with the project in the project's Logs tab. The log displays the step name, start and end time, status, and the text of the log generated during the migration process. For task details, see View the project log.

There are several possible causes for warnings:

- One or more project files were not found in the project repository. This can result from missing or renamed files.

- Redundant files are found in the repository. The migration cannot complete until the legacy repository is empty of files. Redundant files can be one of the following:

  - Duplicate project files that could not be deleted. This can result from insufficient permissions.

  - Files unrelated to ALM that were manually saved in the project repository.

  - Unidentified project files.

Back to top

## Notes and limitations

This section provides notes and limitations when migrating projects.

Topic | Description
--- | ---
Cloud accounts | When upgrading from an earlier version, you need to delete your migrated cloud accounts and recreate them in the current version.
Different database types | Migrating projects from one database server type to another database server type is not supported.
Migration failure | If the migration has completed, but previously had failures, make sure to remove the orchidtmp\MigrateScriptsTemp folder because it could be exhausting server disk space. Resolution: Make sure there are no active migrations or upgrades. Go to the orchidtmp folder and delete the MigrateScriptsTemp folder.
Dockerized hosts | When migrating a project that contains tests using Dockerized hosts, only the Orchestration configurations are migrated; the path to your updated Docker images must be redefined. Solution: To run a migrated test using Docker hosts, you need to add the Docker images (if different from the default ones), associate the orchestrator configuration with the valid images, and then assign the images to the test in the Performance Test Designer. For details, see Distribute load generators among Vuser groups. When migrating a project that contains a Dockerized Kubernetes host, the orchestrator bearer token is not retrieved (it is displayed as a combination of asterisks) and needs to be entered manually.
Passwords | After migration, you must re-enter any internal password that was created within ALM (such as for Monitor Profiles). These re-entered passwords are encrypted with the OpenText Enterprise Performance Engineering passphrase. The login password does not need to be retyped; it remains the same password for OpenText Enterprise Performance Engineering as well. Users with an empty password need to ask their administrator to reset their password if they cannot authenticate with an empty password.
Result data on hosts | When upgrading a host from Performance Center 12.6x, uncollated test run results on the Controller and load generators, and offline graph data from historical test runs on the Controller, is not migrated to 202x. Resolution: Use an external InfluxDB server to avoid this issue in the future. For details, see InfluxDB analysis servers.
User-defined fields | Only the default user-defined fields appearing in the schema during the creation of ALM LAB or projects are migrated. Additional columns that were added to project above the number listed in parenthesis below are migrated: For Projects: Test (24), Test instance (24), Runs (12), Test Set (6) For Lab: Project Properties (4), Host (5)
User profile | User profile data is not migrated from ALM for LAB and projects.
Users set with Viewer role | During Site Admin and LAB migration, all users are automatically set with Viewer role. During project migration, users that belonged to the TDAdmin group in the ALM project are set with Performance Tester permissions in OpenText Enterprise Performance Engineering, and the rest are set with Viewer permissions.
Version control | Version control is not supported. As a result, only the latest checked in tests and scripts from ALM are available after migration.

Note: Not all features defined in previous versions are displayed and work in the same way as in the latest version. For the list of unsupported features, see Deprecated features.

Back to top

See also:

- Create domains and projects
- Upgrade projects to a new version
- Manage projects
- Project repository

https://admhelp.microfocus.com Enterprise Performance Engineering,LoadRunner Enterprise 8942
Tips to improve your search results...OpenText™ Enterprise Performance Engineering Help Center OpenText™ Enterprise Performance Engineering Help 26.1 All View Local Help Center View Online Help Center Version: