Why is still "soaking" after JIRA 7.1.7 has been released today?

This is great news . Good work Atlassian!

Removes a big heartache in migrating JIRA's, should save probably ~30 minutes next time! (and that's excluding the time it took to find the workaround)

Hi ohernandez@atlassian.com

Good news, thanks a lot

Regards,
Dieter

Hi dieter,

Both fixes should make it into JIRA Server 7.1.7

Regards,

Oswaldo Hernández.
JIRA Bugmaster.
[Atlassian].

It would be really nice to get this fixed together with https://jira.atlassian.com/browse/JRA-41681 in 7.1.6 and thus eliminate all our JIRA 7 blocker regarding project import

I have some ideas how to fix it in https://support.atlassian.com/servicedesk/customer/portal/22/JSP-218894
and i also can share my final solution if wanted ...

I can confirm the workaround works on a 165 project, 64,000 issue JIRA with ~15 custom fields which required the SQL Script to be applied to.

This is by no means a solution, but you can still merge your instances with this workaround and have no data loss from the field values.

Hello Kevin,

By no mean I'm one of Atlassian affiliates, but I'm managed to move all my 17 projects when we merge our Jira instances.
This is quite a major bug, but not a blocker.
There is a workaround which works and it will move all the data from these custom field which are either Checkboxes, Select List (single choice) or Select List (multiple choices).
The values will be moved completely.
One of our project contained 30 type of custom fields from these types and I had to create SQL batch file to run the command in one go.

Jira 7 has brought a very important improvement, which for us was a real blocker; the ability to import all the Agile boards related data, i.e. sprints and ranks.
Projects which use agile data are now can be moved JRA-28748 (although you need to recreate the actual boards in you target Jira)
You will also have to use Project configuration add-on, to move the configuration first, but I presume you already know it.
If you need some help, you are welcome to email me shai.dahan@galacoral.com

This bug is a huge expensive problem for us - We have just bought a 2000 seat Jira + Confluence license, and we cannot move our Jira instance (90+projects) to our destination instance (used by 2 other teams) because of the Atlassian bug.

So occurrence low, impact BLOCKER.

7.1 has been and gone. I'd really like Atlassian to hire some devs to fix it ASAP, because right now we cannot merge our instances.

Thanks Shai,

I managed to implement the fix and got the Project Import working in the end.

The instructions are a lifesaver if you're merging 2 large JIRA sites together as chances are you will encounter this problem due to bad assumptions in the software.

Jack

This is the content of the suggested workaround in the article.
Unfortunately Atlassian restricted this page for unknown reason (luckily I've a copy of it)
I have attached the original page here.

These are the instructions, which work for me in quite a lot of projects migration.
Note that step two is not necessary and it has no meaning in the actual process.
I would suggest that you make a copy of your database and make the changes on the copy rather on the original.

================================================================================================================

Always back up your database before performing any modification to the database. If possible, try your modifications on a test server.

Perform some database changes to the Source instance and then re-generate/export the backup and perform the import on the source instance. From the Source JIRA instance database :

(info) Create a XML backup for the source instance, before modifying the database, just in case anything goes wrong.

1. Run this SQL and save the results as a .csv file. You will need the values from the ID column for STEP 5.
select * from customfieldoption where customfield in (select id from customfield where cfname='Severity');

(info) Replace Severity with the name of your affected custom field.

2. Run this SQL to return the Default Configuration Scheme for Severity under configname and save it as a .csv file for reference.
select * from fieldconfigscheme where id in (select CUSTOMFIELDCONFIG from customfieldoption where customfield in (select id from customfield where cfname='Severity'));

3. You will need the id from this SQL for the next SQL in Step 4.
select id from customfield where cfname='Severity';

(info) Replace Severity with the name of your affected custom field.

4. Replace XXXXX from the SQL below with the id from the above SQL results in step 3.
select * from fieldconfigscheme where FIELDID='customfield_XXXXX';

5. Update the Source Instance's database:
update customfieldoption set CUSTOMFIELDCONFIG=WWWWW where id in (XXXXX,XXXXX,XXXXX,XXXXX,XXXXX);

(info) Replace WWWWW from the ID in Step 4 and Replace XXXXX with the ID from the ID Column of the SQL results from Step 1.

Generate new XML project backup from source instance

Restore the project into the target instance
================================================================================================================

Good luck

Custom field values are not imported using Project Importers Tool - JIRA Knowledge Base - Atlassian Documentation.html