Uploaded image for project: 'Migration Platform'
  1. Migration Platform
  2. MIG-266

All standard and custom fields are migrated every time a migration is run

XMLWordPrintable

    • 14
    • Major

      Issue Summary

      All fields (custom or standard) will always be migrated (if supported) or come up in the pre-migration report (if unsupported), even though it is not referenced by a selected project.

      Steps to Reproduce

      Example 1: Supported standard field

      1. Change a standard field from Global to being used by 0 projects
      2. Ensure that the field is used in 0 screens
      3. Migrate a project
      4. Observe that this standard field is still migrated even though it was not referenced in the project data

      Example 2: Supported custom field

      1. Ensure there is a supported custom field type configured in the Jira Server instance
      2. Migrate a project which does not have this custom field referenced in the data
      3. Observe that the custom field is still migrated even though it was not referenced in the project data

      Example 3: Unsupported custom field

      1. Ensure there is an unsupported custom field type configured in the Jira Server instance
      2. Migrate a project which does not have this custom field referenced in the data
      3. Observe that the unsupported custom fields is reported in the 'Pre-migration report' as it is considered part of the data set (Note: the report is still in development)

      Expected Results

      For selected projects:

      • Only migrate referenced standard fields. 
      • Only migrate referenced custom fields.
        • Only report on referenced unsupported custom fields

      Actual Results

      All custom and standard fields are migrated every time a migration is run. This means that fields not required by the selected projects are migrated, resulting in longer migration runs, high risk of project migration failure and a higher burden on Cloud performance.
      
      If the field is supported - it can create noise in the destination instance by migrating fields that are not used by any project. 
      If the field is unsupported - it can create noise in the pre and post migration ‘Requires Attention' report by reporting to the customer that the field config won’t be migrated and that they should either fix/clean-up the issue unnecessarily. 

      Workaround

      Delete the custom fields that are not required post-migration.

            Unassigned Unassigned
            jwong@atlassian.com Jason Wong
            Votes:
            9 Vote for this issue
            Watchers:
            18 Start watching this issue

              Created:
              Updated:
              Resolved: