Rachel Wright is an entrepreneur, Certified JIRA Administrator, and author of the JIRA Strategy Admin Workbook. She started using JIRA in 2011, became a JIRA administrator in 2013, and was certified in 2016. She is the owner and founder of Industry Templates, LLC, which helps companies grow, get organized, and develop their processes.
Sometimes it’s important to understand how far your Jira application has strayed from the default configuration. Was that setting there from the beginning or did an application administrator add it eons ago?
To find out, visit Admin > Issues > Notification schemes in your application. Then use this baseline list to compare your Jira settings to the default.
Initial settings for Jira Cloud and Jira Server/Data Center v8.15 are included below. I keep fresh and untouched application instances around so you don’t have to!
Jira Software Cloud, Server & Data Center Notifications
Sometimes it’s important to understand how far your Jira application has strayed from the default configuration. Was that setting there from the beginning or did an application administrator add it eons ago?
To find out, visit Admin > Issues > Permission schemes in your application. Then use this baseline list to compare your Jira settings to the default.
Initial settings for Jira Cloud and Jira Server/Data Center v8.15 are included below. I keep fresh and untouched application instances around so you don’t have to!
Jira Software Cloud Free & Standard Project Permissions
Scheme name: Default Permission Scheme
Project permissions
Administer Projects
Ability to administer a project in Jira.
Granted to:
Project role
Administrators
atlassian-addons-project-access
Browse Projects
Ability to browse projects and the issues within them.
Granted to:
Project role
atlassian-addons-project-access
Application access
Any logged in user
Manage sprints
Ability to manage sprints.
Granted to:
Project role
atlassian-addons-project-access
View Development Tools
Allows users in a software project to view development-related information on the issue, such as commits, reviews and build information.
Granted to:
Project role
atlassian-addons-project-access
Application access
Any logged in user
View Read-Only Workflow
Users with this permission may view a read-only version of a workflow.
Granted to:
Project role
atlassian-addons-project-access
Application access
Any logged in user
Issue permissions
Assignable User
Users with this permission may be assigned to issues.
Granted to:
Project role
atlassian-addons-project-access
Application access
Any logged in user
Assign Issues
Ability to assign issues to other people.
Granted to:
Project role
atlassian-addons-project-access
Application access
Any logged in user
Close Issues
Ability to close issues. Often useful where your developers resolve issues, and a QA department closes them.
Granted to:
Project role
atlassian-addons-project-access
Application access
Any logged in user
Create Issues
Ability to create issues.
Granted to:
Project role
atlassian-addons-project-access
Application access
Any logged in user
Delete Issues
Ability to delete issues.
Granted to:
Project role
Administrators
atlassian-addons-project-access
Edit Issues
Ability to edit issues.
Granted to:
Project role
atlassian-addons-project-access
Application access
Any logged in user
Link Issues
Ability to link issues together and create linked issues. Only useful if issue linking is turned on.
Granted to:
Project role
atlassian-addons-project-access
Application access
Any logged in user
Modify Reporter
Ability to modify the reporter when creating or editing an issue.
Granted to:
Project role
Administrators
atlassian-addons-project-access
Move Issues
Ability to move issues between projects or between workflows of the same project (if applicable). Note the user can only move issues to a project they have the create permission for.
Granted to:
Project role
atlassian-addons-project-access
Application access
Any logged in user
Resolve Issues
Ability to resolve and reopen issues. This includes the ability to set a fix version.
Granted to:
Project role
atlassian-addons-project-access
Application access
Any logged in user
Schedule Issues
Ability to view or edit an issue’s due date.
Granted to:
Project role
atlassian-addons-project-access
Application access
Any logged in user
Set Issue Security
Ability to set the level of security on an issue so that only people in that security level can see the issue.
Granted to:
Project role
atlassian-addons-project-access
Transition Issues
Ability to transition issues.
Granted to:
Project role
atlassian-addons-project-access
Application access
Any logged in user
Voters & watchers permissions
Manage Watchers
Ability to manage the watchers of an issue.
Granted to:
Project role
Administrators
atlassian-addons-project-access
View Voters and Watchers
Ability to view the voters and watchers of an issue.
Granted to:
Project role
atlassian-addons-project-access
Application access
Any logged in user
Comments permissions
Add Comments
Ability to comment on issues.
Granted to:
Project role
atlassian-addons-project-access
Application access
Any logged in user
Delete All Comments
Ability to delete all comments made on issues.
Granted to:
Project role
Administrators
atlassian-addons-project-access
Delete Own Comments
Ability to delete own comments made on issues.
Granted to:
Project role
atlassian-addons-project-access
Application access
Any logged in user
Edit All Comments
Ability to edit all comments made on issues.
Granted to:
Project role
Administrators
atlassian-addons-project-access
Edit Own Comments
Ability to edit own comments made on issues.
Granted to:
Project role
atlassian-addons-project-access
Application access
Any logged in user
Attachments permissions
Create Attachments
Users with this permission may create attachments.
Granted to:
Project role
atlassian-addons-project-access
Application access
Any logged in user
Delete All Attachments
Users with this permission may delete all attachments.
Granted to:
Project role
Administrators
atlassian-addons-project-access
Delete Own Attachments
Users with this permission may delete own attachments.
Granted to:
Project role
atlassian-addons-project-access
Application access
Any logged in user
Time tracking permissions
Delete All Worklogs
Ability to delete all worklogs made on issues.
Granted to:
Project role
Administrators
atlassian-addons-project-access
Delete Own Worklogs
Ability to delete own worklogs made on issues.
Granted to:
Project role
atlassian-addons-project-access
Application access
Any logged in user
Edit All Worklogs
Ability to edit all worklogs made on issues.
Granted to:
Project role
Administrators
atlassian-addons-project-access
Edit Own Worklogs
Ability to edit own worklogs made on issues.
Granted to:
Project role
atlassian-addons-project-access
Application access
Any logged in user
Work On Issues
Ability to log work done against an issue. Only useful if Time Tracking is turned on.
Granted to:
Project role
atlassian-addons-project-access
Application access
Any logged in user
Scheme name: Default software scheme
Same as the Jira Cloud “Default Permission Scheme” except:
Ability to browse projects and the issues within them.
Granted to:
Application access
Any logged in user
Edit SPRINTS
Ability to edit sprint name and goal.
Granted to: none
Manage sprints
Ability to manage sprints.
Granted to:
Project role
Administrators
Start/Complete Sprints
Ability to start and complete sprints.
Granted to: none
View Development Tools
Allows users in a software project to view development-related information on the issue, such as commits, reviews and build information.
Granted to:
Application access
Any logged in user
View Read-Only Workflow
Users with this permission may view a read-only version of a workflow.
Granted to:
Application access
Any logged in user
Issue permissions
Assignable User
Users with this permission may be assigned to issues.
Granted to:
Application access
Any logged in user
Assign Issues
Ability to assign issues to other people.
Granted to:
Application access
Any logged in user
Close Issues
Ability to close issues. Often useful where your developers resolve issues, and a QA department closes them.
Granted to:
Application access
Any logged in user
Create Issues
Ability to create issues.
Granted to:
Application access
Any logged in user
Delete Issues
Ability to delete issues.
Granted to:
Project role
Administrators
Edit Issues
Ability to edit issues.
Granted to:
Application access
Any logged in user
Link Issues
Ability to link issues together and create linked issues. Only useful if issue linking is turned on.
Granted to:
Application access
Any logged in user
Modify Reporter
Ability to modify the reporter when creating or editing an issue.
Granted to:
Project role
Administrators
Move Issues
Ability to move issues between projects or between workflows of the same project (if applicable). Note the user can only move issues to a project they have the create permission for.
Granted to:
Application access
Any logged in user
Resolve Issues
Ability to resolve and reopen issues. This includes the ability to set a fix version.
Granted to:
Application access
Any logged in user
Schedule Issues
Ability to view or edit an issue’s due date.
Granted to:
Application access
Any logged in user
Set Issue Security
Ability to set the level of security on an issue so that only people in that security level can see the issue.
Granted to: none
Transition Issues
Ability to transition issues.
Granted to:
Application access
Any logged in user
Voters & watchers permissions
Manage Watchers
Ability to manage the watchers of an issue.
Granted to:
Project role
Administrators
View Voters and Watchers
Ability to view the voters and watchers of an issue.
Granted to:
Application access
Any logged in user
Comments permissions
Add Comments
Ability to comment on issues.
Granted to:
Application access
Any logged in user
Delete All Comments
Ability to delete all comments made on issues.
Granted to:
Project role
Administrators
Delete Own Comments
Ability to delete own comments made on issues.
Granted to:
Application access
Any logged in user
Edit All Comments
Ability to edit all comments made on issues.
Granted to:
Project role
Administrators
Edit Own Comments
Ability to edit own comments made on issues.
Granted to:
Application access
Any logged in user
Attachments permissions
Create Attachments
Users with this permission may create attachments.
Granted to:
Application access
Any logged in user
Delete All Attachments
Users with this permission may delete all attachments.
Granted to:
Project role
Administrators
Delete Own Attachments
Users with this permission may delete own attachments.
Granted to:
Application access
Any logged in user
Time tracking permissions
Delete All Worklogs
Ability to delete all worklogs made on issues.
Granted to:
Project role
Administrators
Delete Own Worklogs
Ability to delete own worklogs made on issues.
Granted to:
Application access
Any logged in user
Edit All Worklogs
Ability to edit all worklogs made on issues.
Granted to:
Project role
Administrators
Edit Own Worklogs
Ability to edit own worklogs made on issues.
Granted to:
Application access
Any logged in user
Work On Issues
Ability to log work done against an issue. Only useful if Time Tracking is turned on.
Granted to:
Application access
Any logged in user
Scheme name: Default software scheme
Same as the Jira Server “Default Permission Scheme”.
Jira Software Data Center, Jira Cloud Premium, and Jira Cloud Enterprise Project Permissions
These types of Jira have archival features and additional permissions. Same as the Jira Server “Default Permission Scheme” plus:
Browse Project Archive
Ability to browse archived issues from a specific project.
Where’s the best place to track your Jira migration? It’s the same place you’d track any other strategic company initiative! I always track my work for Jira in Jira. That includes everything from small configuration changes to big projects like migrations and upgrades.
To make it easier for you to manage your migration in Jira, ThinkTilt has added three of my migration templates to their app! The ProForma for Jira app has always been the gold standard for checklists and forms in Jira and now you can use it to manage your migration as well.
73 step Jira migration checklist embedded in an issue with ProForma for Jira
New Templates
The following migration worksheets are now available in the ProForma for Jira template library:
ProForma’s form library includes hundreds of templates to use or customize. Check out these forms in the ProForma demo site or in the ProForma app. Here’s how:
Instructions
Step 1: Install Install the free or paid ProForma for Jira app in Jira Cloud, Server, or Data Center.
Step 2: Create a Form To create a form in a Jira project, click Project Settings > Forms. (Or create from the application admin area at: Admin > Manage Apps > Forms.) Next, click the “Create Form” button on the top right.
Step 3: Choose a Template Choose one of the migration templates. In the form builder, enter “migration” in the search box on the right, as shown. Select a template and make any desired content or setting customizations.
Step 4: Add Form to Jira Issue Finally, create a Jira issue and add the form to it. Click the “Add Form” button, select the form, and complete the form fields as you plan your migration project.
Want to use the worksheets, but don’t have ProForma? Click here to get started.
If you don’t have my new book, The Ultimate Guide to Jira Migrations: How to migrate from Jira Server to Data Center or Cloud, download it now from the Botron website.
If you haven’t done a software migration before, it’s hard to know what to expect. How do you properly plan for something unknown? How does the configuration and amount of data impact complexity? How long will it take? The answers to these questions are different for each organization and application. Use these common misconceptions to help plan and set expectations.
Migration is Quick
The first misconception is that migration is a quick and easy weekend activity. While the actual transfer of data may not take that long, the process of preparing to move the data and testing the results often takes weeks or months.
If you’re migrating six or fewer apps and have less than 750 users, Atlassian classifies the migration as simple. Atlassian recommends to start planning three to six months before the migration date.
If you’re migrating more apps, users, have incompatible apps, or have customizations, you should plan for a more complex migration. Complex migrations may require six to twelve months of planning.
Have you cleared your calendar yet?
Migration is Simple
How complicated could it be? You simply pick up your data and move it, right? Unfortunately, it’s rarely that simple.
Application settings are usually more complex than you think. There are probably settings you forgot about or don’t even know exist. Some features work differently between versions or deployment types. There are apps that work in Server but not in Cloud. You’ll need to uncover your application’s challenges and create a plan to handle them.
While tools exist to help with analysis and the actual data transfer, there’s no “one click” solution to run the entire migration project for you. You should treat this project like any other strategic company initiative. Designate a project manager, create a project plan, and devote more time than you think you’ll need for discovery and testing.
No Strategy Needed
Hopefully by now you’re convinced not to underestimate a migration! Before you start, you should determine an overall strategy. What is your main migration goal? Form a project team of stakeholders and make their first duty to answer this question.
Is the goal to:
Have the target application behave exactly the way it does in the source application?
Migrate all data “as is”?
Only migrate development project data?
Give users different abilities than they had before?
Clean up the configuration before the migration or clean up after (or both)?
All of the above or something else?
Determine your goals in the beginning so you can craft a strategy to support them. Without goals, there’s no way to measure success.
Regardless of the size of your migration or the specifics of your situation, be sure to take your time, do a trial run (or many runs), and don’t perform the final migration until everything is accounted for.
Sometimes it’s important to understand how far your Jira application has strayed from the default configuration. Was that setting there from the beginning or did an application administrator add it eons ago?
To find out, visit Admin > System > Global permissions in your application. Then use this baseline list to compare your Jira settings to the default.
Initial settings for Jira Cloud and Jira Server/Data Center v8.15 are included below. I keep fresh and untouched application instances around so you don’t have to!
Jira Software Cloud Global Permissions
Administer Jira
Create and administer projects, issue types, fields, workflows, and schemes for all projects. Users with this permission can perform most administration tasks, except: managing users, importing data, and editing system email settings.
Users/Groups:
system-administrators
atlassian-addons-admin
site-admins
trusted-users-xxx (unique alphanumeric string)
administrators
jira-administrators
Browse users and groups
View and select users or groups from the user picker, and share issues. Users with this permission can see the names of all users and groups on your site.
Users/Groups:
system-administrators
site-admins
jira-software-users
administrators
jira-administrators
atlassian-addons-admin
Share dashboards and filters
Share dashboards and filters with other users.
Users/Groups:
atlassian-addons-admin
jira-software-users
system-administrators
jira-administrators
site-admins
administrators
Manage group filter subscriptions
Create and delete group filter subscriptions.
Users/Groups:
jira-administrators
jira-software-users
administrators
system-administrators
atlassian-addons-admin
site-admins
Make bulk changes
Modify collections of issues at once. For example, resolve multiple issues in one step.
Users/Groups:
atlassian-addons-admin
jira-software-users
site-admins
administrators
jira-administrators
system-administrators
Create next-gen projects
Create projects separate from shared configurations and schemes. Next-gen projects don’t affect existing projects or shared configurations like workflows, fields or permissions. Only licensed users can create next-gen projects.
Users/Groups:
Public, anyone on the internet, including logged in and anonymous users.
Jira Software Server & Data Center Global Permissions
Jira System Administrators
Ability to perform all administration functions. There must be at least one group with this permission.
Users/Groups:
jira-administrators
Jira Administrators
Ability to perform most administration functions (excluding Import & Export, SMTP Configuration, etc.).
Users/Groups:
jira-administrators
Browse Users
Ability to select a user or group from a popup window as well as the ability to use the ‘share’ issues feature. Users with this permission will also be able to see names of all users and groups in the system.
Users/Groups:
jira-administrators
jira-servicedesk-users (If installed)
jira-software-users
Create Shared Objects
Ability to share dashboards and filters with other users, groups and roles.
Users/Groups:
jira-administrators
jira-servicedesk-users (If installed)
jira-software-users
Manage Group Filter Subscriptions
Ability to manage (create and delete) group filter subscriptions.
Users/Groups:
jira-administrators
jira-servicedesk-users (If installed)
jira-software-users
Bulk Change
Ability to modify a collection of issues at once. For example, resolve multiple issues in one step.
“The way you should implement new things in Jira is to think about how you’ll report on those things. Always start with reporting needs and work backward.”
Join Rachel Wright and Manuel Pattyn from iDalko, a Platinum Atlassian Solution Partner, as we discuss Jira clean up. In this episode of the Atlassian.FM podcast, we cover how to start a Jira clean up, common pitfalls to avoid, and how to overcome common challenges like too many admins, customizations, or competing ideas.
Listen in podcast format or read the written transcript on the iDalko website.
Are you still opening Jira to search Jira? That’s so 2020! There’s a much faster way. Instead, use your browser’s “search engines” feature to quickly jump to Jira projects, issues, and pages. No navigation or clicks required!
This is my absolute favorite Jira tip because it saves time. Once it’s set up simply type a specific set of characters to jump straight to your favorite Jira locations!
Example
In the video, I’ve set my browser to take me to the “DEMO” Jira project when I type: “p“ tab “DEMO” in the address bar.
After I type “p” and a space, my address bar changes to a search bar that looks like the screenshot below.
Notice how the address bar changes
After I type “DEMO” and press the “Enter” key, I’ll be directed to the DEMO project in Jira.
Similarly, I’ve designated the “i” character to go to a specific issue ID and other characters for other frequently accessed Jira admin pages. Here’s how to set it up:
Chrome Browser Instructions
Let’s set up the “i” character to visit a Jira issue like in the example above.
Launch the Chrome browser
Right click in the address bar and select “Manage search engines”
Click the “Add” button next to the “Other search engines” header
In the “Add search engine” overlay, enter:
“Jira Issue” in the “Search engine” field
“i” in the “Keyword field
“https://your-jira-url.com/browse/%s” in the “URL with %s in place of query” field
Click the form submission button
Chrome “Add search engine” overlay
The “%s” in the URL is a variable and represents a word or phrase you’re searching Jira for.
That’s it! To try it out, type the “i” key, then the “tab” key, then any Jira issue ID in the browser’s address bar.
Example: “i“ tab “DEMO-1“
The browser will take you directly to the URL for issue DEMO-1. It’s easy and the possibilities are endless!
Sample Jira URLs
To craft other Jira search URLs, simply find a location in Jira, copy the URL in the address bar, and substitute “%s” for the variable search term. Here are some examples:
You can this same trick with other applications and websites that have predictable search URL patterns like, Confluence, Dictionary.com, Twitter, and even your own website. I frequently use “d“ tab “word” to look up a word at dictionary.com.
You can also do this in other browsers. Here are the Firefox instructions, for example.
Have a useful Jira tip to share? Add it to the comments below!
As a consultant, I’ve seen a lot of different Jira configurations and helped plan many migrations, merges, and moves. Sometimes the effort is small, like moving a Jira project from one application to another. Other times it’s porting an entire application to a different hosting environment or combining multiple large instances together. Regardless of the scope or effort, organizations often make two big mistakes. They are:
Lack of Preparation
The most common mistake is poor planning. A migration is rarely a quick and easy activity. It requires many hours of discovery, multiple dry runs, and testing.
Organizations often rush to complete the effort without performing enough pre-migration analysis. They don’t take the necessary time for due diligence. When proper analysis isn’t done, impactful setting differences are missed, data is mistakenly omitted, and Jira doesn’t function the way users expect.
Examples
When security and permission settings aren’t handled properly, users don’t see data they expect.
If email settings aren’t considered, end users may receive more or fewer notifications than expected.
If data from third-party apps isn’t migrated, users won’t see information and functionality they are used to.
Remedy
There’s no substitute for a proper upfront analysis and verification before the final event. You need to understand the application configuration intimately, clean up unneeded schemes and settings, archive projects and issues you no longer need, and make sure the application is healthy before migrating any data.
You need to thoroughly test the migration results in a staging application, often multiple times, until everything is perfect.
Lack of Communication
The second most common mistake is poor communication with stakeholders. Before you even start the project, you need to identify the many types of impacted users, how they will be impacted, and what kind of participation is expected from each. The migration effort should never be a surprise to anyone!
Examples
The Finance Department wasn’t informed of the migration and had to shuffle money around when license fees increased.
Not all data was migrated and the Help Desk team was bombarded with user trouble reports.
A Developer logged in to find Jira was not connected to critical build tools.
The Compliance Team failed an audit because settings in the new application conflicted with company policy.
Remedy
Just like with any large company strategic initiative, Migration Team members need to a good job communicating and managing expectations. Overcommunicate at each step. At a minimum, users need to verify that their data is as expected in the staging and production environments. Involve users early and often.
In October 2020, Atlassian announced they will stop selling new Server licenses on February 2, 2021. Further, they will end support for Server products on February 2, 2024. This means customers like me will need to switch to Data Center, migrate to Atlassian-hosted Cloud products, or make alternate plans.
It’s no surprise that this announcement brought a mixed reaction from the user community. There was a lot of initial shock and emotion as the online forums erupted with commentary. It took me a while to process all the information and I’m finally ready to share my opinions.
Before I do, there’s something you should know. It’s no secret; I’ve been in a relationship with Jira since 2011.
But before I discovered Jira, I was in love with Salesforce. I fell in love with both applications for the same reasons: both were infinitely flexible and let me configure them exactly the way I wanted. I could adapt the software to fit my needs without changing my behavior.
A well-worn Salesforce conference giveaway
I attended a Salesforce user conference and brought home a giveaway that I still have today. This little mint container displays Salesforce’s trademark “no software” logo. At first I didn’t understand. How could a software company be anti-software? The logo conveys that Salesforce said “no” to the familiar concept of hosted software and “yes” to cloud infrastructure instead. I acquired this item sometime around 2005. So ~15 years later, the fact that the software industry has pivoted to leverage the cloud is not a huge surprise. Cloud proponents might ask why Atlassian took so long to make their announcement! Don’t get me wrong, I’m a HUGE Jira Server fan and I will always love and prefer it. But asking Atlassian to develop and support multiple deployment methods, with different code bases, features, and terminology is a terrible long term business plan.
Cloud is Inevitable
This announcement was ultimately inevitable but it doesn’t mean it will be an easy road for everyone. There are certainly organizations with a real or a perceived aversion to cloud software. Some industries have complex governance and compliance regulations to consider and there are data residency concerns and latency issues to resolve. There are consultants facing real challenges with helping their clients through this transition. There are Jira Server administrators wondering if moving to Cloud means their role is unnecessary or redundant. (Not at all! Cloud applications need competent administrators to manage and maintain the configuration. There are just a few things you won’t need to do anymore. Example: a manual re-index.)
Some Options
For customers who can afford it, switching from Server to Data Center can be as easy as simply pasting in an updated license key and installing Data Center compatible apps, assuming they exist. Jira Data Center has some attractive features, like clustering (multiple applications), archival, high availability, redundancy, disaster recovery, etc, but you don’t have to use them. You can simply run Data Center as non-clustered (single) application.
For customers who are open to migrating to Cloud-hosted products, there are cost, feature, app, and user interface differences to consider. Migration is not a simple weekend project, but with adequate analysis, planning, and testing, it is doable.
I have to give Atlassian credit for announcing this change years in advance. At the very least, we all have adequate time to prepare or make alternate plans. They have visibly invested in their Cloud infrastructure and there’s still a lot of time before “end of life” to address the outstanding concerns. Atlassian has provided migration information, created a new Cloud tool to help move data, and publicly addressed our gripes – although I understand that not all will be satisfied with the responses. Some customers feel forgotten, disrespected, or excluded. I can understand that perspective and don’t intend to disregard or minimize those feelings.
Pricing Concerns
Many of us are concerned with price increases. The Data Center cost is simply out of reach for some organizations. As a consultant, I keep a Jira Server instance running simply to take screenshots, create training materials, and support my clients using Server. This is a test instance and I am the only user. My annual starter license cost is $10 USD. If I understand correctly, to simply change to a Data Center license, my annual cost increases to over $20,000 USD. This is simply impossible and unreasonable. If true, it means small consultancies like mine can’t properly support Data Center clients in the future. It’s crazy to think that I can’t afford the software I love so much and help others manage! I’ll have to try to keep my sandbox Jira Server instance running as long as possible or until it’s no longer useful for its intended purpose. For charitable and non-profit organizations, I’m happy to see that free Data Center licenses are now available.
Change is Constant
Change is hard. I understand and sympathize. But change is also constant in this world. The only thing you can control is how you react to change. I’m trying to improve the way I personally respond and in this situation, I’m choosing to find ways to see this as a positive opportunity. For example, I have the ability to help organizations determine the best path for their unique needs. I can help companies reduce risk during their migrations. And I can learn to love Jira Cloud as much as Server – or at least try.
If you plan to change to Jira Data Center, migrate to Jira Cloud, have multiple Jira Server applications to consolidate, or simply feel lost about what to do next, there’s a new resource just for you! I teamed up with Atlassian Solution Partner Botron Atlassian Apps to create The Ultimate Guide to Jira Migrations: How to migrate from Jira Server to Data Center or Cloud. This free 180 page ebook is the master resource to answer all your migration questions and provide a comprehensive plan to follow.
Regardless of your situation, take a deep breath, and try to work towards arriving at the “acceptance” stage of this announcement. You’ve likely survived bigger software challenges and I have no doubt you will get through this one as well. Until then, I wish you the very best of luck, success, and prosperity in the new year.
Software migrations are fact of life and Jira is no different. No solution fits forever and organizations must pivot as needs and industry capabilities change. As systems evolve, features grow, and infrastructure becomes obsolete migrations and consolidations are inevitable.
In October 2020, Atlassian announced they will stop selling new licenses of their Server products. Customers need to switch to Data Center, migrate to Atlassian-hosted Cloud products, or make alternate plans by Feb 2, 2024. What should you do if you have Jira Server or multiple Jira applications? There’s a lot of great migration information available, but until now, it was all scattered in different locations.
