Split instances in more details (Part 1)

[#1]

Introduction

Imagine that you have single instance of Jira or Confluence and because of some reason it need must be divided into two separate. There could be many reasons behind that.. Company split into two organizations, single team would like to start own instance, some users would like to customize more than it is possible in one huge instance or simply some projects would work better / faster on a separate instance..

No matter what is the reason the procedure that we need to follow is similar. Let's try to go together through this process so that it would no longer be a problem

Goal

In our case there was a need to split because some of the key users wanted to go to Jira and Confluence Data Center as soon as possible and do not wait for decisions until Server would reach EOL (End of Life). In addition it was important to do in a way that it would be fully transparent to business users on both sides - current users that would continue to use should not even notice that there is a split and users that would move to new instance simply start to work on specific day using a new URL and everything is working as expected.

Source environments before split where like following

Jira Environment A (Source)
Users: 2000
Projects: ~600
License: Server

Confluence Environment A (Source)
Users: 2000
Spaces: ~400
License: Server

And Apache that works like a reverse proxy.

Target would be half of that..

Jira Environment B (Target)
Users: ~1000
Projects: ~350
License: DC

Confluence Environment B (Target)
Users: ~1000
Spaces: ~300
License: DC

Around 1000 users would have to move to a new environment. On this moment we do not know how much data would be moved and more important how to do it .. It was just a guess based on few quick checks.

Step 1: Research

Yes, we should start by asking ourselves a question - Is this task even possible?

Normally we check what the official documentation says.. Good thing is that after few second we find relevant article called "Splitting Jira Applications" - https://confluence.atlassian.com/adminjiraserver/splitting-jira-applications-938847622.html

This mean that (at least for Jira) it is possible. What about Confluence? Unfortunately looks like there is no official procedure for Confluence (or it is not so easy searchable like for Jira), but if we look at Jira procedure we think that it should look similar.

Sounds like an easy task, huh? 10 step, backup, export then import, cleanup and we should be done. Well, not quite..
Before we even start thinking about doing the split we should have to do a huge effort of figuring out what to move..

Step 2: Analysis

There is no easy way to know that this project / space belongs to this team and it simply would not be possible to get this information with a single click from UI..

Is this even possible to determine? Yes it is but requires deep investigation. We usually start with checking what is on the instance. Here we list all projects / spaces that are there. We could use UI, API.. but the best way (and fastest) is to do it from the database. Then when having a list in front of us finally we can move forward. But wait! Who should be responsible for making sure that we know what to move? Admins?

Of course many people would say that we can go to business users and simply ask couple of questions or give huge list share with everyone and wait until someone mark his own .. Right, there is huge chance that at the end we would get pretty accurate results but definitively it would take a lot of more time and we get the results we still are not 100% sure what would happen if someone would incorrectly mark some projects or spaces.

So in such a situation always better is to have alternative point of view and compare. Admins could potentially get information from their perspective and at the end merge the results to validate if everything is accurate. In this situation we used a (Python) script that over Rest API gathered as much information as possible.. Who have access to the project, who is / was the assignee (or reporter), how many tickets, attachments .. More you get = better. Thanks to that we identified many interesting things like projects that were used by both sides (so it mean that after a split projects must exist on both instances)

But it is not only projects / spaces that we need to check.. If using add-ons we have to make sure which one must continue to exist on target instance. There was a situation that a plugin was used by people that would move to a new instance. And in our case we not only split instance from Server to Server, but also made a "migration" to DC..

Step 3: Licenses

Now when we know how many users, projects/spaces.. data we would move that it was required to think about getting DC licenses, so that new instances that would be created could continue to operate.

Yes, migration to a different license type.. Documentation was not saying anything about this. It was only mentioned that "This process requires two separate server licenses". OK, so definitively we have to have a new DC license and also all plugins.. We had an additional problem since users used Insight and it was no longer possible to install it as a plugin (it is a part of Jira Service Management now!).. So we had to buy not only Jira Software DC but also Jira Service Management DC just to continue use this functionality.

There were also other things that we did not know yet how are handled and how would behave but it was enough to estimate the cost of the licenses and make a decision that we proceed with separation.

Step 4: Planning

According to documentation we should create a backup of database, attachments, then create a new instance and move data by using a XML backup functionality.. This procedure looks totally fine for, but from our experience XML backups on large instance were not always the perfect solutions. In addition we have to wait and we do not have guarantee that after import / export everything would be working fine.

Since our servers are virtual and we would not make move between different networks, we decided to use virtual machine cloning capabilities. Main idea was to minimize the downtime for users, so we had to choose a solution that would quickly have a new working instance without the need to move data. Database was installed on the same server so we actually grab everything including attachments. Users were also using the same Active Directory.. What potentially could go wrong?

Well.. Interested how we finally handled this migration? Jump in to Part 2 for more details. If you are already done with split and looking for guidance about post-migration cleanup that we did after then Part 3 of the story might be worth checking.