CustomField Merge after cloud migration

[Deleted user]

HI,

I wanted to share some difficulties with migration and customfields as well as get some tips and/or tricks.

We are currently migrating and have the problem, that some of our features required redesign in Cloud. Not everything works the same on Cloud as it did on Server (3rd Party stuff mostly)

That's why we decided to setup our Cloud page as we needed to and validate our cloud system beforehand. This also let's us reduce downtime while migrating, because we don't have to configure WF's or something similar afterwards.

Not one thing in particular is very time consuming: CustomFields.

When migrating in a similar system, all customfields are newly created with the "migrated" tag. those hold all of our data. Now our setup uses the same customfields, but without the (migrated) tag. because we cannot merge the old and new fields we now have to go ahead and setup everything regarding customfields like Screens, Postfunctions, Filters... to work with the now migrated versions of the fields, then delete the fields we used for the setup, reconfigure everything and then change all customfields with the /migrated) tag so they will look good. As you can see this is just a very high amount of labor and I wanted to ask if someone experienced something similar and how this can be done faster.

Our dataset is big, there a 14k+ Issues, 100+ Customfields for 20+ projekts with 8-10 workflows and 14 Issue Types + postfunctions and automation rules.

And help or  experience reports would be appreciated.

kind regards

[Valerie Knapp]

Hi @[deleted] , thanks for your post. 

For the part about the custom fields with "migrated" appended to the end, I have done a number of migrations for customers and you can contact https://support.atlassian.com/contact/#/ who have a script they can run to remove this for you. 

I think in terms of the pain of analysing an on-premise to go into cloud, you're doing the right thing to rationalise everything. Unfortunately, it is a tedious process that can't really be avoided (in my experience).

Best wishes

[Deleted user]

Hey,

thanks for the reply. It's good to know that this script exists, but, your right, the tedious process remains.

Kind regards

[David Day_ Appcento]

I know its an old thread but just wanted to add my tips since a lot of people seem to have this issue. it's one of the most common post-migration headaches. What you're seeing is expected JCMA behavior: when it encounters a field that already exists in the destination cloud site (even if it is a default Cloud field), it creates a copy with "(migrated)" appended to avoid data loss.

The manual fix is tedious: you have to go through each field, copy the migrated values into the original using Automation rules or bulk edit, update all screens/workflows/field configs to reference the original field, and then delete the migrated copy. With 100+ custom fields (which is common), this easily takes a full week of admin time.

I actually built an app for exactly this problem: Migration Field Cleanup for Jira on the Marketplace. It scans all your fields, detects every "(migrated)" pair automatically, and merges them safely by copying migrated values into originals only when the original is empty. It never overwrites existing Cloud data. 

If you want the link, happy to share. The core approach is: scan first, review safety classifications, then merge in batches with a progress bar.

Atlassian is aware of this (see MIG-1163) and has an early access program for pre-migration duplicate detection, but that is only available to enterprise MOVE customers. For everyone else, post-migration cleanup remains manual work, which is what my app addresses.