Entity behavior while resolving configuration duplication

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).

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.

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.

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.

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.

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.