Suggestions on a difficult migration strategy

[Bryan Karsh]

Hi wise ones,

We have recently acquired a small company, which uses Jira -- they use the on-demand version, with Service desk and multiple other plugins.

We have a federated hosted Jira -- with an instance for internal users, an instance for external users, and also Confluence. Authentication is handled by crowd.

Our version of Jira is 5.2.6 -- we have a lot of plugins too, and much customization in the way of script runner scripts, velocity templates, etc.

We need to migrate the small company from their on-demand instance into our instanc(s) -- depending on whether the queues they have are internal or external.

I haven't figured out my final migration strategy, but given that we want to provide as much of their original functionality as possible, I envision my migration looking like this:

1. Upgrade our jira instances to more modern version based on compatibility matrix.

2. purchase/install needed plugins.

3. Do all the grunt work necessary for importing projects (custom fields, screens, workflows, etc).

4. Import new users into Crowd ( not sure best approach here).

5. Import projects from data dump

6. manually move attachments to where they should go.

This task frankly scares the bejezus out of us, since their instance is as complex as ours, and differs so much re: plugins, etc. I have seen some commercial plugins mentioned for assisting with this type of migration. Any tips? Any warnings?

Thanks for the advice -- I appreciate it. This community has saved my hide many many times.

[EddieW]

1) awesome, glad you're looking to move forward

2) thats good, the onboarded teams will appreciate not losing the great tools they have!

3) The nice thing about on demand is that all their customization is in the data, not the install.

The data export you can get should actually include things like workflows, customfields, etc as needed., They will get different IDs likely, but that shouldn't be an issue for anything they were able to do overthere. (so step 3 should not be needed !)

I am not sure about ServiceDesk, and how of the config exports/imports.

4) There are methods for one time imports. But if JIRA has write access to crowd, and one of the underlying directories for the application it will do this as part of #5 too I believe. If not you can get exports from on demand https://confluence.atlassian.com/display/JIRA/How+to+Export+Users+to+CSV+from+JIRA(may need support) and import to crowd https://confluence.atlassian.com/display/CROWD/Importing+Users+from+CSV+Files

5) The XML export should include just about everything except attachments.

6) yep, Maybe even do this before step 5. Would be wise to check for conflicts (if old project keys overlapped).

In general, don't be scared, the tools are well architected and migrations should be reasonable. I'm also sure given the purchasing/upgrades you will be doing that Atlassian support may provide advice via their support site.

But I would strongly suggest just trying in non-prod first ( a few times if needed). A DB dump and rsync of 2 directories and you can have JIRA running on another server. Attempt the Migration and see how much comes over (make sure to grab the files, or else avatars and such will be missing). I think you'll find the task may not be so daunting ( i really hope so at least ! )