Issue migration between Jira projects can usually be handled in two ways:
- same instance tendentially using
MoveorBulk Move; - different instances tendentially using export/import or API/script.
Migration Within the Same Instance Method 1
This is the simpler case.
Main steps
- filter the issues to migrate;
- use Move or Bulk Change;
- select the target project;
- map issue types, statuses, and required fields;
- confirm and validate the result.
What to check first
- issue types available in the target project;
- compatible custom fields;
- workflows and statuses;
- permissions;
- automations and notifications.
Migration Method 2 Between Projects: CSV Export and Import
Recently, I found myself working on a specific Jira use case that comes up more often than expected: migrating issues from one Jira project to another.
At first glance, it sounds like a straightforward activity, but in practice it can become quite complex depending on the project configuration. In my case, although this method is typically used for migrations between two different Jira instances, I applied the same logic to migrate issues between two projects in the same instance. It turned out to be a practical option, especially because there were many issues to move and the standard approach was not the most convenient one.
The first attempt was not as smooth as expected. I ran into several issues caused by missing fields, incompatible configurations, and values that did not exist in the target project. That was a useful reminder that even a migration that looks simple on paper depends heavily on how well the target structure is prepared.
In this article, I want to share the most practical native approach I used for this activity: CSV export and CSV import.
When This Approach Makes Sense
This method is useful when the goal is to migrate:
- issue content;
- standard fields;
- basic custom fields;
- issue types and statuses that already exist in the target project.
It is commonly used when the source and target projects are on different Jira instances, but it can also be a convenient solution within the same instance when you need to migrate a large number of issues and want more control over the process.
Exporting the Issues from the Source Project
The first step is to export the issues from the source Jira project.
To do this:
- Open the Jira site.
- Go to Filters -> Advanced issue search.
- Run the JQL query for the issues you want to migrate.
For example:
project = ABC ORDER BY key ASC
Once the result list is displayed:
- Click Export.
- Select CSV (all fields).
This will generate the file that you will later import into the target project.
Preparing the Target Project
Before importing anything, I found it important to check that the target project was actually ready to receive the data.
In particular, the target project should already contain:
- the required issue types;
- compatible workflows and statuses;
- the necessary custom fields;
- matching select list values;
- valid users for assignee and reporter fields.
This was exactly the point that created the first problems in my case. If one of these elements is missing, the import can fail or produce incomplete issues, which means you often spend more time fixing the target structure than running the migration itself.
Importing the CSV into the Target Project
Once the file is ready, the next step is to import it into the target project.
In Jira, go to:
- Settings -> System
- External system import or Import and export
- CSV
Then:
- Upload the exported CSV file.
- Select the target project.
- Map each CSV column to the corresponding Jira field.
- Review the configuration.
- Start the import.
The field mapping is the most sensitive part of the process. At minimum, I recommend checking:
- Summary
- Description
- Issue Type
- Status
- Priority
- Assignee
- Reporter
- Due date
- Parent or Epic link
- Required custom fields
Validating the Result
After the import, I would strongly recommend opening the target project and validating the result before considering the migration complete.
The main checks are:
- total number of imported issues;
- issue types;
- statuses;
- field values;
- Epic or parent relationships;
- missing or incorrectly mapped fields.
Even in a simple migration, this validation step makes a big difference.
What CSV Does Not Handle Well
One important lesson from this kind of activity is that CSV works well for simple structures, but it has clear limitations.
It does not reliably preserve:
- comments;
- attachments;
- issue links;
- history;
- SLA data;
- JSM request types;
- Assets fields.
So while the method is useful, it should not be seen as a full-fidelity migration for every Jira scenario.
When You Need a More Advanced Method
If the migration must include comments, attachments, links, or Jira Service Management-specific data, then CSV is usually not enough.
In those cases, the better options are:
- REST API;
- custom scripts;
- dedicated migration apps.
These methods require more setup, but they also provide much more control over the final result.
Recommended Migration Flow
Looking back at this use case, the cleanest workflow is:
- Export the issues from the source project.
- Check the target project structure.
- Run a test import with a small issue set.
- Fix any field mapping problems.
- Run the full import.
- Validate the final result.
Additional Checks for Jira Service Management
If the migration involves Jira Service Management, it is also important to verify:
- request types;
- queues;
- SLA configuration;
- organizations;
- portal fields;
- Assets fields.
These elements are often not migrated correctly with CSV alone.
Final Note
Working on this specific case was a good reminder that migrations are never just about moving tickets from one place to another. Even when working within the same Jira instance, the success of the activity depends on preparation, field compatibility, and careful validation.
For a simple migration, CSV is often enough. For more complex scenarios, especially those involving Jira Service Management or richer issue relationships, a more controlled method such as API, scripts, or a migration tool is usually the better choice.
Sara Ferrari
Author
