Hi Sai,
There are a few solutions available in the market for migration from Rally to Jira. These plugins are broadly divided into 2 categories based on the approach being used for migration.
1. CSV based export & import (with downtime):
-Only basic data (Basic fields, simple descriptions, etc.) can be migrated. Here, the field formatting between systems must also be taken care of manually. In your case, Rally uses HTML for rich text formatting while Jira uses Wiki, so before import, this formatting needs to be done as per the target end system.
-Generally, it won't preserve test data, comments, attachments, and relationships.
-Can only import of a limited number of issues in a single import and is a tedious process.
-Error-prone when the size and complexity of the migration increases.
-There would be downtime, which means the target system cannot be accessed during migration.
2. API-based migration (with no downtime):
-All types of fields (system or custom) can be migrated. Field formatting between systems is also automatically taken care of.
-Preserves test data, comments, attachments and relationships.
-Modelling can also be taken care of without impacting your business continuity and productivity, ensuring a smooth migration experience.
-It works well when the migration's size and complexity are high and less prone to errors as automation is involved.
-No downtime: Your team can continue working on projects with minimal disruption, as migration happens in the background.
Migrations are typically a complex and risky process- you need careful planning as you decide on an appropriate migration strategy, before you begin to evaluate the different options. You should understand the challenges that are involved in the migration process. These factors help select an appropriate plugin or migration tool for your organization's use case.
Based on our experience, here are the few factors/challenges and pre-checklist that should be considered before selecting an appropriate plugin/migration tool.
Challenges:
1) Format change: Rally uses HTML for rich text formatting, while Jira uses Wiki. So, it would help if you planned such format conversion [Like how to convert HTML format to Wiki for the data being migrated].
2) Sprint migration with Open State: If Sprints are being migrated, those need to be migrated with Open State until all other issue types are migrated. Additionally, the Sprint's status needs to be reconciled as per Rally in Jira.
3) Model mismatch between Rally and Jira: Jira only allows you to retain the test result of the last Run, i.e., there can be only a single Test Execution record for a given Test Case and Test Set (unlike Rally, which allows you to record the result of every Run). Jira would be able to absorb most of Rally Test data, other than Rally Test Results - Rally Test cases will move to Zephyr Test Case, Rally Test Plan to Zephyr Test Folders, Rally Test Set to Jira Test Cycle and Rally Test Result to Jira Test Execution.
4) Loss of entity context and activities: Opt for a plugin/solution that migrates the data with history to prevent data loss.
5) Impact on user productivity: Plan the migration so that the user can use the system during the migration so that it does not negatively impact/downtime on the overall organization's operations.
6) Data variability: Select the migration tool which is robust enough to take care of data movement, deletion, and project restructuring during incremental migration.
7) Migration Failure or Data mismatch: Look for a solution that takes care of data recovery and Rollback Mechanisms in case of a migration failure or improper data migration.
Pre-checklist for Migration
1) Dedicated migration team
-Team of infrastructure engineer, end systems admin, migration manager, validation lead, and business executive, among others.
-Establish clear roles and responsibilities for every stakeholder.
2) Thorough upfront planning
-Data incompatibilities listing and solution sign-off for each incompatibility.
Application throttling planning – setting up additional nodes, understanding rate limits.
Performance tuning – caching, timeouts, disk space OF the database, migration tool, end systems.
3) Phased migration
-For 500+ users, do not go big bang and move everything in one go. It's suggested to perform migration in this sequence - UAT >> Pilot (2% projects) >> Phase 1 (10% projects) >> Phase 2 (30% projects) >> Phase 3 (40% projects) >> Last phase (remaining projects).
4) Configuration and maintenance as an automated program
-Automation to configure and maintain migration configurations to reduce human error.
-Data-driven migration progress reports – entities migrated, pending migration, entities in error for each project.
5) Change management & synchronous validation
-Requirement changes are inevitable. Plan for reconciling the already migrated data.
-Validation should be started from day one of the migration kick-off and not in the end.
OpsHub, an Atlassian partner, has extensive expertise in undertaking complex migration projects, ensuring zero downtime, preserving data integrity, executing systematic cutovers, and employing a factory-style approach.
You can explore a case study to gain insights into how OpsHub Migration Manager (OMM) facilitated a seamless migration to Jira.
We are happy to help you with your migration planning process. Feel free to get in touch with our solutions architects for an initial free consultation on migration planning.
Thanks,
OpsHub team
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.