Thoughts on Atlassian’s Server Decommission

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.

I'm Currently in a Relationship with JIRA

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.

The Ultimate Guide to Jira Migrations: How to migrate from Jira Server to Data Center or Cloud

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 Appfire to create The Ultimate Guide to Jira Migrations: How to migrate from Jira Server to Data Center or Cloud. This free 210 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.

Announcing The Ultimate Guide to Jira Migrations

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.

The Ultimate Guide to Jira Migrations: How to migrate from Jira Server to Data Center or Cloud

That’s why I teamed up with Atlassian Solution Partner Appfire to create The Ultimate Guide to Jira Migrations: How to migrate from Jira Server to Data Center or Cloud.

This 210 page book is the master resource to answer all your migration questions and provide a comprehensive plan to follow.

This book includes:

  • best practices for planning a migration or merge,
  • practical tips for preparation, execution, and testing,
  • a 73 step checklist so you don’t miss anything before, during, or after
  • 16 customizable worksheets for planning, analysis, and project management,
  • a quiz for determining the best deployment method for your situation,
  • and expert advice.

Download your FREE comprehensive Jira migration, merge, and consolidation guide from the Appfire website.

How to manage and edit shared Jira scheme settings

Question

We are using a shared screen scheme across multiple projects.  How do we make changes to one project without impacting others?


Answer

It’s great that multiple projects share schemes! Sharing schemes is the goal. Whether it’s screens, issue types, workflows, or other settings, Jira maintenance is easiest when schemes are shared. But sometimes, there’s a business need for one project’s settings to differ from the rest. In this situation, the answer is to create new schemes and associate them with a specific project. Now you can customize that project without impacting other projects.

About Schemes

Admin > Issues > Screens administration page

First, let’s discuss schemes in general. A scheme is a configuration or collection of settings. There are schemes for issue types, workflows, screens, fields, priorities, issue security, notifications, and permissions. In this post, we’ll tackle the most confusing Jira configuration area. We’ll explore the screens, screen schemes, and issue type screen schemes pages in the administration area.

Screen Settings

Note: Schemes apply to Jira Server, Jira Data Center, and “Classic” projects in Jira Cloud. “Next-gen” projects in Jira Cloud are schemeless.

Screens

Two Jira Screens with Different Fields

Screens define which fields are present and their display order. In the example, one screen has the “Story Points” standard field and the other screen has the “Steps to Reproduce” custom field.

Screen schemes

One Screen for All Actions


Screen schemes associate screens with the three issue actions: create, edit, and view. In the example, there’s one screen for all actions but a screen scheme can have 1, 2, or 3 total screens.

It’s a best practice to limit the number of fields on the create screen and only show fields the reporter can complete. Since an issue’s reporter doesn’t usually schedule work, omit fields like “Fix Version” and “Due Date” on the create screen. Show these fields on the edit and view screens instead. Screen schemes make it possible to show different fields for different actions.

Issue type screen schemes

Simple Example: One Screen Scheme for all Issue Types and one Screen for all Actions

This scheme associates screen schemes with different issue types. In the example, there’s one screen scheme shared by the Story and Bug issue types. A project can have one screen scheme per issue type or fewer schemes. Fewer schemes are always easier to maintain.

Alternatively, you can have different screens for each issue type. For example, the Bug screen scheme may contain a screen with fields like “Steps to Reproduce” and “Expected Result”.

Regardless of the number of screen schemes and screens, a project can only have one issue type screen scheme.

Common Example

Here’s a more complex but common example.

In the example:

  • The issue type screen scheme contains two screen schemes.
  • The first screen scheme at the top is for the Story issue type.
    • It has one screen for all issue actions and contains three fields.
  • The second screen scheme at the bottom is for the Bug issue type.
    • It has two screens.
    • The first screen at the top is for the create action and contains three fields.
    • The second screen at the bottom is for the edit and view actions and contains four fields.

How to Decouple a Project

Here’s the simple scheme relationship example again. There’s one screen scheme for all issue types and one screen for all actions. This means all issues have the same fields.

Let’s imagine, all projects share these settings but we want to add a custom field to only one project. Here are the steps to create the needed schemes and decuple a Jira project.

  1. Create a new screen or copy an existing one
    • Add the custom field to the new screen
  2. Create a new screen scheme or copy an existing one
    • Associate the new screen with the new screen scheme
  3. Create a new issue type screen scheme or copy an existing one
    • Associate the new screen scheme with the issue type screen scheme

At this point, we’ve created new schemes, but they are unused and don’t impact any Jira projects or issues. The last step is to associate a project with the new issue type screen scheme. This change does impact Jira data.

  1. Go to the Jira project to modify and click the “Project Settings” link in the left sidebar
  2. Click the “Screens” link in the left sidebar
  3. At the top right, click the “Actions” button and select “Use a different scheme”
  4. Choose the new issue type screen scheme and click the form submission button

Finally, check your work by verifying the new field displays when creating or editing issues in the updated Jira project.

Huh?

Still confused? Don’t worry! This was the hardest part of Jira administration for me to understand. It will make more sense after you’ve practiced these types of changes in the application. Use your Jira test environment to experiment with these settings until they make more sense. Once you understand all the screen settings, the other scheme relationships (ex: workflows) will make more sense too.

Need advice for screens and fields? Check out the Better Form Design in Jira series.

Have a Question?

Use the “Ask a Question” form on the top right and we’ll answer it in a future post.

View other questions

New Course: Learning Jira (Server Edition)

How do you track your work? As organizations continue to adopt digital technology, more and more teams are leveraging Jira! By learning Jira you’ll be able to easily manage your own daily tasks and help your organization plan their strategic initiatives.

I’ve used Jira since 2011 and it’s the best application I’ve found to manage my work.  Join my LinkedIn Learning course to understand Jira fundamentals and how you can leverage this software to tame your never-ending “to do” list.

Access to my courses and others is included with your Premium subscription!


Rachel Wright’s Jira and Confluence
Admin and User Courses on LinkedIn

Use Jira Cloud instead?

New Jira Basic Administration Course

For every Jira application there’s an administrator that needs to correctly configure settings, manage users, complete customization requests, and ensure the instance supports growth and change in their organization.

But how do you learn to do that?

Take my new course! Jira: Basic Administration is perfect for new Jira admins or anyone who could use a refresher on the top skills every administrator needs.

This course includes the top 5 things every Jira admin needs to know like: adding users, creating projects, editing workflows, and troubleshooting common permission and notification problems.

You’ll learn:

  • how to use Jira,
  • which application type you have,
  • the responsibilities of an administrator,
  • how to access the most used admin areas, and
  • how to set up a test environment so you can experiment without impacting production data.

Take my Jira admin course on LinkedIn. Access is included with your Premium subscription!


Rachel Wright’s Jira and Confluence
Admin and User Courses on LinkedIn

Join the virtual “Best Practices for Managing and Maintaining Your Jira Application” presentation

World events are making in-person presentations impossible! Instead, we’ve shifted to virtual events and are excited to deliver “Best Practices for Managing and Maintaining Your Jira Application” to users all over the world.

Join Rachel Wright at these remote events:

Book Rachel Wright for your next remote event

Manage your out of control Jira application!

Hear Rachel’s Jira best practices remotely!

You know if you don’t maintain your Jira application that it can quickly grow out of control. But where do you start? How do you make small improvements without impacting daily business? What should you do if your application is already a bit of a mess?

In this presentation, we’ll address:

  • how to set standards so you don’t have more schemes to maintain than necessary,
  • how to clean up schemes and custom fields when you have too many,
  • how to archive old projects and unneeded issues,
  • and how to track changes and customization requests so you have a record and an audit trail.

Atlassian Community Events are where users meet, learn, network, and share best practices. User groups meet locally and all over the world.  Group members are newbies and veterans who like to “talk shop” about Atlassian software, Agile development, DevOps, software, and related business topics. Attend these events to network with your peers, share solutions, meet Atlassian Solution Partners, get special content from Atlassian, and maybe enjoy a beer or two.

Join us, join an Atlassian Community Event in your city, or start a community group!

Rachel Wright’s Jira Courses on LinkedIn

Rachel Wright at LinkedIn’s recording studio

I’m excited to announce my Jira courses are now part of LinkedIn’s technology course library! I’m officially a LinkedIn Learning instructor! In March 2020 LinkedIn flew me to their California offices to film my Jira: Basic Administration course.

LinkedIn’s online video courses help you learn software, creative, and business skills. Classes are taught by credible industry experts with a focus on high-quality content and production value. Over 50 new courses are added each week, so there’s always something new to learn.

And the best part: Their entire course library is included with your LinkedIn Premium subscription!

I loved teaching Jira administration in their professional video and audio recording studios. I felt like a movie star!

On the Road with Jira

I’ve been on the road since 2015 and I take every opportunity to combine my love of Jira and travel. On this LinkedIn recording trip, I completed another item from my Jira bucket list! I visited the Channel Islands in Ventura, California. The five individual islands are only accessible only by boat. I visited Santa Cruz and Anacapa and can’t wait to go back!

Hello from the Channel Islands


Rachel Wright’s Jira and Confluence
Admin and User Courses on LinkedIn

Jira User Best Practices

As organizations continue to adopt digital technology, more and more teams are leveraging Jira to track their work. Here are some do’s and don’ts for Jira users.

Do

Here are some best practices and good habits:

Create Jira issues

Create a Jira issue any time you need to track a task. Jira can handle many millions of issues, so don’t worry about filing too many. Also, you can’t really break anything in Jira, so don’t be afraid to use it! The only thing your administrator can’t undo is deletion of data.

Break up large tasks into smaller ones

If you’re working on something big, create multiple issues to break it up into small, manageable chunks. For example, if the task is to make a cake, break that up into different sub-tasks for ingredient shopping, for mixing and baking the ingredients, and for icing the cake after it’s cooled. Ask your Jira Administrator about issue hierarchy in your application.

Breaking up work is also the way to assign multiple people to similar tasks.

Transition issues as you work

Transition issues forward in the workflow as you work on them in real-time. It’s your responsibility to make sure an issue’s current status mirrors reality.

Keep issue details accurate

Keep all issue details and fields up to date. It’s important to complete as many fields as possible and update them as soon as information changes. It’s OK if additional details become available after an issue is created. Add it to Jira right away so everyone has the best information.

Accurate information helps others find issues and generate reports. When an issue is complete, its information should serve as a legal and historical record of what was done.

Take action on issues assigned to you

If an issue is assigned to you, it means you need to take action! Look at the status to see what to do and look in the comments field for any notes left for you.

Fix incorrect assignments

If an issue is assigned to the wrong person simply change the assignee. Unassigned or incorrectly assigned issues create unnecessary delays.

Record action details

When you’ve completed an issue, add a comment explaining what you did, where or how you did it, and anything else others should know right now or in the future.

In the example, a typo on the company website was reported.

I fixed the typo and then added a comment showing I corrected the spelling of the word “customer”, that the change occurred in the first paragraph on the page, and the page I changed was named “terms.html”. 

Now anyone who needs to verify my change knows exactly what to look for and where.  This is just good record keeping.

Log time

When you’ve completed an issue, log how much time it took to complete.  Get into this good habit, even if your organization doesn’t require it.

Logging work is NOT about how good or fast you are!  It’s about planning, prioritization, allocation of resources, and improving estimation for future similar tasks.

For example, if my estimate is 1 hour and I’ve logged 3 hours so far, this could signal there are other factors making this task take longer than expected. Maybe the code is super complex, maybe I could some help clearing road blocks, or maybe I simply mis-estimated.  In the real world, these things happen all the time!  Jira just gives you a way to show it.

A final thought on time logging:

Do you submit a time card or a report of what you’re working on?  Jira can handle both those things for you.  No need for extra manual work!  Ask your Jira Administrator about progress reporting and time logging in your Jira application.

Don’t

Now let’s cover a few things not to do:

Delete issues

If you don’t need an issue, it’s smarter to simply close it rather than delete it.  Use the “Resolution” field to indicate no work is needed because it’s invalid, can’t be reproduced, is a duplicate, or won’t be fixed.

Report an issue and walk away

If you create an issue, you should follow it through to completion, be ready to verify the resolution, and be available to answer questions.  If you create an issue and walk away, it might not be addressed any time soon.

Enter sensitive information

Don’t enter sensitive information into Jira or other applications.  This is sometimes referred to as PII (personally identifiable information) or SPI (sensitive personal information).

Sensitive information includes passwords, personal data (social security numbers and mother’s maiden names), health information (like which health insurance plan an employee has) employment information (like citizen status or salary), and any proprietary or confidential personal or company information.

Contact your Jira Administrator, Security, Legal, and Compliance teams for any company-specific policies.

Also read: 9 Tips for Getting Action in Jira

How does Jira issue ranking work?

Question

How does Jira ordering work? What happens when users prioritize issues differently or on different boards? How do I know if ordering is functioning correctly?


Answer

Jira provides a way to order and prioritize issues. On a board, simply drag an issue above or below another issue to determine ranking.

Ranking is a global concept. Issues are ranked against other issues regardless of their Jira project, issue type, or associated board. Ranking is not related to other standard fields like “Original Estimate”, “Story Points” or “Priority” but you can use these concepts together to influence your prioritization process.

An issue only has one rank even if it’s included in multiple boards. The display order is based on an issue’s relation to other issues on the board.

If you change an issue’s ranking on one board, the ranking changes automatically on other boards. Project Managers, Team Leads, and Product Owners need to work together to determine overall strategic priorities.

More about Ranking

Before a sophisticated ranking system was available in Jira, we all created a static, custom number field to track order. This was tedious to maintain. When priority changed, we had to manually renumber the values in the custom field. This was especially problematic for long issue lists.

Luckily, today, there’s a better method. Today’s system is called LexoRank and it uses numbers and letters for maximum ordering flexibility. An issue’s order is stored, as a string, in single field called “Rank”. Jira Administrators can see the field on the “Custom Fields” page, but it is “locked” and not editable. Admins might also see remnants of old ranking fields marked “obsolete” too.

Order by Rank with JQL

In addition to viewing issue rank on boards, you can also order issues by rank with JQL. This is useful for filters and dashboards. To see issues in one project, ranked from highest to lowest, use a query like: project = project-name ORDER BY Rank ASC

Troubleshooting

Jira periodically rebalances or “recalculates” issue order. The application checks for and handles rebalancing automatically, as a background service. It detects problems like missing minimum or maximum values, strings that are too long, or duplicate ranks in the database. Jira administrators can see the rebalancing status and check for integrity problems from the following page: Admin > System > LexoRank management.

Jira Server LexoRank management page

Here’s a screenshot of the LexoRank management page in Jira Server. (The page looks similar in Jira Cloud.)

The middle of the page shows information about the ranking field and its status. In the example, there are 188 ranked issues and the rank status is “OK”.

You can manually trigger a rebalance by clicking the “Balance all fields” button or the “Balance field” link. To check ranking integrity, click the “Run integrity checks” button (not pictured) at the bottom of the screen. You can perform these actions without impacting Jira’s availability.

Resources

Use these additional resources to learn more about ranking.

Have a Question?

Use the “Ask a Question” form on the top right and we’ll answer it in a future post.

View other questions

Jira Server vs Jira Cloud Interface Comparison

Are you migrating from Jira Server to Jira Cloud (or vice versa)? The user interfaces are similar, but there are some differences to prepare for.

In early 2020 Atlassian started incrementally delivering a new navigation experience for Jira Cloud. The return of the horizontal navigation makes the application look similar to Server, but there are still UI differences to be aware of.

Continue reading “Jira Server vs Jira Cloud Interface Comparison”
0
    Your Cart
    Your cart is empty. Go add some materials!Return to Shop