Migrate a project including custom fields and screens to another server

[Alex Sydney]

What would be the best way to migrate a project (including workflow and Agile panels) from one server to another without manually re-creating custom fields and custom screens?

[Alex Sydney · Accepted solution]

Actually, the question is answered by combining Rahul, who provided Atlassian's tools for project migration and I by providing third party paid plugging for project migration called “Project Configuratgor”.

[George Dinkov _Botron_]

Hi guys,

Although this is an old question, it might be useful to mention that our add-on, Configuration Manager for JIRA,  solves the problem completely - including the migration of Agile boards.

Cheers!

[Rahul Aich [Nagra]]

HI Alex

The simplest way would be to take an xml export from the source JIRA server and restore from backup the entire xml into the target server. Then delete the projects that you do not need. This option is only valid if your target instance is empty. Note that a xml restore will wipe of any existing data form the target instance.

If your target instance has some data which you cannot afford to wpie off, then the only option you have is to use the project import feature.

With project import you need to re-create the configurations manually i.e. custom fields, workflows. Screens are not mandatory to be re-created. Any agile boards you have will also need to be manually recreated on the target instance.

Here's the link to the project import which gives you more information.

https://confluence.atlassian.com/display/JIRA/Restoring+a+Project+from+Backup

https://confluence.atlassian.com/display/JIRA/Restoring+Data

Rahul

[Alex Sydney]

Hi Rahul, Thank you for answering and submitting links. XML restore would be a good solution for a single project to be migrated. In our scenario we are planning to migrate many projects from Test server (where projects get developed) to Production server at different time. What would be a solution for this scenario? Alex

[Rahul Aich [Nagra]]

Alex

Let me explain it again. I think i have confused you.

Project import is always the best option to migrate projects between two jira instances. As in this case, the target instance need not be empty. Project import to target does not wipe off all data from target instance. However, the cons is that there is usually a lot of configurations that you need to replicate before you can do that.

In your case, it seems there is data in your target isntance which is valuble to you, so the only option left for you is project import.

Restore from xml is not an option.

It would had been an option if you were happy to lose all the data in your target instance,

Hope this clears.

Rahul

[Suhan Sencer]

Hi Alex,

Could you please send me a link or documetation if this solution was okay for you?

Do you advise this Project Configurator?

I have same issue, i need to migrate almost 15 projects to another living instance. So this means thousands of customizations needs to be created at target instance.

Kind Regards.

[Alex Sydney]

There is a paid third party plugin called "Project Configurator" which developed for case like this. It allows to migrate heavy customized projects between JIRA instances without manually re-creating customization. Here is some info on this plugin: Project Configurator is a plugin with versions for JIRA 5 and JIRA 6, that can copy a project configuration from a development or test instance to another JIRA instance. - Handles not only the project specific configuration, but also global objects such as schemes, workflows, statuses, resolutions, users, roles, groups, etc. that are used by the project. - The plugin will detect the minimum set of changes required to replicate the new configuration in the target instance. - In case of error, the database will be rolled back to its original state. - Simulated load feature, that allows for previewing the changes that will be applied. - Both processes (export and load) can be launched from a standard JIRA session in a web browser running anywhere.