Prepare a Jira Migration with Admin Toolbox | Part 2: Cleanup

[#1]

Hey there!

Welcome to part 2 of our article series on preparing a Jira migration featuring Admin Toolbox for Jira! Before in the first blog post, we wrote about standardizing your settings in the Community as a strongly recommended step, and now it's time to find what's obsolete and leave it behind so you can enjoy a neat, orderly Jira instance. This article will focus on the next step: The cleanup.

Why is a cleanup important not just for Jira migrations?

This is probably the most neglected part of maintenance in general. The cost of a messy instance is hard to estimate, nor does it prevent you from working. Yet, you'll notice the impact over time:

• You find tens of similarly named issue types.
• Users aren't sure which fields to use because the names are inconsistent - "Due date" or "End date"?
• Searching for issues takes longer.
• Users are confused by the number of apps that flood them with information.
• License costs continue to rise, seemingly for no reason.

Did this happen to you already, or you'd rather avoid it? Try a regular cleanup. It doesn't have to take much time, and it's easy to execute. We have prepared a checklist of what to review and tips on how Admin Toolbox helps you reach the most hidden corners of your instance. Let's begin!

What is a Jira cleanup, anyway?

The goal here is to dispose of what you don't deliberately plan to use in the future (or move to Cloud). In the context of a Jira migration, this corresponds to the Optimize & Shift migration strategy by Atlassian, which emphasizes moving what you need only. That said, even besides migrating, you should review your instance at least once per year, and based on the age of your instance, there might be a lot to remove at first: 

• inactive users
• unused groups and roles
• test projects
• old and trial apps
• countless workflows, issue types, screens, custom fields, and other Jira objects

And even though the effects of not cleaning aren't apparent, they definitely cost money, time, and/or system performance. To start, you need to have a good checklist of what to inspect to help you evaluate which objects are still being used or planned to be used and which ones you can safely remove. We'll bring you a suggestion for the checklist up next.

The Jira maintenance checklist

Such a plan can look like the one below. You can apply it to both Cloud and on-prem, as it includes objects that appear on both deployment types. They can be divided into users, Jira objects, and apps.

Area	Complete?
Inactive users (more than 6-12 months)
External administrators (based on the size of the instance)*
Unused or barely used groups
Old projects (last updated date 1-2+ years ago)
Unused or barely used issue types
Unused or almost unused workflows
Unused or barely used screens
Unused or barely used field configurations
Unused or barely used statuses
Unused or barely used resolutions
Unused or barely used custom fields
background-color: grey;
Apps – expired trials, unused or barely used apps

*External administrators: Even though this is more about governance, we recommend reviewing the administrators, too – these users can change anything. In general, having two administrators is just fine (in case the other is unavailable). Still, there are situations in which you need more than two (perhaps an extra admin dedicated solely to user requests). Every admin should be well qualified, leave a clear audit trail behind him, and not make big decisions without others.

The cleanup may seem repetitive, but luckily, there are apps designed to make it easier and quicker. When developing Admin Toolbox for Jira, we focused on giving you the right data you need to make an informed decision on what to keep or remove before you migrate to Cloud (or if you just enjoy having a reliable, neatly set-up Jira instance).

Towards a smarter cleanup with Admin Toolbox

Deleting obsolete data from Jira without helpful applications is like cleaning house with one hand tied behind your back. While you can definitely do it successfully, it will take more time than necessary. Or you will get so frustrated that you'll skip some of the steps. Here is how our app gives you an extra hand.

Bulk change versions and components

When you display Jira projects as an admin, you see how many issues each project has and the last issue update date. This, by itself, is great for deciding what to archive or remove. Admin Toolbox goes further: it shows how many versions and components are used. The main upside, however, is the Bulk operations button. It was added in version 2.11 to help you standardize and clean up roles, versions, and components.

In the case of versions and components, it serves as a project overview focusing on the common versions and components. From there, you can add or remove a particular version in all of your projects or rename it, so it's more in line with the release terminology you use — this all without browsing each project manually.
What this helps with:

• Obsolete and/or wrong versions and components will be removed from filters and searches.
• Versions and components will become standardized across projects, allowing for better reports.
• You'll ensure that certain versions and components only appear in certain projects.

Bulk change users and roles

During a Jira migration, there's enough trouble with users and groups as is – let's make it easier by reviewing your project roles first. This is especially important if you use Jira Service Management, as the "Service Desk Team" project role is critical to its functioning. Bulk editing of users and roles proves helpful here.

The operation provides you with a list of the selected projects and roles in use, in this case, "Administrators". From here, you can review the members of any role and change them, if needed, in the projects you need. Standardizing or removing role members becomes very simple this way.

Below, we add the "jira-servicedesk-users" group to the "Service Desk Team" role on all Service projects to ensure that they can work as agents. The same way you can remove a certain user, group or role from several projects at a time.

This feature is useful when cleaning up obsolete groups and users from the system because it shows if they are being used at all. It also clears up permissions, as you can review what to expect when you migrate to Cloud.

User switcher

After cleaning up the user, group, and role structure and setting the correct permissions, you should verify that they work correctly. You can quickly check the configuration by logging in as the desired user with Admin Toolbox's User switcher.

Smart view & advanced global search

Last time, we mentioned the smart view to show you IDs of objects like workflows or issue types and makes it easy to see how much they're used. This is useful if you need a simple report on which objects you need to migrate to Cloud and merge or remove instead. If one of them isn't used much, it's a good candidate.

You may want to return to certain objects to check them again before deleting them, or you may need their ID (perhaps in scripts or automations). In this case, the advanced global search function in the administration is very useful: Write the name of the desired object, e.g., the name of a workflow, and you will see its ID, and you can go to it directly in the administration. This way, you can quickly change the field options, for example.

Well prepared for a Jira migration

After standardizing your Jira configuration and cleaning up Jira, you're well on your way to preparing for migration to the cloud. It doesn't matter whether you follow Atlassian's recommended Optimize and Shift method or have chosen a different strategy. Admin Toolbox helps you with the process in multiple ways. Review how it can help you maintain Jira and prepare a migration for 30 days for free at the Atlassian Marketplace.