Migrating "Epic status" is not locked on source (Jira v8.12.3) but locked on destination (v9.2)

Tim C_i4lu7p

Hi,

We've got a Jira server migration challenge which not been able to resolve.

The "Epic Status" field is not showing as a locked field on source server (Jira v8.12.3) and is just included as a standard customfield in the database.

The same "Epic Status" field is locked on destination server (Jira v9.2) and is included in the "managedconfigurationitem" database table (as expected).

The only instructions I've seen to be able to unlock/lock a customfield assumes that it already exists in the "managedconfigurationitem" database table.

Anyone know if/how we can safely add a record into this "managedconfigurationitem" table to make the customfield show as locked field (on the source server) ???  

Hopefully, the 3rd party migration application ("project configuration for jira") will then ignore it (as a system field).

Any feedback or advice would be welcomed - as this issue has become a complete blocker (for the migration).

Thanks in advance.

Nic Brough -Adaptavist-

The content of that table is not too obtuse to work out, unlike most of the rest of a Jira database, and it's ok to insert data into it, but you will still need to check and possibly update the sequence table.

As usual, you will need Jira offline while you run the SQL to insert the data, and I'd recommend re-indexing after you bring it back up.

The standard content is documented directly at https://confluence.atlassian.com/jirakb/unlock-a-locked-jira-software-custom-field-779158866.html 

Before you lock the field though, I would recommend

• Working out why your admins unlocked it and what changes they made to the configuration of it that the lock was preventing them doing
• Undo it.  The locks are there for a reason - to stop you misconfiguring the fields.  You are going to have problems migrating your data anywhere if you've got misconfigured fields
• Check that your Epic-name field really is of the right type - is it definitely a  com.pyxis.greenhopper.jira:gh-epic-status field in the customfield table?
• Check what numbers there are in managedconfigurationitem table.  When you insert a row into it, you are going to need to use e that fits the pattern of usage (basically, the number has to be 10000 or above, and unique). The ID number in this type of table always goes up, and is stored in a sequence table, so if you're adding to the end of the table, you need to increase the sequence counter.  However, because they always go up, and are not actually used as a sequence, they often have gaps which you can fill. 

If, for example, you have a table with 10009, 10010, 10019, 10020, 10021, then instead of having to faff around with the sequence table to add your row with an id of 10022, just use an id in the gap - anything between 10011 and 10019 in my example.