Migrate projects to LoadRunner Enterprise

This section describes how to migrate projects from Performance Center/ALM to LoadRunner Enterprise.

In this topic:

Project migration workflow

Migrating projects from Performance Center to LoadRunner Enterprise requires the following steps:

1. Upgrading Performance Center projects to ALM 12.60 (pre-installation)

   To work with Performance Center/ALM projects in LoadRunner Enterprise, you first need to upgrade your projects to Performance Center (ALM 12.60) before you can migrate them to LoadRunner Enterprise.

   For details on upgrading Performance Center projects to ALM 12.60, see the Project migration pre-installation activities section in the LoadRunner Enterprise Installation Guide (available from Installation).

2. Migrating the Site Admin and LAB schemas from ALM (during installation)

   During the installation process, you need to migrate the configuration data that was stored in ALM Site Admin and LAB to LoadRunner Enterprise.

   For details, see Configure Site Admin and LAB schema migration in the LoadRunner Enterprise Installation Guide (available from Installation).

   Note: You can also perform this step post-installation from the Configuration wizard, provided you specify a new Site Admin and LAB schema for LoadRunner Enterprise (if you use the existing schemas nothing happens). For details, see the Configure LoadRunner Enterprise section in the LoadRunner Enterprise Installation Guide (available from Installation).

3. Migrating the project data (post-installation)

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

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

   For details, see Migrate projects to LoadRunner Enterprise below.

Back to top

Migrate projects to LoadRunner Enterprise

This task describes how to migrate project data and the file repository from Performance Center projects to LoadRunner Enterprise.

1. Prerequisites

   Upgrade projects/migrate schemas	Make sure that you have upgraded Performance Center projects to ALM 12.60 and migrated the Site Admin and LAB schemas from ALM 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 LoadRunner Enterprise server. Make sure that the tnsnames.ora file is configured to connect to the Oracle server of ALM.
   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 LoadRunner 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 ALM smart repository size is similar to the repository size required for LoadRunner Enterprise.

2. On the LoadRunner Enterprise Administration sidebar, select Management > Projects.

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

   Not Migrated/Upgraded	The project has not been migrated to LoadRunner Enterprise, or has not been upgraded to the latest LoadRunner Enterprise version. Note: When migrating projects, they are automatically migrated to the latest LoadRunner Enterprise 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 LoadRunner Enterprise version. Note: Whenever the LoadRunner Enterprise 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 of LoadRunner Enterprise. For details, see Upgrade projects to the latest LoadRunner Enterprise 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 View 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 you want 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 ALM's Site Admin and LAB schemas during the LoadRunner Enterprise installation process.

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

   UI Element	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 LoadRunner Enterprise on the database server. Note that this is not the database admin user. Note: For MS-SQL (Win Auth), the Windows user running the LoadRunner Enterprise 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 the permissions required to access LoadRunner Enterprise 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 from LoadRunner Enterprise during project migration, the following conditions must be fulfilled:

   • The database server must be accessible.

   • The ALM database and user must exist.

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

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

   • The version of the ALM 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 ALM source data, click Reload ALM 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 ALM source data, click Reload ALM initial values.

   Note:

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

   • Make sure that the LoadRunner Enterprise 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 View migration issues.

   Only projects that are in Completed and Active state are available in LoadRunner Enterprise.

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

Back to top

View migration issues

To view migration events associated with the project, select a migrated project and click the 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 to LoadRunner Enterprise.

Subject	Description
Cloud accounts	When upgrading from an earlier version of LoadRunner Enterprise, 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 in ALM 12.60 to another database server type in LoadRunner Enterprise 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. Resolution: 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, re-entered any internal password that was created within ALM (such as for Monitor Profiles). These re-entered passwords are encrypted with the LoadRunner Enterprise passphrase. The ALM login password does not need to be retyped; it remains the same password for LoadRunner Enterprise as well. Users with an empty password need to ask their LoadRunner Enterprise 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 LoadRunner Enterprise 202x. Resolution: Use an external InfluxDB server to avoid this issue in the future. For details, see Manage analysis servers.
Upgrades and remote installations	Upgrades and remote installations installed on earlier versions are not migrated to LoadRunner Enterprise 2020.
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 LoadRunner Enterprise, and the rest are set with Viewer permissions.
Version control	LoadRunner Enterprise does not currently support version control. As a result, only the latest checked in tests and scripts from ALM are migrated to LoadRunner Enterprise.

Back to top

See also:

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