Upgrading to Jira Server Service Management 2.0 and moving to the version 2 pricing model

Still need help?

The Atlassian Community is here for you.

Ask the community

Use this page if you plan to migrate to the new pricing model for Jira Service Management 2.0.

Jira Service Management version 2.0 introduces a new pricing model. Whether or not you adopt the new pricing model affects your upgrade path. If you want to stay with your pricing model and upgrade to the version 2.0 product, check out Upgrading to Jira Service Management 2.0.

If you're using our Cloud service Atlassian OnDemand, please refer to Upgrading to Jira Cloud Service Management 2.0 and moving to the version 2 pricing model

 

 

On this page

Upgrading to version 2 pricing model for Jira Service Management Server

What's new for me

The Jira Service Management 2.0 Release Notes summarizes the new functionalities and changes you will see after you upgrade to version 2.0.

Before you begin

  • You must have the Jira System Administrators global permission.
  • Check the Supported Platforms  to ensure your version of Jira supports Jira Service Management version 2.0.
  • Make sure that you've read the New pricing model for Jira Service Management 2.0 FAQ.
  • Get a new license key.
    To move to the new pricing model, you will need to apply a new license key to your installation to activate the pricing switch. To get the new license key, you need to contact our advocates team. The FAQ page linked above covers information on how to contact us.  

Stage 1: Installing 2.0 and applying the version 2 license

  1. Make an agent list, i.e. a list of all the users that you plan to assign an agent license seat to. This typically includes both agents and service project administrators. 
  2. Download and install version 2.0.  For instructions, see Install Jira Service Management.
    Notes:
    • After you install 2.0, agents and administrators will see the new People tab and the email channel settings in each service project. Do not make changes to these two sections just yet. You will set up the users in the next stage and after that, it is easier to manage the users on the People tab and configure the email channel.

      Old People tab v.s. the new one
      Screenshot: Old People tabScreenshot: New People tab
  3. Go to   >  User management  >  Groups , locate the  service-desk-agents  group, and add the users on the agent list you made in step 1 to this group. 

    Why?

    Adding your agents to the group in this step ensures that the agents will already have the license allocated to them after you apply the version 2 license key in step 4. This ensures that there will be no down time for agents and they can continue working with issues and communicating with customers while you make the other changes to complete the upgrade in stage 2.  

    The service-desk-agents group and the Jira Service Management agent access global permission are new objects added by version 2.0. Jira Service Management uses these two new settings to manage license allocation. For more information about licensing, see Licensing.

  4. Apply the version 2 license key you get from our advocates to your installation of Jira Service Management.

Stage 2: Migrating the permissions and setting up the users for each service project

 Why?

Upgrading from version 1.1

Before upgrading to version 2.0, you have been using your own permission scheme to control who has access to what in each service project. In version 2.0, you set up permissions by assigning people to the Jira Service Management-specific project roles instead of directly associating them with the permissions in the permission scheme. When you assign people to these roles, Jira Service Management will automatically grant the permissions they'll need for their tasks.

After you install version 2.0, Jira Service Management checks the permission scheme against the standard permission scheme. If the permissions for the Jira Service Management roles are not the same as those in the standard permission scheme, you will see an error. There are two levels of errors: major and minor. You must fix the major ones because they impact your usage of the People tab. To learn more about the errors, see Resolving permission scheme errors.

Because the roles never existed in version 1.1, you will see a long list of missing permissions for each role in the error message and some of them are major errors. Due to these major errors, service project administrators will not be able to use certain functionalities of the People tab, but other users can continue using the service project, e.g. customers can still create requests and agents can work on issues assigned to them. 

To restore the functionalities available on the People tab (e.g. public signup for customers), you need to migrate the permission scheme for each service project to resolve the permission errors. 

What does the error look like?
Screenshot: Permission scheme errorScreenshot: Details of the error

Upgrading from version 1.2

Version 2.0 introduces the new Service Management Collaborators role. After you install version 2.0, Jira Service Management checks the permission scheme against the standard permission scheme. If the permissions for the Jira Service Management roles are not the same as those in the standard permission scheme, you will see an error. There are two levels of errors: major and minor. You must fix the major ones because they impact your usage of the People tab. To learn more about the errors, see Resolving permission scheme errors.

Because the Service Management Collaborators role never existed in version 1.2, you will see a list of permissions that are missing for the role in the error message and some of them are major errors. Due to these major errors, service project administrators will not be able to use certain functionalities of the People tab, but other users can continue using the service project, e.g. customers can still create requests and agents can work on issues assigned to them. 

To restore the functionalities available on the People tab (e.g. public signup for customers), you need to migrate the permission scheme for each service project to resolve the permission errors. 

How?

  1. For each service project, decide who are the project's agents, administrators, customers and collaborators, and then make a list of the users for each role. You can note users down individually or the group names to which they belong. 

    How to decide
    • Agents are the users that need to communicate with customers. Learn more
    • Administrators are the users that manage the service project. Learn more
    • Customers are the users that open requests. Learn more
      (Note: In version 2.0, you can open up your Customer Portal so that all users can open requests in your service project as long as they have an account in Jira Service Management. This is an open service project. If you plan to make your service project an open one, you can leave your customer list blank. We'll look at how to make it open after migrating the permissions.)
    • Collaborators are the users that occasionally assist agents in resolving requests and they do not communicate with customers directly. Learn more
      (Note: You might not have any collaborators at this stage. If that's the case, just leave the collaborator list blank.)

    For example:

    AdministratorsAgentsCustomersCollaborators
    • admin
    • Alice
    • support
    • Jim
    • it
    • John Smith
    • developers
    • project-managers
    • finance
    • hr
    • users
    • support-managers
    • regional-managers
    • William
  2. For each service project, go to the Jira project administration page of the project and locate the Roles section. You will see the Jira Service Management roles there. 
    (Go to  > Projects, choose the project. In the left-hand navigation, click Roles.)
     
  3. Add users on the lists you made in step 1 to the roles.

    • Add the administrators to the Administrators role.
    • Add the agents to the Service Desk Team role. 
    • Add the customers to the Service Management Customers role. 
    • Add the collaborators to the Service Management Collaborators role.
  4. In the header, go to Service Management, and choose your service project. 
    You will see an error message displayed at the top of the screen. To learn the details of permission setup differences between your current permission scheme and the standard one, you can expand the message. 

  5. At the bottom of the message, click the Upgrade permission scheme button. For information about the errors in the message and what the upgrade action does, see Resolving permission scheme errors.
  6. Go to the People tab, check the AgentsCustomers and Collaborators sections to make sure that the users added to the roles in step 3 appear in the right section. 
    Note: Administrators appear on the Agents tab and have the ADMIN icon next to their usernames.
  7. Repeat step 1 to 6 for the other service projects. 

Congratulations! You've finished the upgrade process. Check out the following section for functionalities that might be useful for your service project. 

Next

  • Decide whether you want your Customer Portal to be open or restricted. For details, see Opening up or restricting access to your service project.

  • Public signup for your customers: By allowing public signup for your service project, your customers can easily create user accounts for themselves. If your Customer Portal is an open one, you can enable public signup. For more information, see Configuring public signup.

  • Enable the email channel if you want your customers to be able to create requests by sending emails to your inbox. See Receiving requests by email.

Last modified on Nov 23, 2020

Was this helpful?

Yes
No
Provide feedback about this article
Powered by Confluence and Scroll Viewport.