Migrate projects to LoadRunner Enterprise

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

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 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.

  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 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.

  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.

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.

  1. Prerequisites

    • 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.

      • 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 Migrate projects to LoadRunner Enterprise.
    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 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.

  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:

    • 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;
        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 MS-SQL (SQL Auth), you need to provide a password for the td user with at least read permissions.
    Connection String Displays the database server connection string.

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

    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 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 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
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.
Diagnostic server passwords

When migrating projects that contain diagnostics servers, the diagnostic server passwords are not imported. Therefore, to use diagnostics servers from migrated projects, you must update the password for each server you want to use.d
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 2020 default ones), associate the orchestrator configuration with the valid 2020 images, and then assign the images to the test in the Performance Test Designer. For details, see Assign Load Generators to Groups dialog box.

  • 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

  • Any internal password that was created within ALM (such as for AUT hosts and Monitor Profiles), should be re-entered after migration. These re-entered passwords will be 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.

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.

Back to top

See also: