Jira NextGen migration
How to migrate a Project from Next Gen to Classic in Jira
Situation might occur where you need to consider a Jira NextGen migration to classic project (Example: migrating from cloud to server or the plugin you use doesn’t support NextGen). Unfortunately the move is not straightforward and you might end up losing data along the way. This article will assist you with your next Jira NexGen migration and help you keep almost everything
Things to bear in mind :
Next Gen was created for Jira cloud to give team more power and responsibilities. Anybody can create and manage NextGen projects unlike Jira Classic projects which demands jira-admin and project administration permissions. It’s very actually complete with a lot of features available, like roadmaps, Kanban and Scrum boards and few reports. But of course, it has it’s loads of drawbacks. One of them is less flexibility in workflows conception or multiple resolution status. Each project is a stand alone and any configuration will disappear with the project if deleted. We understand the rationale behind it, Atlassian wanted to avoid any conflicts with Jira classic project configurations (handled by Jira Admin). So custom fields are unique to the project. Follow this link to get a glimpse of what is possible or not during the migration from NextGen to Classic.
Gone… baby gone
Custom fields will need to be recreated (and value inserted the same way if needed for the mapping) by the Jira Admin to be able to make the move. Failing to do so will lead to missing data after the migration.
Versions and components will be deleted. Since versions and component are unique to a project, it will not be possible to keep the data when bulk moving the issues. We will show you later in this article how to keep the data though.
The Epic link will need to be established. Due to the architecture of NextGen projects, Epic Link will not be carried over during the move unless an Epic Link Name is created during the bulk move.
Possible issue
Target project has some required field that were not present in the source project. Workaround : Apply a temporary Custom Field Configuration Scheme which just have the basic required fields (Summary, Issue Type) before the migration to all the issue types and then remember to map the correct the Custom Field Configuration Schemes after the migration. It’s the simplest way otherwise, you will have to ask the team working on the project to fill out any missing required field before the migration, and sometimes we are talking about hundreds of them.
Keeping the data
Fields like versions can be retained by following these steps before starting the migration : Get a list of all the versions from the source project. If the list is short you can recreate them in the target project by using cautiously Copy and Paste. If you are dealing with a lot, then we suggest getting a csv file (from the advance issue search). Create a csv file with one column summary and the other one named version. In the version column put the versions from the source project, one per line. and put anything in the corresponding summary line (like 1,2,3 etc…). Save it as a csv. Import it in Jira via the system import csv option and select the correct target project. This will create x number of issues with a version. Delete all these newly created issues.
You can use this technique for any use case where you have a lot of values to enter for a custom field not just migration (example : a drop down with 50+ choices)
Now you can go ahead with the migration.
Create a site back up (This operation can take a lot of time !). Download the XML created (It should be available for 7 days)
Export a csv of all the issue with all the fields selected. If there are more than 1000 issues, remember there is a limitation in Jira cloud so you will have to add &pager/start=1000 for 1000 to download the next 1000 and &pager/start=2000 for the next one and so forth…
You will be able to see from the csv which custom fields are not gonna be carried over (they start with “custom field”). Look for the ones that needs to be migrated and make sure the Classic project has them if you want to map them. Prepare a csv with column Summary, Issue Key and columns of Custom Fields to migrate. Verify that you don’t have duplicates in Summary as this column will be the key for mapping. Lets call the file post-migration-cf.csv
Start the Bulk Move
- Make sure you map Statuses and Issue Types correctly. We advise to move Epics with their children to not break the tie. Use a JQL query to find them. Then move the rest of the issues.
- For Epic Link Name you can enter any type of value it will be common to all Epics. You will have to rename them after migration so Each Epic will have its proper name.
- Remember, Jira will migrate only the standard fields shared between a Classic and a NextGen Project.
- After the bulk move, proceed to the bulk upload of the file post-migration-cf.csv
- Map the custom fields and the value if needed
The migration is done and you should have a Classic Jira project very close to what you had in NextGen. Adjust the other schemes to suit your needs
If you need experts for your Jira NextGen migration: contact us, we will be more than happy to assist you, we are Atlassian certified experts
