Migrate projects to LoadRunner Enterprise
This section describes how to migrate projects from Performance Center to LoadRunner Enterprise.
Migrating projects from Performance Center to LoadRunner Enterprise requires the following steps:
Upgrading Performance Center projects to ALM 12.60 (pre-installation)
To work with projects from an earlier version of LoadRunner Enterprise (Performance Center), you first need to upgrade your projects to Performance Center 12.6x (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.
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 the Install and configure LoadRunner Enterprise servers and hosts section in the LoadRunner Enterprise Installation Guide.
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 will happen).
For details, see the Configure LoadRunner Enterprise section in the LoadRunner Enterprise Installation Guide.
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.
This task describes how to migrate project data and the file repository from Performance Center projects to LoadRunner Enterprise.
Note: For details on upgrading projects that were migrated to LoadRunner Enterprise 2020 from ALM, or that were created in LoadRunner Enterprise 2020, see Upgrade projects to the latest LoadRunner Enterprise version.
Make sure you have performed the first two steps in Project migration workflow.
We recommend that you migrate the project schema from a backup source to avoid any impact on the production 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.
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.
On the LoadRunner Enterprise Administration sidebar, select Management > Projects.
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
Completedstate automatically revert back to the
Not Upgradedstate until they have been upgraded to the latest version of LoadRunner Enterprise. For details, see Migrate projects to LoadRunner Enterprise.
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:
Not Active. If
Not Active, users cannot connect to the project.
Select a project you want to migrate from the Projects list (it must be in
Not Migratedstate), and click the Project Name link to display the project details.
Click the Migrate Project button in the upper-right side. 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.
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
The net service name found in the local tnsnames.ora file (make sure the name is valid).
The name of the database server on which the database is located.
The database server port number.
(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.
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 should 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 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;
EXEC sp_change_users_login 'Update_One', 'td', 'John';
(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.
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.
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.
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 Migration State and Project State 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
Activestate are available in LoadRunner Enterprise.
For more details on project settings, see View or edit project settings.
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.
Notes and limitations
This section provides notes and limitations when migrating projects to LoadRunner Enterprise.
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.|
|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.|
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:
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.
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.
Note: Not all features defined in previous versions are displayed and work in the same way in LoadRunner Enterprise 2020. For the list of unsupported features, see Unsupported features.