Idea for Phased Migration between Jira Instance (could use feedback!)

[Bryan Karsh]

Hi,

I've posted before on the subject, but I had an idea recently I wanted to share with the community -- would love an extra pair of eyes to look at this.

We are going to be upgrading our 4.11 instance to 5.2x version. This upgrade includes confluence and Crowd, plus a major rethink in how issues are distributed between some queues. For simplicity's sake, I am just going to lay out the Jira-related steps here.

Due to various hardware and software customizations, plus external customer constraints, a simple in-place upgrade is not possible. We need to achieve the following:

1. minimize downtime

2. maximize testing/validation of new environment (since we are changing so much, we need a big window to migrate/update/test)

3. develop means to migrate a delta data set

3. preserve all data if possible

To that end, my high-level approach is to migrate in phases:

Phase 1: (main migration / UAT of new environment)

-- create migration project (to be used for delta migration steps later on). This project is to contain all custom fields, components, etc., since any issue from any existing project can be moved here..

-- lock down all admin rights on environment, to prevent any changes to customfields, projects, etc. Save timestamp for use in future migration phase step. Only changes occuring in live system are issue-related.

-- take full xml dump of existing environment.

-- build separate Jira 5.2x version of Jira

-- import xml from existing environment into new Jira

-- manually copy attachments into new Jira

Phase 2: (delta migration preparation)

-- build out temporary version of 4.11 environment (copy of live environment, but only containing migration project. Attachments not needed)

Phase 3: (aka -- delta "final" migration -- this is somewhat convoluted.. but should be doable within a few hours max)

-- make old environment read-only, allow users access to live Jira 5.2x environment. (This will allow users to 1. create new issues in new enviroment during migration activity, and 2. refer to old tickets in old system during migration activity -- this is not ideal, but it will prevent us from being down during a several hour maintenance window.)

-- run JQL query in old environment to see which issues have been created or updated since timestamp in Phase 1.

-- delete these issues from the live jira 5.2x instance.

-- move these issues (in old environment) into the migration project (also in old environment)

-- take xml dump of old environment

-- import migration project from old environment (which should have the delta issues in them at this point) into the temporary 4.1.1 instance. Make sure to manually copy over any attachments.

-- upgrade temporary 4.1.1 instance to 5.2x

-- take new xml dump of temporary environment

-- import migration project from temporary environment (which should now be 5.2x version) into the "real" 5.2x environment. Don't forget to manually copy over attachments.

-- move issues in the migration project (now in live 5.2x environment) to correct queues.

-- end maintenance, lock users out of old environment.

That's what I have so far. It seems to me this should work. The only downsides I see are:

-- the issues migrated during the delta phase will have out-of-sync issue keys, since some issues will exist in both the old and new instance, and by deleting and readding them to the new instance, the issue keys won't be in the same order as the created timestamps. I view this as a relatively minor issue.

-- filters/subscriptions made during the freeze won't be copied over, unless I do some sort of db update

... anything else I am overlooking? This approach seems to do what I want, without the headache of scripting something to capture the delta information.

Much thanks for any tips or feedback!

[Renjith Pillai · Accepted solution]

It appears to be me quite complicated. How much is your JIRA instance size, that decides this.

I would do this way:

Phase 1:

1. Take backup of the live instance
2. Install a new 5.2.x in a different machine/port/database
3. Disable email in 5.2.x - https://confluence.atlassian.com/display/JIRA/Restoring+Data#RestoringData-disableemail
4. Restore data there (the maximum time I have seen for restoring data with 1.2 million issues is around 4-5 hours)
5. Bring in all your required customizations/plugins/attachements
6. Reindex once
7. Announce the new server for UAT
8. Leave the system for two days for UAT while the production is in use.

Phase 2:

1. Announce to the organization that JIRA will be ready only for 4 hours in the night
2. Make JIRA read only, (do alternative 3 of this link, that is the easiest - https://confluence.atlassian.com/display/JIRA043/Preventing+users+from+accessing+JIRA+during+backups)
3. Do steps 1 - 6 of the phase 1 (you would have already mastered it)
4. Announce the new server (if you have an apache proxy, do the forwarding to the new server)
5. Leave the old production shutdown for some days before taking it offline