Entity behavior while resolving configuration duplication

Boards

• During the first migration, boards are not automatically matched against existing destination boards.

  • Every board coming from the source is created as a new board in the destination, because two boards with the same name can be backed by different filters and can show different work.

• In future migrations, we do not support the merging of boards. Instead, you can select:

  • REUSE to keep the existing destination board and its configuration unchanged.

  • OVERRIDE to replace the destination board's configuration with the source board's columns, swimlanes, quick filters, card colors, estimation settings, and board administrators.

Custom field

• Fields are matched by name (including the “migrated” suffix) and type.

• If a field is reused, we merge its global contexts (context applicable to all projects), including issue types, options, and user filters used on both sites.

• If a field was migrated before as part of a phased migration, you can choose OVERRIDE or REUSE. This may change the field’s name.

Custom field context (CustomFieldConfigScheme)

• If a field is reused, global contexts from the source and destination are merged.

• Project-specific contexts are created anew in the destination.

• If a custom field context has already been migrated as part of a phased migration, it will be merged.

• During migration, you can’t change a context from global to project-specific (or vice versa).

Field layout

• To be a match, all the visible fields in the source and destination field layouts should have the same required/optional status.

  • Extra fields on the destination should be marked as optional.

  • All hidden fields in the source will be ignored. If these fields are visible on the destination, they should be marked as optional.

• If more than one destination field layout matches, reuse any of them or select the default option to create a new layout.

• If a field layout was migrated before as part of a phased migration, select:

  • OVERRIDE to overwrite the field layout in the destination with the source.

  • REUSE to reuse the field layout in the destination.

Field layout scheme

• To be a match:

  • The default field layout from the source should match the default field layout in the destination.

  • Issue type to field layout mappings in the source and destination should match.

• If there is no issue types mapped to field layout in either the source or the destination, the default field layout will be used.

• If more than one destination scheme matches, you can reuse any of them, or select the default option to create a new scheme.

• If a scheme was migrated before as part of a phased migration, select:

  • OVERRIDE to overwrite the scheme in the destination with the source.

  • REUSE to reuse the scheme in the destination.

  • MERGE_SOURCE or MERGE_DESTINATION to merge and keep the source or destination values for attributes that cannot be merged.

Filters

• During the first migration, filters are not automatically matched against existing destination filters.

  • Every filter from the source is created as a new filter in the destination because two filters with the same name can return different results.

• In future migrations, we do not support the merging of filters. Instead, you can select:

  • REUSE to keep the existing destination filter and its configuration, such as JQL, owner, and sharing settings, unchanged.

  • OVERRIDE to replace the destination filter’s configuration with the source filter’s JQL, owner, and sharing settings.

Issue type (Work type in Cloud)

• Issue types are matched by name (including the “migrated” suffix) and by their hierarchy levels.

  • If there is a clear match, we automatically reuse that issue type.

  • If there are multiple possible matches, you’ll need to select one.

• If an issue type was already migrated as part of a phased migration and the name has been modified at the destination, you can choose to reuse the option from the destination or override it with the source.

  • If the hierarchy levels don't match, the destination issue type will be reused to avoid breaking existing parent links. You cannot override the selected option in this case.

• If the hierarchy levels differ, we reuse the destination issue type so that the existing parent links in the destination stay intact. The incoming parent links will be invalid and will be migrated as issue links with the link type Former parent.

Issue type scheme (Work type scheme in Cloud)

• If the destination scheme includes all the issue types from the source scheme (including additional issue types, if any) it will be considered as a match.

• If multiple destination schemes match, you can choose to reuse any one of them.

  • You can also select the default option to create a new issue type scheme.

• If an issue type scheme has already been migrated as part of a phased migration, we will merge it into the existing destination scheme. In this case, we keep the destination scheme’s name and default issue type.

• You will not be able to choose an action for issue type schemes. Issue type schemes will be merged by default.

Issue type screen scheme (Work type screen scheme in Cloud)

• To be a match:

  • The default screen scheme from the source should match the default screen scheme from the destination.

  • Issue type to screen scheme mapping in the source should match the destination.

• If there is no issue type mapped to screen scheme in the source or destination, the default screen scheme will be considered.

• If more than one issue type screen scheme in the destination matches, you can reuse any of them or select the default option to create a new scheme.

• If a scheme was migrated before, select:

  • OVERRIDE to overwrite the issue type screen scheme in the destination with the source.

  • REUSE to reuse the issue type screen scheme in the destination.

  • MERGE_SOURCE or MERGE_DESTINATION to merge and keep the source or destination values for attributes that cannot be merged.

Notification scheme

• During the first migration, for the configuration to be reused, the destination scheme must include all the events from the source.

  • We look for an existing destination scheme with a matching name, and then compare the notification events.

• In future migrations, you can select:

  • REUSE to keep the destination scheme as is.

    • In this case, source notification rules are not applied. The destination may not contain every source rule, and the REUSE option will keep the destination rules intact regardless.

  • MERGE_SOURCE or MERGE_DESTINATION to keep the union of the source and destination notification rules.

    • When MERGE_SOURCE option is selected, if the source scheme name + description already exists on the destination, the name and description are not updated.

  • OVERRIDE to replace the destination rules with the source rules.

    • Rules that exist only on the destination will be removed.

• The entity migration is blocked if the source name clashes with another scheme on the destination.

Options, default values, user filters

• Options that match will be reused as much as possible.

• For options that are already migrated as part of a phased migration, you can either reuse the destination option or override it from the source.

• The default value and version orders can also be reused or you can override it with your choice by uploading the first CSV file in the Update rules for configuration entities card as part of pre-migration checks.

• User filters will be merged.

• If you choose the DEFAULT option, the choice you made for custom field will be considered.

Permission scheme

• During the first migration, to be a match, the destination scheme must contain all the grants from the source.

  • It can include additional grants and still be considered a match.

  • We look for an existing destination scheme with a matching name and then compare the permission grants.

• In future migrations, you can select:

  • REUSE to retain the destination scheme.

  • MERGE_SOURCE or MERGE_DESTINATION to combine the source and destination grants.

    • Existing destination grants are preserved. When MERGE_SOURCE option is selected, the source name and description overwrite the destination's.

    • If the source name already exists as a global permission scheme on the destination, the name and description are not updated during merge.

  • OVERRIDE to replace the destination scheme with the source scheme.

    • Grants that exist only on the destination will be removed — except, in server-to-cloud migrations, destination grants held by the add-on access role and the AI agent role, which are always retained.

• The entity migration is blocked if the source name clashes with another scheme on the destination.

Priority

• During the first migration, priorities are matched by name (case-insensitive, but the migrated suffix is recognized).

  • The description and priority icon are not considered.

  • When name and color both match, we treat it as an exact match and automatically reuse the destination priority.

  • If only the name matches but the color differs, we will still reuse the entity. If multiple matches exist, we offer the customer choices.

• In future migrations, merging of priorities is not supported. Instead, you can select:

  • REUSE to retain the destination’s priority name, description, and status color.

  • OVERRIDE to overwrite the destination priority's name, description, and status color with source values.

    • Override is blocked if a different priority on the destination already uses the incoming name.

Priority scheme

• During the first migration, priority schemes are matched by name, and then each priority in the source scheme is checked to see whether it already exists in the destination scheme.

  • The destination scheme can contain additional priorities beyond those in the source, which will be retained.

  • We do not compare the default priority.

• In future migrations, we automatically merge the already-migrated priority scheme.

  • Merging will add any incoming priorities missing from the existing destination scheme, and the existing priorities in the destination scheme will be preserved.

  • Make sure to validate the resulting set of priorities before proceeding.

  • If the source name clashes with any existing destination scheme, the name will not be updated during merge.

Project role

• During the first migration, we find a matching role by name and merge the default actors based on your selection.

• In future migrations, the default actors are automatically merged. No action required.

Screen

• To be a match, a destination screen should contain all the fields from the source screen. The destination can still include additional fields.

• If more than one destination screen matches, you can reuse any of them, or choose a default to create a new screen.

• If a screen was migrated before as part of a phased migration, we will merge it into the existing destination screen and keep its name.

  • Additional fields from the source will be added to existing tabs in the destination.

  • If needed, new tabs are created in the destination with the required fields.

  • If you rename tabs before migration, they will be created as new tabs in the destination.

  • If a field already exists in another tab in the destination, we will not add it again from the source.

• Screens are always merged, so there’s no separate policy setting for screens.

Screen scheme

• To be a match, the destination and source screen schemes should use the same screens: Default, Create, Edit, and View.

  • If the source screen scheme has Create/Edit/View but the destination does not, we compare the source’s Create/Edit/View to the destination’s Default screen and vice versa. In this case, the Default screen scheme in the source and destination should match.

• If several destination screen schemes match, you can select any of the available options, or select the default option to create a new screen scheme.

• If a screen scheme was migrated earlier as part of a phased migration, select OVERRIDE to overwrite the destination with the source, or REUSE to use the destination screen scheme

• You cannot merge screen schemes.

Status

• During the first migration, we match statuses by name (including any migrated suffix) and status category.

• In future migrations, you can select:

  • OVERRIDE to overwrite a status in the destination with the one from the source.

  • REUSE to reuse an existing status in the destination.

Workflow

• During the first migration, we match workflows by name and the list of statuses they contain.

  • The destination workflow must include all statuses from the source. It is okay to have extra statuses on the destination.

• In future migrations, you can select:

  • OVERRIDE to overwrite a workflow in the destination with the one from the source. In this case, the source workflow must contain all statuses currently in the destination workflow.

  • REUSE to reuse an existing workflow in the destination. The destination workflow must contain all source statuses.

Workflow scheme

• During the first migration, we look for an existing scheme in which the default workflow and the issue type (work type in the Cloud) to workflow mappings are identical to those in the source.

• In future migrations, you can select:

  • OVERRIDE to overwrite a workflow scheme in the destination with the one from the source. This option ensures that the incoming workflow retains all statuses for each issue type or the default already present in the destination.

  • REUSE to reuse an existing workflow scheme in the destination. This option ensures that the existing destination workflow (for each issue type or the default) already includes all incoming statuses.

  • MERGE_SOURCE to add any missing issue type to workflow mappings. In case of conflicts, the source workflow is considered.

  • MERGE_DESTINATION to add any missing issue type to workflow mappings. In case of conflicts, the destination workflow is considered.

• In all cases, the resulting workflow must contain all statuses that existed before the operation.