Migrating JIRA Cloud Project from one Site to Another

I have lately been trying and failing in trying to move (or copy) JIRA project from one site to another. One could think that this is so common use case that Atlassian would provide easy tooling for this. But based on quick Google search, this is not as straight forward as one would think. And hope.

The first instructions I found were based on making a backup of your site. Don't do that! If you try to import the backup, you will accidentally overwrite your whole JIRA instance. This only works if you want to bring the project(s) to an empty JIRA site.

But what does work, is the cloud-to-cloud migration that was still in beta when I tried it. With this approach I managed to bring individual cloud JIRA projects from other cloud instances to a common JIRA. In the following section I will tell how to do that and what potential pitfalls to expect.

Prerequisites

Cloud-to-cloud migration has some pretty heavy prerequisites, probably biggest of them being that you need to have Org Admin access rights for both the JIRA you are migrating from and for the receiving instance. I think this is pretty overkill. I hope in the future there would be some much lighter way of moving JIRA projects between sites. That would be possible with Trusted or Site Admin accesses.

Then you need to have the same Apps installed in both instances. This is good to keep in mind, especially if you have some costly ones in the original site. If you can, try to keep the set minimal. Keep it simple is a good rule.

Next, make sure you have same or similar enough custom fields in both instances. I failed my migration a couple of times because I had a validator in the original workflow that I didn't spot first that was relying on a custom field information. I had even trashed the custom field, but the reference was still left in the workflow. I would recommend simplifying your workflows before migrating.

 

Or putting the previous prerequisites into a simple list:

• You need Organisational Admin access for both JIRA instances
• You need same Apps installed in the receiving JIRA as in the original
• Same Custom fields are needed in receiving JIRA
• Check the workflows for validators. Keep it simple.
  

 

The Migration

Once you have done all the preparations, the actual migration should be smooth. For detailed instructions, check this link. In the original JIRA site, go to Settings > System > Import and Export > Migrate cloud site. Choose the receiving site (you will only see a list of sites you have Org Admin rights). Choose the projects you want to migrate. The conflict checker is very user friendly and helps you spot and clear conflicts before you try. If there's no conflicts, review and start the migration. Time it takes depends on the size of the project(s).

 

After the Migration

One thing that we noticed after the migration was that all users who were in the original project got site access to the receiving JIRA. They appeared as having site access, but no product access. In the user administration listing it also seems that these users would have received email invites, but according to Atlassian this is not the case. Never the less, I recommend removing their site accesses unless you intentionally want to give them access.

I hope in the future Atlassian provides a simpler tool for migrating individual projects between cloud instances. And with lighter access rights requirements. I think this must be quite common use case when companies evolve and merge.

Chasing Zero Bug Policy with a Three Strike Rule

Deal with Bugs Early

I claim that the best way to treat bugs is to deal with them fast. I call this the Zero Bug Policy. It means that anytime there's a new bug, development team fixes it as soon as they can. This minimizes the need of categorising bugs or spending time with bug backlog.

Unfortunately teams are often not in such a position that the amount of bugs is zero. Many would probably say that there is no such thing as a bug free software. At least software that has been developed for several years by multiple people and solves a complex real-world problem. Technical capability of the development team, culture, ways of working, staff turnover and many other factors contribute to the amount of bugs. Usually the more moving parts your solution and organisation has, the greater the chance that you will have existing bugs.

Then, assuming you are in a state where bugs have been and are piling up: how do you dig your way out of the situation? One way is to simply increase awareness. If having bugs has been the normal, you need to spend some energy to change the status quo.

Automate Your Way Out

I created a JIRA automation that implements so called Three Strike Rule. It runs periodically and has the following rules:

• All bugs that are found that have not changed status in 30 days, are labeled with Strike1. 
• All bugs that have Strike1 label and have not changed status in 30 days since, are labeled with Strike2
• All bugs that have Strike2 label and have not changed status in 30 days since, are closed/some other action taken.

I have also used JIRA project components and the ability to assign bugs to specific component owners, in most cases team leads. This makes the issues more personal and encourages action. Unassigned issues can be more easily ignored.

Automatic closing of bugs should be seen as something that should be avoided as much as possible. If customer has reported a bug and you close it with some automated message, it most probably is not going to increase the customer satisfaction. But on the other hand, neither does leaving the bugs rotting in your backlog.

With this simple Three Strike action I've witnessed a big decreasing trend in the number of aging bugs. When the rule was first implemented, there were several aging issues, but since then the numbers have gotten lot closer to the Zero Bug Policy for almost all teams.