Get started with Jira Service Management for admins
Your first stop for learning how to get started with Jira Service Management.
Migrate between team-managed and company-managed projects
Migrating between team-managed and company-managed projects is complex, but possible. If your team currently works in a company-managed project, and you want to migrate to team-managed projects or alternatively if your team gave team-managed projects a try, found that they didn't suit how you work, and you want to move your requests to company-managed projects.
You'll need to have a new Jira Service Management project available, so your current project requests have a place to go to.
Create a new team-managed project to receive your existing company-managed project requests
To create a new team-managed project:
Click your Jira .
Select Projects.
Select Create project > Try a team-managed project.
Make sure you've selected a service project. You can select Change template to view all available team-managed templates.
Enter a name for your new project and Create.
Create a new company-managed project to receive your existing team-managed project requests
Your Jira admin will need to create a new company-managed project for you. Reach out to them for help. Learn more about creating company-managed projects.
To create a new company-managed project:
Click your Jira .
Select Projects.
Select Create project > company-managed project.
Make sure you've selected a service project. You can select Change template to view all available company-managed templates.
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:
Click your Jira to navigate to the Jira home page.
Select Filters.
Select All issues.
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.)In the top-right corner, select more (•••) > Bulk change all. The Bulk Operation wizard appears.
Move your existing requests into your new project
Follow the Bulk Operation wizard to move your requests into your new project:
Select the requests you want to migrate > Next.
Select Move Issues > Next.
On the Select Projects and Issue Types screen, select a destination.
On the Map Status for Target Project screen, select a destination status for each request in your old project. Each request in your team-managed project will take on this status in the new project.
On the final screen click Confirm.
Things to keep in mind if you migrate from company-managed to team-managed projects
Team-managed projects and company-managed projects are quite different. You can read about the differences between company-managed and team-managed projects. We’ve included some things to consider when you migrate from a company-managed to a team-managed project.
Elements in your company-managed projects
You will need to recreate your existing project’s configuration for your new project, so that elements in your company-managed 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 company-managed projects they came from.
Custom fields
To migrate, you need to recreate your custom fields in your new team-managed project. Team-managed project fields are independent of global custom fields. When you move requests to a team-managed 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 team-managed project's fields.
Your global custom field data is stored against your requests but the fields in your company-managed project are technically different from the fields in your team-managed destination, so when migrated they will appear blank. The data is recoverable if you move the issues back to the company-managed 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
Team-managed projects don’t use the same resolution field that exists in company-managed projects, and have a different way of determining whether an issue is considered “Done”. Whilst in company-managed projects you might use the JQL resolution = unresolved to find open issues, in Jira Service Management team-managed projects you’ll need to change this to statusCategory != Done.
Email request type
Requests sent to your service project’s email address are automatically added to your queues, so your team can focus on customers without managing multiple places to work. In company-managed projects, you can configure this so that email requests are created with a custom request type you have configured. However, in team-managed projects, we create a dedicated request type for all email requests which cannot be changed. Learn how to set up request types in team-managed service projects.
Request types and issue types
In company-managed 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 team-managed projects, each project has its own request types that can’t be shared across projects. This means that each team-managed project has its own request types that are independent of other projects. Team-managed 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 company-managed and team-managed 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 team-managed to company-managed
Team-managed projects and company-managed projects are quite different. You can read about the differences between company-managed and team-managed projects. We’ve included some things to consider when you migrate from a team-managed to a company-managed project.
Elements in team-managed projects
You will need to recreate your existing project’s configuration for your new project, so these elements in your team-managed 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 company-managed and team-managed projects.
Request types
Issue and request types differ between company-managed and team-managed projects. The request types in your team-managed project can be mapped directly to the request types in your company-managed 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 team-managed request types, you'll need to have a Jira admin recreate these fields in your new company-managed 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 team-managed project are technically different from the fields in your company-managed destination, so when migrated they will appear blank. The data is not recoverable if you move the issues back to the team-managed project they came from.
Project access
Access to company-managed projects is controlled by a permissions scheme. Only your Jira admin can update your company-managed project's permission scheme. You may want to confirm your company-managed 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
Company-managed and team-managed projects have different ways of determining whether an issue is considered Done. Whilst in team-managed projects you might use the JQL statusCategory != Done to find open issues, in company-managed 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.
Was this helpful?
Still need help?
The Atlassian Community is here for you.