Open

Overview

This documentation helps to migrate QTM4J 3x data to QTM4J 4x in Jira Server/DC.

What’s get migrated with Server 3x to 4x Utility 

Details

• Execution Result 

  • Execution results will be migrated in 4.x with following attributes – Name, Description, Background color, Sequence Number. 

  • Text color will be ignored. 

• Platform 

  • Platform is renamed as Environment in 4.x and it will be migrated. 

• Project Settings 

  • Execution Preferences – Auto propagate and Execution Result Button Preferences will be migrated in 4.x.  

  • Automation Preferences are not applicable for 4.x, so they will not be migrated. 

• Import/Export Tool -> Authentication 

  • Import Export feature is provided inside 4.x App only, no separate utility will be needed for this. So, API Key will no longer be required to migrate.  

• Project  

  • Project details will be migrated to 4.x along with their status.  

  • QMetry Add-on features on new project functionality is deprecated in 4.x, so it will not be migrated. In 4.x, project administrator will be required to enable QMetry explicitly for new projects. 

• Issue Type 

  • In 4x QMetry can be enabled separately for Story and Defect for individual projects. For all Issue Types which are disabled in 3.x, those will be marked as Disabled as Story Issue Types in 4.x. 

• Storage Tier  

  • Storage tier (Data Directory/FTP/SFTP) related information will be migrated as it is in 4.x. 

• Logging 

  • This functionality is deprecated in 4.x, so it will not be migrated in 4.x. 

• Test Case Jira Issue(s)  

  • Test Case Jira Issues (created in 3.x) will be migrated as Test Cases in 4.x with following attributes - Key, Summary, Description, Priority, Status, Components, Labels, Fix Versions, Sprint, Assignee, Reporter, Attachments, Created, Updated, Custom fields (QMetry supported), Comments, Test Steps.  

  • Activity, Issue Links, affected version, Votes, Watchers, Unsupported custom fields, Resolution, QMetry audits, Work log, History, Automation attributes will not be migrated. 

•  Test Scenario Jira Issue(s) 

  • Test Scenario Issue Type is deprecated in 4.x. 

  • Existing Test Scenarios will be migrated as Folders with following attributes – Key, Summary, Description. They will be appearing on Test Case Listing page in 4.x. 

  • Attachments, Comments, Activity, Issue Links, affected version, Votes, Watchers, Custom fields, Resolution, QMetry audits, Work log, History, Priority, Status, Components, Labels, Assignee, Reporter, Fix Versions, Sprint will not be migrated.  

• Test Run Jira Issue(s) 

  • Test Run Issue Type is renamed as Test Cycle in 4.x. 

  • Test Run Jira Issues (created in 3.x) will be migrated as Test Cycles in 4.x with following attributes - Key, Summary, Description, Priority, Status, Labels, Components, Fix Versions, Sprint, Assignee, Reporter, Created, Updated, Attachments, Custom fields (QMetry supported Custom Fields only), Comments etc. 

  • Activity, Issue Links, affected version, Votes, Watchers, Unsupported custom fields, Resolution, QMetry audits, Work log, History, Automation attributes, Test Scenario linkages etc. will not be migrated.  

  • Test Cases linked through Test Scenarios and Story will be linked directly to Test Cycle. Only unique Test Cases will be linked in Test Cycle during migration even if Test Case is linked multiple times via Story or Test Scenario because Test Cycle of 4.x allows to link unique Test Case versions. Story links with Test Run will be migrated but Test Scenario, since deprecated in 4.x., links with Test Run will not be migrated. 

• Test Executions  

  • Test Executions created in 3.x will be migrated in 4.x.  

  • Test Case Execution will be migrated with Execution Result, Comment, Actual Result, Execution Assignee, Executed By, Executed On, Defect Linkages, Attachments, Automation Result (Only for Automated Test Runs), Duration (Only for Automation Test Runs) etc. 

  • Test Step Execution will be migrated with Execution Result, Comment, Actual Result, Executed By, Executed On, Defect Linkages, Attachments, Duration (Only for Automation Test Runs) etc. 

  • Test Run Comment, Test Execution Audit logs, Columns, Filters and other preferences will not be migrated.  

  • In 3.x. if same Test Case is linked to Test Run multiple times, directly or through Story or Test Scenario, in 4.x. Test Case will be linked only once with the Test Cycle. However, separate Test Case executions will be created for each linkage of the Test Case. 

• Folders 

  • Folders on Test Case page will be migrated with test case mappings, and They will be appearing on Test Case Listing page in 4.x. 

  • Cross Project Test Case Mappings will be skipped.   

• Story

  • Story Issue Type will remain as it is in 4.x as Jira Issues only. They will not be considered as QMetry Issues.  

  • Test Scenario Linkages with story will be skipped. 

  • Test Cases under Test Scenarios which are linked with Story will be linked directly with Story and duplicate test cases will be skipped. 

  • Direct Test Case Linkages with story will be preserved.  

• Defects

  • Defect Issue Type will remain as it is in 4.x as Jira Issues only. They will not be considered as QMetry Issues. 

  • Defect Linkages will be migrated.  

• JQL Functions  

  • JQL Functions in 3.x were mainly extending JQL search functionality. However, Test Case and Test Runs are managed as QMetry Issue Types in 4.x, so JQL Functions will no longer be applicable. Thus, they will not be migrated in 4.x.  

• Steps to Reproduce

  • Steps to Reproduce are different in nature, and they do not have 3.x compatibility, so they will not be migrated to 4.x.

• Gadgets  

  • 4.x Gadgets are different in nature, and they do not have 3.x compatibility, so they will not be migrated to 4.x. 

• Reports

  • 4.x Reports are different in nature, and they do not have 3.x compatibility, so they will not be migrated to 4.x.  

• Exploratory Testing

  • Exploratory testing sessions will be migrated to 4.x.  

  • 3.x Exploratory testing sessions are global, they are not project based. But in 4.x, sessions are project based, so all 3.x sessions will be migrated to any one of project in 4.x.  

  • Audit related information will be skipped.  

• Automation

  •  Automation API related endpoint and parameters are changed in 4.x, so User will be required to change this in their configuration. 

  • API Key will remain as it is after migration.  

• Audit log 

  • Jira issue history of Test Case and Test Run will not be migrated. 

  • Audit logs of Configuration for following events will be migrated, 

  • Project enable/disable action 

  • Project Preferences 

  • Issue types enable/disable action 

  • Platform  

  • Execution Result 

  • Re-index  

  • Audit logs of Test Step including create, update, sequence change or delete, will be migrated. 

  • Audit log of Test Cycle for following events will be migrated, 

  • Link or Unlink Test Case 

  • Change Test Case sequence 

Other Migration Rules

•  In custom fields, If the available project context is selected to global (all projects) then those fields will be migrated in all projects. Otherwise, fields will be migrated to that specific project in 4.x.

  • For duplicate Labels in Jira, 4.x will have only one Label.  For example, if in Jira we have two labels ‘xyz’ and ‘XYZ’, during migration in 4.x. either ‘xyz’ or ‘XYZ’ will be created which will have mappings of both.

  • In Jira if custom fields are created with same name, during migration in 4.x. count suffix will be added in Custom Field name. For example, in Jira two custom fields with name ‘CF’ were created, during migration in 4.x. custom fields will have name ‘CF_1’ and ‘CF_2’ as in 4.x. custom field name must be unique. 

Before Running Migration Utility (This step is required for MSSQL database only):

Step 1: Make sure Database Isolation level is properly configured. To check this, Go to Jira Administration > System > Troubleshooting and support tools > Instance Health > Database > Isolation level (This should be same as the following image).

Open

• If it is not same as above, you need to execute the query below in your database system.

  • ALTER DATABASE <DATABASE-NAME> SET READ_COMMITTED_SNAPSHOT ON;

  • (Replace “<DATABASE-NAME>” with the actual database name.)

  • Now, you need to restart Jira Server.

Step 2: Run the following queries in the database.

• DBCC CHECKIDENT ('AO_5A68F6_4X_CFIELD_TYPE', RESEED, 0);

• DBCC CHECKIDENT ('AO_5A68F6_4X_PERMISSION', RESEED, 0);

How to run Migration Utility?

• Only Jira administrator users can execute this utility, thus the user who is going to execute migration must have ensured the required administrative permissions.

• Go to Manage Apps and update the “QMetry Test Management for JIRA (QTM4J)” app to version 4.4.0.1 or 4.4.0.2 from version history in Atlassian Marketplace.

• Once the above step is completed, download and install the QMetry Migration App which will be provided by the QMetry Team. Please refer to the following screenshot.

• Re-index the Jira data (Go to JIRA ADMINISTRATION > System > Indexing > Full Re-index).

• Once the Migration Utility is installed, open the Applications tab under Jira settings Menu. You can see a new section QTM4J Migration is added on the left panel.

• Click on QTM4J Migration. You can see the details appear on the screen at the right. Go through the instructions carefully and check the acceptance check box.

• Click on the Accept and Next button to proceed.

• The next screen displays the summary of data that exists on the QMetry for Jira Server/Data Center 3.x instance. It includes counts of projects and other entities.

• To initiate the migration process, click on the Start Migration button.

The confirmation message pops up.

Note: Once the migration is started, it cannot be canceled.

The migration process is initiated. You can see the overall migration status in percentage along with project-wise migration status.

If the migration process is completed successfully, the screen displays Status like the following screen.

If the migration fails, the status is displayed accordingly on the screen. Users can download the error log by clicking on the Error Logs button and attach to QMetry support ticket.