How to implement a Jira Migration (a step-by-step guide)

Keywords: Jira migration, migrate Jira to new server, jira cloud migration, jira to Jira migration

The following article contains everything you need to know to complete a safe Jira migration. You will also find a step-by-step guide on how to implement the migration.

Your business and organizational structure will inevitably evolve.

This might be due to changing technical environments, the merging and splitting of teams, or even the sale of the entire company via an acquisition.

Whatever the reason, at some point the Jira instance you’re working in will need to be migrated.

In this article, we’ll provide tips on the best approach for a secure Jira migration and a step-by-step guide on how to achieve this.

A side note: this article can get a little technical towards the end. If you’re just using Jira as a user, (but not as an admin) this article will be valuable. However, we want to be as clear as possible on how to migrate Jira to a new server. So the end of the article might be mostly useful for your administrator. If you’re the Jira admin, great! Otherwise, I’d recommend you share this with your admin as well. He/she will thank you for it!

Now, let’s get into the nitty-gritty of the challenge of implementing a clean Jira migration.

Types of Jira Migrations

There are several types of Jira migrations, each of which comes with its pros and cons.

The Big Bang approach of migrating Jira

If you follow a Big Bang approach, it means you’ll be migrating Jira to a new server in one go.

So you’ll be starting from nothing, as it were.

It achieves the migration in a single step and makes it clear to users that all information has been transferred to a new system.

Going forward, all access to the old system is redirected. So there can be no confusion as to where updates should be logged.

Because of these factors, a Big Bang migration can look superficially attractive.

However, it will mean downtime for users, and there are several other major drawbacks that we’ll discuss in more detail in a minute. Keep reading…

A Project-By-Project approach to Migrate Jira

This approach means migrating projects, as required.

This is typically done when a project has been maintained on one Jira instance but then needs to be moved to another.

This might be due to reasons relating to infrastructure, security, or practicality.

When the migration is launched, access to the project is stopped and all data (including configuration information) is sent over to the new instance in one go.

Users can then be informed that the project is available on the new instance.

This approach can be used to gradually migrate a complete configuration to a new environment. And while it is a more measured approach, it nevertheless comes with many of the same problems as a Big Bang migration…

An issue-by-issue approach or a Live Jira Migration

Following this approach, issues are migrated from one instance to another as required.

So issues are simultaneously available on both platforms.

Team members can then work on either platform and gradually switch over from one to the other.

This is arguably the most flexible and most foolproof approach, by some margin.

 

The dangers of migrating Jira

A Big Bang migration sounds simple, but it can come with some major issues.

These include:

1. Losing valuable time when preparing for the migration process

A great deal of preparation is needed to ensure that the new system meets all operational requirements of the users and teams who depend on the system.

You can not underestimate this!

In many cases, people need to dedicate significant amounts of time to confirming that the new system is fully customized to their needs.

And, all too often, they’ll still miss crucial details.

2. Missing crucial details when migrating Jira to a new server

During the transition period, you will have to factor in downtime during which neither Jira instance is operational.

You will likely want to schedule this for a low-traffic period, such as a weekend, with an advance announcement of the planned downtime.

However, if the migration fails, then everything needs to be rescheduled and repeated.

Trust me, that’s not fun!

You will have to follow up with further testing with repairs to the migration process. You’ll then need to do this again and again until you get it right.

This is the kind of big-bang migration that you don’t want.

3. Losing crucial data after Jira has been migrated

When the moment of truth arrives, and staff begin really using the new environment, then no rollback is possible.

At this point, you’ll conclusively find out whether you’ve done enough preparation.

If one team finds a blocking issue, while other teams are happily using the new system, then the administrator hits a wall.

The dissatisfied staff will have to either wait for the functionality to be built or for a workaround to be devised for their issue.

But failing that, they’ll have to make do without it.

As with the real Big Bang, you can’t do a re-run…

Why do we prefer a live migration for Jira

2 words.

Less-friction.

When migrating Jira to a new server, running a Live Migration removes nearly all of the problems and friction that you might face.

With a Big Bang migration, some degree of dissatisfaction is almost inevitable.

Staff want their environment to continue to work as they know it. And introducing significant changes will always have an impact on operations, however big or small.

Given limits to speccing and testing, there is a very good chance that at least some features and functionality will be missing, altered, or broken.

What’s worse, this will often only be revealed once your users pick things up on the other side of a Big Bang migration.

Our view is that bringing about change in an organization is best done by making incremental improvements to the environment without causing disruption.

A Live Migration achieves just this, allowing for projects and issues to be gradually transferred from one system to another. This makes the process simple and painless.

Staff can then choose to work in either system, as they want.

Synchronization of data (using tools like Exalate) ensures that users will find what they need, as they need it, on both platforms.

Small changes can then be applied to the new system to make it just perfect.

All the while your staff can keep using both systems in their day-to-day operations.

If something doesn’t work to their needs, then they can continue to use the original system while the configuration is adapted on the new environment.

Once the new configuration is perfected, the whole team can make the switch. Only when staff is completely satisfied the old configuration can be dismissed.

By building this flexibility into the transition, the migration is ultimately made far easier and far safer.

How to implement a Jira to Jira live migration

At this point, you know about the types of migrations and the dangers they come along with.

Now it’s time to show you exactly how to migrate your Jira safely to a new server (or cloud).

For reasons, we explained above, we will be doing a live migration.

In this case, we’ll be taking an example for migrating Jira to another Jira. We’ll be migrating all agile information within the projects. This includes sprints, epics, all issue data including issue key, change history, issue links, sub-tasks, typical issue custom fields, etc…

To implement the live migration, we’ll be using Exalate.

Exalate is an add-on for Jira that allows you to easily synchronize issue data in real time.

You can trial Exalate for free for 30 days. That should be more than enough time to complete the migration.

Step 1: Install the Exalate migration tool

First, you’ll have to download Exalate.

To do this, head over to the Exalate page on the Atlassian Marketplace.

Once there, click “Try it free”.

Than choose if you would like to install it for Jira Server or Jira Cloud.

After this, go ahead and complete the installation on your Jira instance.

If you need more details on setting up Exalate, you can have a look at the following documentation page for Jira Server or the following documentation page for Jira Cloud.

Step 2: Complete the registration

After successfully having installed the migration tool, you’ll have to register it to use it.

So go to the Add-ons tab in your Jira Administration section.

Once there, navigate to  “Registration” for the EXALATE tab on the left menu.

You will find the following form already filled with your jira-data. If everything is correct, go ahead and click “Register”.

That should do the trick. Easy enough, right?

Step 3: Install the Exalate synchronization tool on the other instance

To implement the migration, you will need to have Exalate installed on both the initiating instance as well as the destination instance.

So repeat steps 1 and 2 for your other instance.

Note that if more than 2 instances will be involved in the migration, just set up Exalate for any of the other instances as well.

Step 4: Connect the Jira instances

Now we’ll configure a connection between the instances using Exalate

Exalate connects instances based on invitations. This means you’ll have to initiate your connection on one side after which you will receive an invitation code on the other side.

Don’t worry, this is easier than it sounds.

https://docs.exalate.com/display/ED/Registration+process

• Setup Exalate and configure a migration scenario as described on the documentation site
• Have some pioneers make the switch and ensure that the configuration stabilizes
• Transfer the whole team by providing required training
• Dismiss the old system

Conclusion

Performing a migration from one system to another is never easy.

Fundamentally, though, the challenges in the transition are not just about technology. It’s about the people using it and the way they work.

That’s why it’s crucial to ensure the new configuration completely meets their needs.

The problem here is that getting user feedback is always difficult. Users will rarely have enough time to explain their requirements in the necessary detail or validate new software to the degree that is required.

Because of this, a Big Bang migration may well be followed by a ‘WTF’ moment. This usually only happens when staff has to put the new instance to use.

And at this point, you might be left without having the option to roll things back.

The gradual transition made possible by a Live Migration, on the other hand, allows for an iterative and controlled evolution of the environment. That’s why we recommended this approach in some way for most use cases.