All Projectrak fields are migrated on the first migration.
Remember, we won't migrate the next field types:
Script fields
Group fields
List fields of external data source
Suggestions
After the first migration, we suggest to:
Not modify any option of Priority, Status and List fields.
Not rename fields.
When migrating project-type and user-type fields, if you do not want to lose their values:
Make sure all the projects and users related to them are being migrated in the same migration or have already been migrated previously.
The following content applies to all fields created manually by users on Data Center:
When you perform several migrations, fields with the same name will not be migrated again. If after the first migration, on Data Center you rename a field, next time you migrate to Cloud this field will be created as a new one.
When you migrate project-type fields, if its value is related to a non existent (not previously migrated) project in Cloud, it will always lose its value.
When you migrate user-type fields, if its value is related to a non existent (not previously migrated) user in Cloud, it will always lose its value.
In the case there is a field with the same name in Data Center as in Cloud, we will migrate its new options. This applies to List, Priority or Status fields. E.g.:
The following content applies to Projectrak predefined fields, which are the ones created by default on the app installation.
Projectrak’s predefined fields are the same in Server/Datacenter and Cloud. These predefined fields cannot be deleted, and our ultimate goal with migration is not to lose any piece of data.
“Updated” predefined field is an exceptional case and will never be migrated. This is due to it being a self-calculating field.
These are a few points we would like to share about Predefined fields and Migration:
Name and description: Server or Datacenter names and descriptions will be the ones carried over to Cloud. If you have a Predefined Status field called “Phase” in Cloud and one in Server called “Status”, after migration the Predefined Status field will be named “Status”.
Field values: (this will only apply to Predefined Priority and Status fields). You can experience different behaviours depending on the case:
Existent values on Server / Datacenter that are non-existent in Cloud: when migrating these values, they are created in Cloud and assigned to the corresponding projects.
E.g: A value called “Blocked” in a Status predefined field non-existent in Cloud, when migrated will be created in the destination instance as a new value and associated with every project as it was in Server.
Existent values on Server / Data Center that also exist in Cloud: as it is the same value, this will be associated with the migrated projects in Cloud as they were in Server / Datacenter. The icon and color scheme will be the ones that have been carried over to from Server.
E.g: A value called “At Risk” in Sever that also exists in Cloud, when migrated will be assigned to the migrated projects in the destination instance and it will keep the same associated value with the projects that were already in Cloud.
Values nonexistent on Server/Datacenter, but existent in Cloud. There can be 2 options:
Values only existent in Cloud but not associated to any Project after migrating will be deleted.
E.g: A “No budget” value of a predefined Status field is only present in the Cloud and no projects are on that Status. After migration that value is deleted.
To keep that value, it can be created in Server/Datacenter before starting the migration, or you can create it after migration in Cloud.
Values are only existent in Cloud that are associated with Projects. After migration, these values will still be associated with those projects (and shown by Projectrak), but they will be disabled from the field configuration, where you will be able to enable them again so you can select when and if needed.
“Formula” fields that depend on an unmigrated Jira custom field will appear as "count issues" formula type.
