• Products
  • Get started
  • Documentation
  • Resources

Migrate between next-gen and classic projects

Migrating between next-gen and classic projects is complex, but possible. If your team currently works in a classic project, and you want to migrate to next-gen projects or alternatively if your team gave next-gen projects a try, found that they didn't suit how you work, and you want to move your requests to classic projects.

You'll need to have a new Jira Service Desk project available, so your current project requests have a place to go to.

Create a new next-gen project to receive your existing classic project requests

To create a new next-gen project:

  1. Click your Jira .

  2. Select Projects.

  3. Select Create project > Try a next-gen project.

  4. Make sure you've selected a service desk. You can select Change template to view all available next-gen templates.

  5. Enter a name for your new project and Create.

Create a new classic project to receive your existing next-gen project requests

Your Jira admin will need to create a new classic project for you. Reach out to them for help. Learn more about creating classic projects.

To create a new classic project:

  1. Click your Jira .

  2. Select Projects.

  3. Select Create project > Classic project.

  4. Make sure you've selected a service desk. You can select Change template to view all available classic templates.

  5. Enter a name for your new project and Create.

Find and move existing requests to your new project

Now that you have an empty project waiting to receive your old project's requests, you can move existing requests into the new project.

To complete this step, ask your admin to grant you the Make bulk changes global permission. Learn more about global permissions.

Search for your existing requests

First, you need to find the requests you want to move:

  1. Click your Jira to navigate to the Jira home page.

  2. Select Filters.

  3. Select All issues.

  4. Click the Project filter, and select the project with the requests.
    (If you're looking at the Advanced mode, you'll need to select Basic.)

  5. In the top-right corner, select more (•••) > Bulk change all. The Bulk Operation wizard appears.

Project filter listing available projects
Bulk changes menu

 

Move your existing requests into your new project

Follow the Bulk Operation wizard to move your requests into your new project:

  1. Select the requests you want to migrate > Next.

  2. Select Move Issues > Next.

  3. On the Select Projects and Issue Types screen, select a destination.

  4. On the Map Status for Target Project screen, select a destination status for each request in your old project. Each request in your next-get project will take on this status in the new project.

  5. On the final screen click Confirm.


Things to keep in mind if you migrate from classic to next-gen

Next-gen projects and classic projects are quite different. You can read about the differences between classic and next-gen projects. We’ve included some things to consider when you migrate from a classic to a next-gen project.

Elements in next-gen

You will need to recreate your existing project’s configuration for your new project, so that elements in your classic project can be migrated. This includes things like queues, reports, customers, request types, portal configuration, custom notifications, language support, automation rules, SLAs, approvals, workflows, and fields.

Components

Component fields are unique to every project in Jira. If you migrate issues with completed component field information, you will lose this data. This data is not recoverable, even if you bulk move these issues back to the classic projects they came from.

Custom fields

To migrate, you need to recreate your custom fields in your new next-gen project. Next-gen project fields are independent of global custom fields. When you move requests to a next-gen project, Jira retains most of your request's global custom field values (except the component and version fields). However, these are not mapped to your next-gen project's fields.

Your global custom field data is stored against your requests but the fields in your classic project are technically different from the fields in your next-gen destination, so when migrated they will appear blank. The data is recoverable if you move the issues back to the classic projects they came from.

Project and request keys

Project keys are unique and can never be reused in Jira. If you migrate your requests to another project, they will get new keys and the new project must have a different key. If you move a request to another service, Jira will automatically redirect any links to your old request keys. Learn more about project keys.

Resolution field

Next-gen projects don’t use the same resolution field that exists in classic projects, and have a different way of determining whether an issue is considered “Done”. Whilst in classic projects you might use the JQL resolution = unresolved to find open issues, in Jira Service Desk next-gen projects you’ll need to change this to statusCategory != Done.

Email request type

Requests sent to your service desk’s email address are automatically added to your queues, so your team can focus on customers without managing multiple places to work. In classic projects, you can configure this so that email requests are created with a custom request type you have configured. However, in next-gen, we create a dedicated request type for all email requests which cannot be changed. Learn how to set up request types in next-gen service desks.

Request types and issue types

In classic projects, each request type is associated with an issue type. These issue types can be shared across projects in your Jira site. Request type fields are based on their associated issue type fields.

In next-gen projects, each project has its own request types that can’t be shared across projects. This means that each next-gen project has its own request types that are independent of other projects. Next-gen request type fields are dragged and dropped within a project without impacting request types in other projects (or going to Jira settings). Learn more about issue and request types in classic and next-gen projects.

Filters

Filters will not be automatically migrated, you’ll need to update them. Learn more about filters.


Things to keep in mind if you migrate from next-gen to classic

Next-gen projects and classic projects are quite different. You can read about the differences between classic and next-gen projects. We’ve included some things to consider when you migrate from a next-gen to a classic project.

Elements in next-gen

You will need to recreate your existing project’s configuration for your new project, so these elements in your next-gen project can be migrated. This includes things like queues, reports, customers, request types, portal configuration, custom notifications, language support, automation rules, SLAs, approvals, workflows, and fields. Learn about how workflows are different between classic and next-gen projects.

Request types

Issue and request types differ between classic and next-gen projects. The request types in your next-gen project can be mapped directly to the request types in your classic project. You will have to recreate these request types, as they cannot be copied across. Learn more about request types.

However, if you need to change the fields or workflows for a certain request type, you will need to change the underlying issue type. Your Jira admin will need to change the issue type scheme associated with your project. Learn more about issue type schemes.

Custom fields

If you customized the fields that appear on your next-gen request types, you'll need to have a Jira admin recreate these fields in your new classic project's screen schemes and field configuration schemes. Learn more about issue custom fields.

Your custom field data is stored against your requests but the fields in your next-gen project are technically different from the fields in your classic destination, so when migrated they will appear blank. The data is not recoverable if you move the issues back to the next-gen project they came from.

Project access

Access to classic projects is controlled by a permissions scheme. Only your Jira admin can update your classic project's permission scheme. You may want to confirm your classic project’s permission setup after creation. Learn more about configuring permissions.

Project and issue keys

Project keys are unique and can’t be reused in Jira. If you migrate your requests to another project, they will get new keys and the new project must have a different key of its own. If you migrate your requests using the request migration process, Jira will automatically redirect any links to your old request keys. Learn more about project keys.

Resolved issues

Classic and next-gen projects have different ways of determining whether an issue is considered Done. Whilst in next-gen projects you might use the JQL statusCategory != Done to find open issues, in classic projects you’ll need to change this to resolution = unresolved and ensure that the resolution field has a value.

Filters

Filters will not be automatically migrated, you’ll need to update them. Learn more about filters.

Last modified on Apr 24, 2020
Cached at 11:24 PM on Oct 20, 2020 |

Additional Help

Ask the Community