How to migrate custom field values with groovy or not?

[#1]

Hi!

Today I would like to share a possible way to migrate or merge a custom field during a periodical cleanup. 

Possible ways are built-in functionality of Scriptrunner or myGroovy, own code and own yet another alternative way for the complicated situation.

Also,you can follow with next typical steps of cleanup process:

1. Detect the fields
2. Create a ticket about merge plan 
3. Detect the JQL, agile boards queries via database queries in tables searchrequest, add info into ticket
4. Prepare the optimized the context in the comment of ticket
5. Notify project stakeholders in the Jira ticket
6. Get approvals 
7. Inform via slack (email) the next merge the end users affected  for  that changes
8. Execute the action.

This is my typical process for the cleanup activity.

As an example, let’s do the next real case with screenshots.

Goal:

Migrate from the Production environment field to Products field. Both fields are pickers. 

Where some of options are the same, if you see the small differences, you can change if both need to be merged.

Then under super user which has access to all related projects, create filters with related tickets.

Then I saved the filter with name test_ . 

After visiting the Scriptrunner built-in scripts to copy custom fields values.

After verify via preview and run.

Hooray we merged. 

After using the new feature (https://jira.atlassian.com/browse/JRASERVER-41269) from 8.11.0, we can adjust the private filters via gui, if it’s needed. And public stuff as well via gui.

[Alexander Pappert]

thanks

[Martin Bayer _MoroSystems_ s_r_o__]

Hi @Gonchik Tsymzhitov , thank you for this Article.
What will you do with "original" field? Will you immediatelly remove the field or will you just remove all the contexts or will you only remove it from all the screens?

Because from my experience it is sometimes impossible to fix everything and it is needed to make end users responsible that theirs objects (boards, filters, issues...) are ok. But when you send notification about change implemented on PRODuction environment, they often need to check data against original data... so I usually remove field in few phases

1. I only remove it from the screens
2. after month I remove contexts
3. after month I remove the field

What is your way?:) 

[Gonchik Tsymzhitov]

Hi @Martin Bayer _MoroSystems_ s_r_o__ , 

I missed that message, sorry for that. 

Well, my way is mostly the same: 

1. Review context and dedicated if it's global
2. remove it from the screens
3. after month I remove contexts
4. after month I remove the field

Sometimes I do project by project, then I can speed up that process :)