I have a Jira instance used for testing that we create Jira projects in to verify with business customers. When the business customers are satisfied with the project in our testing Jira, we move the project into the Production jira instance for our business customers to use on a regular basis. Is there some tool or feature that allows you to export a Jira project from one instance and import it into another Jira instance? Is it possible to automate this process so that we can replicate between two environments (Test <-> Prod)? I came across a tool called "Swizzle" that appeared to do what I want, but it seems to be very loosely supported and old.
Any help you could provide would be greatly appreciated!
You can export your data from Test JIRA to XML (Administration | Export & Import | Backup System) and then you can import just a selected project using Project Import functionality.
You would still need to do some manual mappings in case your new project uses configuration elements (issue types, workflows, etc.) not present in the target instance (Production), but once you set it up, the issues are copied with the entire history.
The other method could be exporting given project (as a result of Search) to Excel, then to CSV file, then back to JIRA using CSV import. But then you will loose the history and the mapping would be usually more cumbersome as CSV does not keep any field metadata.
Is there no kind of "Save/Load" functionality, with which I can save a complete project in a file and load this project from that file later on (without manual mapping or editing)?
This is still way too clunky and brittle for enterprise use; there's far too much room for user error.
Jira really needs to get proper test, qa and production instance management rolled into the core product. Simple things like being able to detect the base url has changed between instances, or a way to do so that isn't part of some fifteen step process.
if you can create the required project, users ,etc manually, then you can use Task Adapter to transfer tasks between two Jira instances.
This is also what we need. The problem is that we are moving one big project from one server to another with many custom schemes/fields/workflows and custom issue types and creating all this manually would take too much time. We are considering a database dump / restore but that would also copy the other projects from our server and we don't want that.
If you use MySQL or Oracle database for your JIRA, you may create SQL patches to apply over production database, that will create the project with workflows and security schemes. It requires however good knowledge of JIRA database and SQL, and attention to the values of primary keys. Alternatively you may pay with Jelly scripting, but it has very limited functionality.
There shouldn't even be a need for base URL. That's a major pain.
This is tricky if you have customfields, worflows etc getting created for each project. Could you please explain why the tests itself happen on the production instance (may be with limited access) and make it with appropriate permissions once the testing is over?
You can also just copy a project within the instance easily with Jamie's script runner so that the customers can start with a clean instance once they want to switch over to production. So start with a project key like TST-<<based on customer>> and then once testing is over, copy project to the actual project key.
Once done you can delete the old project.
https://studio.plugins.atlassian.com/wiki/display/GRV/Built-In+Scripts#Built-InScripts-CopyProject
Project Import Tool is the only thing provided by Altassian. You need to make sure that all custome fields, issue types, issue security levels, resolutions and permissions that you have in the source instance, exist in the target (production as you say). If you use workflows, export them before. If the workflows use screens, you need to patch XML files and change screen ids. I have moved about 40 projects from one very messy instance to another one, so I am pretty sure that it is possible in general case. But it requires sorting out many things, that is sometimes possible only through direct changes in the databases.
What about all the attachments associated with the projects using the XML project export/import tool. Our attachments are on the filesystem and are not being copied over. Thanks
I actually worked on a small project to perform such a mammoth task before. You can attempt to view the steps here: Migrating Certain Projects from JIRA.
Give this a shot, and see whether it fits your requirements.
There is a new plugin in Atlassian Marketplace called "Project Configurator" designed to transfer the configuration of a project from one instance of JIRA to another. It only transfers configuration (custom fields, workflows, schemes, permissions,...) but not issues or attachments. The idea behind the plugin is to cover the use case of a development instance where changes are made, and a production instance where those changes should be applied, once they have been tested.
(Disclaimer: I am involved in the development of this plugin)
Yes - I have the same question about extracting attachments.
Were you able to figure this out? If so, please advise
thanks
This actually works very well; it's a shame it has to be provided by a third party rather than being core functionality.
plug-in https://marketplace.atlassian.com/plugins/com.awnaba.projectconfigurator.projectconfigurator
When using the export to XML/Project Import option, what problems, if any, are likely if the source instance is Jira 5 and the target instance is Jira 6?
I would like to know a respons to this question myself. I am faced with importing a Jira 5.0 project into a different Jira 6.x instance.
Follow the advice at https://confluence.atlassian.com/display/JIRA/Restoring+a+Project+from+Backup. There is a section called "JIRA versions do not match" that explains what to do when versions for source and target instances are not the same.
If you combine that with the use of Project Configurator plugin, you save yourself all problems related to mapping the project configuration from the source to the target instance. (I am a developer of that plugin, so maybe I am a bit biased here ;-)
I strongly agree with rob.kearey.
This add on is not available on cloud..Any suggestions?
If you are moving your project from the Cloud, you can always make a backup and restore it into a Server instance. Then you export from this instance. If you want to merge Cloud instances, copy them to server instances, merge there and upload the result to the Cloud. This process would be good also for moving projects from Server to Cloud.
See process explained in the URL mentioned by @Kenta Yamamoto below and in another comment above this one.
Dead link
Now a new tool called Configration Manager for JIRA (https://marketplace.atlassian.com/plugins/com.botronsoft.jira.configurationmanager) is available. It does pretty good in copying configurations from one JIRA instance to the other.
For data transfer, export as Excel and import as CSV or XML back up and import will be fine.
For attachment transfer, create a file by querying all weblinks and issues key. The you can run a small REST app to pull the attachment from the source instance and post it to the target.
However, it is a real shame that JIRA does not have the options for these out of the box.
Thanks for that link. Unfortunately it only works for JIRA 6.0 and above. But good to know it exists now..
Yeah, I Agree. This kind of functionality is very useful and should be out-of-the-box. But I would rather use for this, Project Configurator (https://marketplace.atlassian.com/plugins/com.awnaba.projectconfigurator.projectconfigurator). It is more popular, supports filters and dashboards and has a far better price. It even has versions for JIRA 5.X! We've being using it for two years, with a fantastic support. It's very reliable!
https://confluence.atlassian.com/display/JIRA/Migrating+JIRA+to+Another+Server backup attachments and index directories (if located outside jira home directory)
hi, the link is not available anymore
what if i don't have a budget to buy it? is there any way to do it by free?
Please see updated KB: https://confluence.atlassian.com/display/JIRAKB/How+to+merge+JIRA+applications+instances
Version 2.0 of Project Configurator for JIRA, released a few days ago, goes one step beyond and now offers an integrated way to export or import a complete project (that is, not only its configuration, but also issues and attachments)
Does it import the Agile Boards in JIRA 6.4.x ?
It's possible to export workflows ... but if your JIRA instance A has a different setup than JIRA instance B, the workflow will be utterly unusable because it'll use wrong statuses.
It's possible to create a workflow on a JIRA A, export it, and import it to JIRA B, if your two JIRA servers use the exact same screens and statuses. (e.g. if you have a Staging JIRA that's a copy of your live server).
For cloud instance, try the procedure on How to merge two different JIRA Cloud applications together.
In a nutshell, merge projects on JIRA Server and put the merged projects back to Cloud.
We can merge Cloud projects, too.
Refer https://confluence.atlassian.com/jirakb/how-to-merge-two-different-jira-cloud-applications-together-779160767.html.
Hi @Kenta Yamamoto,
Yes, your comment is very accurate and actually we have references of customers working with projects from JIRA Cloud with the process you outlined, I will update my previous comment.
Hi Stephen,
the best option would be a synchronisation app from Atlassian marketplace.
I personally use the J2J Issue Sync app which works great for me:
https://marketplace.atlassian.com/apps/1215323/j2j-issue-sync?hosting=server&tab=overview
It can synchronise projects, issues and fields between two or even more Jira instances. You can try it free before buy so you can test if it meets your requirements.
Martin
It is hard for service desk projects and data from some add-on. You would rather create a TEST project in production instance, then in a separate test instance.
It looks like you're new here. Sign in or register to get started.