nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Custom fields renamed to custom field(migrated)

David Vincent_odk5fz

Hi community,

When we migrate our Jira Server instance to our new Cloud instance, we have fields that are renamed with (migrated), this is also the case for default field configuration where we have two DFCs...

How to avoid this behaviour?
FYI : The fields concerned are "Start date", "Severity" and "Team".

Accepted answers

Kasturee

Hi David. This happened to us when using JCMA to do our test migration from server to cloud sandbox. The Migrated on date also gets added to the description of all the custom and system fields. Not sure if you have noticed this with your migration.

We will be doing a cleanup ourselves to remove the word migrated from the names. Atlassian is helping us remove the migrated on details from the description of the fields but cannot get it right on the Create screen where the details are still appearing.

Perhaps log a ticket with Atlassian to help with the cleanup of this.

All comments

Trudy Claspill

What process did you use to migrate your data? Did you use Jira Cloud Migration Manager? If so, what version of it?

Kasturee

Perhaps log a ticket with Atlassian to help with the cleanup of this.

David Vincent_odk5fz

Thanks @Kasturee

David Vincent_odk5fz

Hi @Trudy P Claspill , yes we use JCMA and we are in 1.7.1

Trudy Claspill

I heard from a co-worker that handled a JCMA migration recently that they saw the same. They worked with Atlassian support (through their MOVE ticket) to get "some" of it cleaned up.

satish_kumar_0ijf2l

Hi Have also migrated the data by using the JCMA plugin, post migration Atlassian support engineer has run the script to do this cleanup activity

Mohammed Siyad_wszfp3

@Trudy P Claspill - I tried migrating my project from DC to Cloud, got the same error of having migrated suffix after the field. https://jira.atlassian.com/browse/MIG-1163 saw this ticket raised. Is there a better approach for this in the migration?

We are planing to migrate our ticketing system project from Data Center to Jira Service Management and our JSM has all the configs and custom fields in place. So one quick doubt will there be a duplication again when we try to migrate.

Appreciate any better response!

Trudy Claspill

Hello @Mohammed Siyad

Do you have a MOVE/support ticket opened with Atlassian support? If you don't, you should open one so that you can get help directly from them as needed.

The only options that I am aware of for addressing this are:

1. Modify the field name in the on-premise instance to something that doesn't already exist in Cloud prior to the migration and continue use with an environment that has two fields for the same data, or

2. After the migration, move all the data in the "(migrated)" field to the pre-existing field, add the pre-existing field to the screens (if needed), update any filters that reference the migrated field, and then delete the migrated field.

Mohammed Siyad_wszfp3

That sounds like a plan. Can you possibly share the link to the MOVE platform.

Is there a possibility where we migrate only the data and the configs stays there

Guy West_nbe4vx

Hey there, I originally had this same issue when performing a test migration from Jira server to Jira cloud (which is being used operationally, i.e has fields with the same name as server instance).

The first test migration produced several "(migrated)" fields in the cloud instance. After realising this I did a piece of analysis listing all of the duplicate fields between the two instances. With the aim of providing a recommendation on each field to either: Delete the field from the on-prem instance, merge the field (which happens when the two fields are the exact same), or rename the field. All of this would be done in an effort to have no fields with this "(migrated)" suffix

However, the latest test migration we performed, without actioning any of the analysis, no longer produces this issue. There are now no fields with the "(Migrated)" suffix in our cloud instance. The duplicate fields are all just listed with the exact same name.

I'd love to know if anyone else has noticed this?

David Day_ Appcento

If you're seeing "(migrated)" appended to your custom fields after a DC-to-Cloud migration, that's JCMA's default behavior. It creates duplicates of every field with that suffix rather than renaming in place. The problem compounds because those duplicates show up everywhere, field configurations, schemes, automation rules, even archived projects.

I went through this and found the most efficient path is: (1) scan to identify all duplicates, (2) classify which ones are safe to merge vs. have conflicting data, (3) bulk-merge the safe ones, then (4) remove the "(migrated)" suffix from remaining fields. Doing this manually takes days for even moderate-sized instances. There's now an app Migration Field Cleanup (https://marketplace.atlassian.com/apps/353982928) that automates steps 1–3 and gives you a clear report before any changes are made.

Worth noting: if your instance has automation rules or scripts referencing those fields, renaming without checking first can break things silently.

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

cloud

jira-software

jira-software-cloud