VZ Jira per-project migration of a very important project at my company is blocked at this time due to a known issue in Jira and Jira Agile:
https://jira.atlassian.com/browse/JRA-28748
https://jira.atlassian.com/browse/GHS-10577

I have contacted Atlassian Enterprise Support team with a priority 1 - highest level - request for a solution.

The information contained in JRA-28748 and GHS-10577 is not confidence building for me at this time.

I have undertaking a rapid and broad search for a workaround. At this time I have located unspecific mention of manual editing of the Jira database as a possible solution or partial solution. See 42picky added a comment - 14/Mar/14 8:38 AM above

I do not at this time know what steps are needed to perform the direct DB manipulation or how viable this is as a solution in general or specifically for my system and data. There is a risk of making a mistake in the database with an manual work performed there.

I am deeply disappointed in this lack of support for Jira per-project migration with Jira Agile plugin and the lack of support to solve this problem for almost 2 year from the time of first notice as referenced in JRA-28748, as well as, the response of the Atlassian Product Management team to seek and expedite a solution. So much so that I am sharing with you a link to the Executive Management of Atlassian as I feel it might in fact be best to seek to contact the executives directly to address this issue with Jira and Jira Agile per-project migration.

This has important consequences for managing large or complex instances of multi-jira environments as detailed in Special Note below.

Atlassian Executives and Board
https://www.atlassian.com/company/about/people

Special Note
The above blocking issue does not appear when doing a whole Jira site migration however a site migration will over-write ALL pre-existing Jira data in the receiving Jira site. This is a possible path to use but it will require a Service Window where JIRA will be down or at least locked so that backups can be run.

Then, ALL Jira parameters must be reconfigured for my Jira site. These include parameters such as all Users and Groups, email server settings, application linking settings between Jira and Confluence, and quite a few others.

As such, this path is not trivial and is at best only a worst case solution for my current Jira site which has only a few projects in it as this time. When my Jira site is a larger data set then the proceeding whole site migration will not be a viable solution. This has important implication for running a multi-Jira environment which is common for large groups.

Example multi-site Jira instances:

• Test / Develop Jira - not uptime sensitive. For testing upgrades, new plugins, and building new complex Jira
• Projects before deploying to the “Production” Jira.
• Production Jira - main system, stable releases, max uptime, work-critical for multiple teams.
• External Jira - for working with external vendors. Complete segregation from internal networks.
  Special Projects Jira - Teams with special needs that don’t fit in the Production Jira.

Ha! Give up!
We got licenses for JIRA back in January, put a ton of work moving everything onto it , only to find after the trial that our agile work couldn't be transferred onto our new system we had just paid for. WASTE OF MONEY!
We now use YouTrack. It's actually better. And it has a free plan. http://www.jetbrains.com/youtrack/
Save yourselves now, or sit in limbo forevermore.

Atlassian this appears to be very import bug, Please continue working to fix it

comment deleted.

42picky: We would be deeply appreciative of instructions on how to do this! Can you send us email at sysadmin@di2e.net? THANKS!

Perhaps you just haven't noticed the new information above:

— snip —
If you are looking for JIRA Agile specific data, we are tracking this separately here: https://jira.atlassian.com/browse/GHS-10577
— snap —

It's classified as "minor"!

All of you which think that this is a blocker for productaive usage of Jira Agile should vote for it and write their comments there, too.

see? even users are more willing to fix this than atlassian!

While this may or may not work very well, and this depends on your database setup, it might be possible to simply copy the AO database tables as a workaround? Far from ideal, but better than nothing at all?

just got an email. "At this time we do not have the capacity to investigate this request"
In other words, don't expect anyone to even attempt to do anything about it for the forseeable future.

FAIL

If anyone else was screwed over by this, try here: http://www.jetbrains.com/youtrack/

Hi Derek, thank you for the hint - half the price, looks quite equal to Jira so that users don't have to shift round - if it works and the Jira import is fine this seems to be a graet alternative. I think we'll give it a try and evaluate YouTrack - after rolling back our Agile purchase buying YouTrack shouldn't blast budget.

Well I hope that when they do fix it, they also make an Import from YouTrack feature now, because after we came across this monstrous screw up on Atlassians part, we had no choice and ended up ditching it in favour of YouTrack (which works!).

An expected resolution date/version would be appreciated here. We have just purchased a license to merge multiple starter instances into one production instance, and cannot without losing data.

This is a Show-Stopper! Under this cirumstance Agile is not usable in productive environments with multiple projects per server and/or multiple servers where sometimes you have to move single projects from one Jira instance to an other. And I think that we're not running a very large Jira environment.
As long as backup and restore works the actual way Agile is only usable in very small environments or if you install one Jira instance per project.
We have to roll-back our investments we've done in Agile a few weeks ago - perhaps we buy a license when this blocker is resolved.
This example shows how deep you have to test Atlassian software before buying it - this is really a No-Go. Backup and restore MUST work under any circumstances, if it doesn't the product is useless.

This is poor excuses and planning on Atlassian's part. This is something they should have implemented while making this plugin to begin with. Who the hell doesn't look at all possibilities when creating an application to be used to customers. This doesn't give them an thumbs up at all.

Also its dumb when I have to put 1 hour response time for my JIRA system being down because of this and it takes you 3-5 hours to respond.

This seriously (triple underline seriously) needs to be looked into. My Agile environment went down not to long ago due to a corruption in the update for Agile. Something to import/export data should have been thought of before putting a plug-in like this into market for customers to work with. This NEEDS to be put in place now. My co-worker and I who are the System Admins of our JIRA environment can't afford to lose data in Agile again.

I would like to refer to this:

https://confluence.atlassian.com/display/AGILE/Backing+Up+and+Restoring+Data:
Please take note that currently the Project Import does not include JIRA Agile data. Currently the developers are still looking into this matter and you can keep track of the progress via the JRA-28748 - Project Imports should include relevant Active Objects data.

i'm just disgusted with their lack of concern over this, thats all. we took the hit and pressed on, losing that data. we only had 30 days of free trial data to move over to our live paid for system. it is very disheartening to pay for something after using a really good product demo, only for it to break on step 1.

@Derek seriously? This is like thinking that Atlassian would make a good IDE... Although I really want this issue addressed, let's be real!

This issue can be resolved by binning JIRA, using JetBrains YouTrack instead, and cursing Atlassian for their disregard towards this issue. Quote:

"this is a significant issue....we do not have the capacity to investigate"

In other words, "don't expect us to even look at this issue any time soon."

One big issue create on 28/Jun/12 6:01 PM and until now not solved...
This is unacceptable...
I am very disappointed with Atlassian.

I have just created a feature issue: JRA-38018. In my opinion, this would be a perfect solution for all users, using a version of Jira, not yet supporting the Agile backup and import.

Yes it is definitely a huge issue for many customer which is why its so frustrating that they aren't even going to work on it for at least another year.

Please resolve this issue Asap !

We are a large paying costumer (+500 Full atlassian stack licences) and we can't migrate our projects. This is really a blocking issue for us.

Not an improvement - a bug, unless Atlassian can point to the documentation that says this specifically doesn't work.

We are also merging multiple environments. We have an internal one and an on-demand one. Users are not ready to move to the single consolidated internal environment as they will lose the sprint data. We are having to pay for duplicate licenses for users who use both the internal and the on-demand ones.

I also agree with the above comments and about the steps outlined in https://confluence.atlassian.com/display/JIRA/Restoring+a+Project+from+Backup. We are consolidating JIRA instances into one large instance and our users are very unhappy about having to recreate their custom filters, dashboards and sprints. This is above and beyond what we have to do to get the project ready in the new instance prior to the data import itself.
Agile is part of JIRA now and it's a critical piece of daily work and planning. One can't just expect for the sprints to just not get imported with the rest of the data!!!

I don't understand why this is listed as a "Feature Request" the feature is already there its called "Project Import" the feature does not work properly so this should be a bug fix. Especially since Atlassian sells JIRA and Agile packaged together and does not give warning that this will "limit" functionality!

This is also a BIG problem for us. Using latest JIRA v6.2#6252 and JIRA Agile 6.3.12.

Is there a workaround for this problem?
WHEN will it be fixed ?

Hi Sorin,
I'm interested on the workaround too. Could you help me too?

Thank you.

Hi Sorin,
I'm interested in the workaround using PostGreSQL. Would you be able to help me out?

Thanks.

Is there a workaround this problem? What if i don't want to import the sprint number for old issues?

If you are interested about merging two JIRA instances with GH/Agile, please contact me. I already successfully performed this operation two times. I can help only if both instances are running PostgreSQL. Also I can help migrating from another database to Postgres (it can be done using export / import). The operation requires lots of changes to both instances but the good part is that it can be done with almost no downtime, only requirement is to make the source instance read-only once you start final steps. Based on the amount of data you have to merge and especially the hardware it could take from few minutes to a couple of hours for 100k issues. The first merge required almost two months of work from which most of the part was spent understanding the database structure and testing merges and identifying things that were not right. One important hint: after the merge you need to perform a restart and a full-index in foreground, background one will not fix everything.
/sbarnea.com

Just to chime in here 6.2 has the same issue

Just think of what will happen when you have a problem with only 1 project and you have to import that project from backup. You cant, not without loosing the plugin data. So this forces you to use a whole instance restore instead, causing a loss of any recent data changes on all other projects as well. Huge hassle especially for a multiple project instance! This has been an issue with us two times already. In both instances all 70 of our employees had to redo an entire days worth of changes, just so we could restore 1 of our 30 projects.

This is also a problem in 6.1.7.

It's a blocker for me. Trying to integrate a new team into company and BAM.... it cannot be done.

We have this problem in version 6.0.3. A show stopper really. Is there an ETA on a fix? will need to file a support issue.

Agree absolutely with the latest comment. Indeed, this issue is a blocker. But in my opinion it has been a blocker from the beginning, because it is disastrous to offer a product without an appropriate solution regarding the data migration.

We like to use Jira, because it is nice and very flexible to use. But, on the other hand, often disappointing.

Dear JIRA Product Management,

did you even notice that this issue is the one and only blocker with more than 100 votes? And that there are only five other issues that come close to it w.r.t priority? So why could this be a question of "not having the capacity"?

(used search: "project = JRA and priority in (Blocker,Critical) and votes>100 and statusCategory!=Complete")

got it eventually. delete all agile data (poor show)
delete all custom resolutions (again poor show)
Someone look into this ticket!

i disabled it and it didnt work, so i uninstalled it and it didnt work. so i deleted all custom fields too and it didnt work. so i reinstalled agile and it didnt work. and now the custom fields are locked so it isnt working. this is an absolute joke, a complete waste of time and money. how long has this issue been untouched? id say it was a pretty major flaw. not impressed.

Yesterday I try Disable Agile, Uninstall Agile and then Install Agile, then the Project Import work. The Story Point/ Sprint field doesn't block the import. But the Agile data is lost.

@Derek M, you would see which field block the import, e.g. "Severity", then you go to "Administration" > "Issues" > "Custom Fields" > Configure (the gear on the right of a custom field, e.g. "Severity", ).....

I found this workaround, but I cant find the option! Where is it?
All I see under Administration is: projects, add ons, user management, issues,system, and audit log

Workaround
Edit the configuration of the custom field 'Atlassian' so that there is no restriction for Issue Type (All Issue Type selected)

Administration -> Fields -> Configure (the gear on the right of a custom field) -> Edit Configuration for Applicable contexts for scheme -> Issue Types -> "All issue type" option.

well i feel like i have wasted money.
i try, i like, i buy. i cant move the data across. this truly sucks.
how can i import all my issues, ignoring the Agile stuff then? looks like i'll just have to bin my scrum board. I cant even remember customising any fields!
and how old is this issue? is it not like, important enough? that we cant do ANYTHING?

Almost a 2 year thread, 50+ comments and 129 votes sure does seem like it should get some attention.

understand my problem we have a standalone JIRA and Ondemand JIRA. Stand alone JIRA already has a lot of data in it and On demand also contains some data(Unfortunately there are two teams using separate On demand's) so i need take all the data from two On demand sites and import into Existing Standalone( Contains Data here too) JIRA. So i really don't know what to do......

Unfortunately, you have no choice (like me) .. unless, of course you accept to loose some data related to Agile (Sprints, etc).
Trust me - it's better to go as I said (save a lot of time and nerves). I know it has to be backed up and restored a huge amount of data but currently there is no other way.

Ohhhh... The existing instance already has a lot of data in it. So i cant do that

No workaround. The only way - full backup, restore on other instance. Then delete all that's not required leaving only desired project.

How close is a resolution for this? I need to import a project (that includes Agile) into another instance. What is the current workaround to get the Sprint data and User stories into the import target?

We finely decide to upgrade to Jira v6.1.5. But I do not feel very well, thinking on the frustation that will follow, after the next update. We surely will have to spend a lot of work again, in order to restore (fr)agile.

This is an essential feature also for us. We are trying to migrate some projects from one JIRA instance to another and are not willing to lose all the sprint history and the backlog ordering.

This issue has the priority Blocker, but what is it blocking: The release 6.2

screenshot attached

Dear Support,

I face the same issue - cannot import a single project in JIRA 6.1.5 because of 'Sprint' field which is ridiculous.
I followed all the instructions with preparation of target instance before import (spent a lot of time) to finally know that this is impossible ... very frustrating. Project import simply doesn't work! Please update the guide as it's misleading - https://confluence.atlassian.com/display/JIRA/Restoring+a+Project+from+Backup
When do you plan to fix this?

One question: Are you going to implement it in Jira v6.2, as far as I know planned to be released in February?

I there any update on this yet....from anybody? Our company just invested pretty heavily in a 100 user license and we have three sites that use greenhopper/agile so we need to merge the sprints and everything onto one site (from three). When will this problem be resolved? It was first reported a year and a half ago, this is somewhat intolerable for an enterprise environment.

Hi.
One question: Is there a possibility to upgrade Jira by installing it unto an existing directory? Maybe in this way we can save all existing data.

Thanks and best regards,
José

are there any updates on this?

Is there any update on this as far as resolution or workarounds? We recently migrated jira via project import and have lost our Agile and Capture data.

How close is a resolution for this? I need to import a project (that includes Agile) into another instance. What is the current workaround to get the Sprint data and User stories into the import target?

Where is the Ranking, Start/EndRelease dates for versions exist? Is there specifics can be shared so we can perform this operation on our own? I already have a script to migrate Sprint information but require the information recently posted by David.

Am I understanding that with Agile 6.3 the sprints will be migrated? What version of JIRA? 6.0.8?

we will look at this, I sent you a linkedin invite

GH 6.3 – I upgraded both instances before and btw, that's something you want to do before because finally they fixed the mess with the sprint assignment.

You're doing it for GH 6.3? or 6.2?

If you think you can help me finishing the scripts, send me and email with your bitbucket accounts.

All right.. Thanks for the reply, can't wait to see it

I am still working at this, but it should be usable during next week, the problem is more complex that it may seem and my script will work only with latest Jira 5 (not 6) and latest Agile, and postgresql. Obviously, the latest changes in GH slowed me down.

I had to drop using SQL Server on one on the instances and switch to Postgres in order to have the same database.

HI Sorin Sbârnea, could you give us any information on the script you talked about.
We would be really interested into this.

We just ran into this issue when trying to import a new project from another JIRA instance on the same version. How long till a fix?

I think that also the external issue links are just... lost. internal ones are still here.

What is planned release time frame for this issue fix?

Hi Sorin,

I am also very interested in your solution if you plan to make it available. Thank you.

Hi Sorin,

That sounds great. Do you plan to make this script accessible? I would be very interested in a solution for this problem...

I wrote a script that can merge GH data from another instance, assuming that you already imported the projects using project import.

I got this working for sprints using a combination of python, GH REST, and Groovy. There are more details at https://answers.atlassian.com/questions/151204/how-to-create-a-sprint-using-the-greenhopper-rest-api/151803
but I wouldn't call it elegant!

And sprint ids would need to be merged

Quick summary: an XML backup files contain entities.xml (issue data) and activeobjects.xml (plugin data). A full import will import both sets of data. A project import only seems to pull in relevant data from entities.xml so all the data for plugins like GH and Zephyr is not present. Most of the plugin data could be imported to an identically-configured JIRA instance via SQL unchanged except for possibly:

different project ids
different board ids

but that's an ugly solution.

While testing jira 5.1, we realised: It seams, the Activity Stream is not fully imported along with the XML-Backup (missing in some projects), as it does in our Jira 4 (test system). This could be related to the same problem, don't you think so?

In the context of a missing functionality regarding the CSV-Import, the following advise was giving to me: "This would be possible by using JIRA Importers Plugin v4.2 or above. However, the plugin only compatible with JIRA 5.x and above". So what about the JIRA Importers Plugin? There could be also a problem, I can imagine.

Hi Jose, I think it is not related. We are facing a problem that happens after this check. Both license version already matches, the project migration runs, and no error is raised. But when you check the imported data, some fields were not imported.

I wonder, if the topic discussed here is somehow related to: Does my GreenHopper license have to match my JIRA license?

You will only be affected by this if you use single project imports:
https://confluence.atlassian.com/display/JIRA/Restoring+a+Project+from+Backup

This is a completely different process from a full site restore.

Is this also an issue when exporting from Jira OnDemand and restoring all data into a self-hosting jira instance? If so, this will really scupper our plans as it will affect dozens of projects. Additionally - will this mean that historical GH reports based on sprints are no longer available?

We have similar problem with Sprint custom field. We want to merge 2 instances of jira with greenhopper but import ignores sprints.

Boris, we already have Jira with 47 projects. GreenHopper server was a test server to confirm that everything is fine. I will need to merge the 2 servers and I don't want to import 47 projects into the new server. I will import 4 projects with GreenHopper in the main server.

ocourteau If you are importing into a new server, why not do a full restore instead of a project restore?

In case of Greenhopper plugin, there are 17 different tables (all of them starting with AO_60DB71_*) and in my case, one of them has more the 2000 lines. I would like to known how the tables are linked each-other (I mean: Which primary-key on table X is foreign-key on table Y). I use MySQL, and this kind of "link" is not easilly gathered from database, as far as I known.

What we did regarding Zephyr Plugin data:

• Open the JIRA Administration and look at the Plugin Data Storage to get the names of the relevant tables
• Check the tables via SQL
• Export all relevant data
• Import the data on another JIRA instance

PLEASE NOTE:
In order to make this work, we had to perform a JIRA export from the first test instance followed by a PROJECT import of that data on the second test instance.
Like this, we were able to import all tickets and attachments.
The SQL import added all the relevant plugin data to the issues.
BUT there will probably be some differences with the IDs, so you might want to write a mapper and test it on a few issues first.

To make Green Hopper accepted by my company, we had to set up a demo JIRA server where we start using green hopper for sprint planning and bug monitoring. Now that the experiment is over and that we convinced all the manager to switch to green hopper and install it on our production JIRA server, it is quite sad that we cannot bring back our past sprint data.

We're using JIRA 5.1 in combination with the Zephyr plugin and we're facing the same problem.
After making a JIRA data backup on the first system and making a project import of the backup.zip on a second system, only the data from the file entities.xml was taken. The other file of the backup.zip (activeobjects.xml) was ignored.
Therefore, no Zephyr Test Details, Test Executions and Test Cycles were imported.

Did anyone find an alternative solution, yet?

Did anyone manage to transfer Greenhopper data somehow?

Does anybody known where I can found a database schema for Greenhopper database? I would like to try this "SQL magic" mentioned by Alexander, but I need to understand how the tables are connected each other... I'm considering that all the info we need is being stored inside SQL tables, of course.

Thanks

Is there maybe a way to copy the fields using some SQL magic.

Team,

Do we have any workaround to preserve such data during the project import?

Thanks!

In addition to the fields noted above, the Sprint custom field is not carried over from during a project import. I believe that this may be the GreenHopper plugin's failure to implement the correct interface, as described here: https://confluence.atlassian.com/pages/viewpage.action?pageId=223220264. However, it is related to the import of GreenHopper data.