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".
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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
What process did you use to migrate your data? Did you use Jira Cloud Migration Manager? If so, what version of it?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
@Trudy 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!
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.