When teams start planning a Jira migration, one of the first questions that may appear is usually technical: How do we move the data? But there is an earlier question that can actually have an even bigger impact on the project:
What exactly should move to Jira, and what should Jira look like when the migration is finished?
A migration may involve thousands or even millions of records, but volume alone doesn't define complexity. Comments, attachments, custom fields, relationships, hierarchy, users, statuses, and years of historical data can all carry context that teams still depend on.
At Getint, we've seen this while working with organizations migrating between Jira instances and moving to Jira from platforms such as Azure DevOps or ServiceNow. The projects can be very different, but one lesson pops up repeatedly - migration scope deserves to be designed before the migration itself begins.
Let's take a look at some of the decisions worth making before moving the first work item to another system.
Start With Why You're Migrating
Not every Jira migration has the same destination or the same definition of success.
A company consolidating several Jira instances after years of growth has different priorities from a team replacing Azure DevOps with Jira. A merger or acquisition creates another set of requirements, while a Jira Data Center to Cloud migration may involve decisions about years of historical information, right?
Before building mappings or testing migration tools, it helps to connect the scope to the reason behind the project.
Migration scenario | A key question to answer |
|---|
Replacing another platform with Jira | What information will teams need to continue their work in Jira? |
Consolidating Jira instances | Which projects, configurations, and historical records belong in the target instance? |
Merger or acquisition | Which workflows and data need to become part of the shared environment? |
Jira Data Center to Cloud | What needs to move, and what only needs to remain accessible? |
Phased migration | How will teams work while the source and target systems coexist? |
That first decision gives the rest of the migration a clearer boundary.
Separate “Must Migrate” From “We Have It, So Let's Move It”
One of the easiest ways for a migration scope to grow is to treat everything in the source system equally.
A closed work item from six years ago probably doesn't have the same operational value as an active Epic with ongoing discussions, attachments, and related work. At the same time, deleting or abandoning historical information simply because it is old may create compliance or reporting problems.
A useful exercise is to divide the source data into four groups:
- Must migrate: information required for active work, operations, reporting, compliance, or continuity.
- Should migrate: information that remains valuable and is likely to be referenced, even if it isn't needed every day.
- Must remain accessible: historical information that doesn't necessarily need to occupy the new Jira environment but cannot simply disappear.
- Can stay behind: obsolete, duplicated, test, or otherwise unnecessary information that has no meaningful future use.
This doesn't mean that smaller migrations are automatically better. The point is to make the scope intentional. If the answer to Why are we migrating this? is simply because it exists in the old system, it may be worth another discussion.
A Work Item Is More Than a Summary and Description
Once teams know which records should move, the next question is what part of those records needs to survive the migration.
Imagine migrating an active development task while leaving behind its comments, attachments, parent relationship, custom fields, or status. Technically, the task has arrived in Jira. Operationally, part of its meaning may have disappeared.
Depending on the source system and workflow, migration scope can include:
- work item or issue types
- summaries and descriptions
- statuses
- custom fields
- comments and attachments
- users and assignees
- parent-child relationships and hierarchy
- links between related items
- labels and tags
- work logs and other supporting information
This is where migration planning starts becoming less about data volume and more about data context.
A real example: Veryon's Azure DevOps to Jira migration with Getint
Veryon faced this question after acquiring another company and deciding to consolidate work from Azure DevOps into Jira Cloud. The migration needed to support the transition away from Azure DevOps while preserving the information teams required in Jira.
The scope included Tasks, Backlog Stories, and Features, rather than treating Azure DevOps as one undifferentiated dataset. Veryon also defined data integrity as one of its migration success measures: the required information needed to arrive accurately and remain usable after the move.
Before choosing Getint, the team had also evaluated another migration solution. With Getint, Veryon reported being able to get a more complex migration MVP running in less than an hour, which gave the team an opportunity to test the approach before progressing further.
The important part of this example isn't that every Azure DevOps migration should use Veryon's scope. Another organization may need completely different work item types, fields, or history. The lesson is that the target structure and required context should be understood before the full dataset starts moving.
Don't Assume the Source System and Jira Mean the Same Thing
This becomes particularly important when the source isn't another Jira instance.
Azure DevOps, ServiceNow, Asana, and Jira organize work differently. Two fields can sound similar while playing very different roles in the underlying process.
- So migration mapping shouldn't begin with: Which Jira field has the closest name?
- It should begin with: What does this information mean in our current workflow, and where should that meaning live in Jira?
For example, an Azure DevOps work item type needs an intentional Jira work item mapping. Custom fields may need direct equivalents, transformations, or a different structure altogether. Statuses present another challenge: a source workflow with 10 states shouldn't automatically become a Jira workflow with ten corresponding statuses simply because a one-to-one mapping is technically possible.
The same applies to hierarchy. Before moving parent and child records, check whether the target Jira configuration can represent those relationships in the way users expect.
A mapping document created at this stage can save a surprising amount of rework later.
Plan for What Happens While the Migration Is Running
Another scope question is easy to overlook: Can people stop working in the source system while the migration happens?
For a small migration, a short freeze may be realistic. For a larger organization, asking multiple teams to stop updating work for an extended period may not be practical. This is where migration planning starts overlapping with integration.
One possible approach is:
Initial migration → continued work in the existing environment → synchronization of subsequent changes → validation → final cutover
The exact approach depends on the systems and organization, but the decision should be made early. Otherwise, a technically successful migration can still leave teams asking what happened to the records created or changed between the first migration run and the final switch.
This is especially relevant for phased migrations where the old and new environments need to coexist for some time. In that situation, teams need to plan not only the initial data transfer, but also what happens to records that are created or updated while the migration is still in progress.
Define Success Before You Move the First Record
“Migration completed successfully” can mean very different things.
Does it mean that the expected number of records exists in Jira? Or that users, attachments, relationships, fields, and statuses also arrived correctly? Does it mean teams can immediately continue their work?
Before running the production migration, turn success into things you can actually validate.
For example:
- Did the expected number of work items arrive?
- Are the required fields populated correctly?
- Were comments and attachments preserved where required?
- Are parent-child and other relationships intact?
- Do users and assignees resolve correctly?
- Do migrated statuses make sense in the Jira workflow?
- Can users find and understand the historical context they need?
- Were records changed during the migration window accounted for?
Veryon's project provides a useful example here as well. Its success criteria explicitly included complete migration of the required Tasks, Backlog Stories, and Features without loss or corruption, alongside verification of data integrity and usability.
That gives “successful migration” a much clearer meaning than simply reaching 100% on a progress bar.
Test the Scope Before Scaling It
A migration plan can look perfect in a spreadsheet and still reveal unexpected problems once real data starts moving. That's why I would treat a pilot or dry run as part of scope validation, not just technical testing.
Take a representative sample. Include simple work items, but also choose the awkward ones: custom fields, attachments, comments, unusual statuses, hierarchy, relationships, and anything else that could expose a mapping problem.
Then look at the result from the user's perspective.
Open the migrated work item in Jira. Does it make sense? Can you understand what happened before the migration? Are the fields where you expected them to be? Is the hierarchy correct? Would someone who wasn't involved in the migration know how to continue working with it?
Finding that a mapping needs adjustment after 50 test records is manageable. Finding the same problem after hundreds of thousands of records have moved is a very different project.
Migration Scope Is Really a Design of the Target Environment
It's tempting to think about migration scope as a checklist of things leaving the old system. Projects. Issues. Attachments. Comments. Users. Done.
But there is another way to look at it: you're designing what people will find when they open Jira on the other side of the migration. That changes some of the questions worth asking.
- Instead of only asking Can we migrate this field?, ask Will this field still be useful in Jira?
- Instead of Can we reproduce every status?, ask Does the target workflow need every one of them?
- And instead of Did every record move?, ask Can teams continue their work with the context they need?
The migration technology matters, especially when you're dealing with complex mappings, large datasets, or a period when both systems need to remain active. But the tool can only execute the migration you've designed.
Getting the scope right comes first. For those who are researching the possibilities to migrate data and planning a Jira migration:
Which part of defining the scope are you finding the most challenging?
