設定の重複を解消する際のエンティティの動作

ボード

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

カスタム フィールド

• フィールドは、名前 (「migrated」サフィックスを含む) とタイプに基づいて照合されます。

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

カスタム フィールド コンテキスト (CustomFieldConfigScheme)

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

• プロジェクト固有のコンテキストは、移行先で新たに作成されます。

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

• 移行中に、コンテキストをグローバルからプロジェクト固有に変更したり、その逆に変更したりすることはできません。

FieldLayout

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

• 一致する移行先フィールド レイアウトが複数ある場合は、その中のいずれかを再利用するか、[DEFAULT] オプションを選択して新しいレイアウトを作成します。

• フィールド レイアウトが段階的移行の一環として以前に移行されている場合は、次のいずれかを選択します。

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

  • REUSE to reuse the field layout in the destination.

FieldLayoutScheme

• 一致と見なされるためには、次の条件を満たしている必要があります。

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

• 一致する移行先スキームが複数ある場合は、その中のいずれかを再利用するか、[DEFAULT] オプションを選択して新しいスキームを作成できます。

• スキームが段階的移行の一環として以前に移行されている場合は、次のいずれかを選択します。

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

フィルター

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

課題タイプ (Cloud では作業タイプ)

• 課題タイプは、名前 (「migrated」サフィックスを含む) と階層レベルに基づいて照合されます。

  • 明確に一致する課題タイプがある場合、その課題タイプは自動的に再利用されます。

  • 一致する候補が複数ある場合は、その中から 1 つを選択する必要があります。

• 課題タイプが段階的移行の一環としてすでに移行されており、その名前が移行先で変更されている場合は、移行先の課題タイプを再利用するか、移行元の課題タイプでオーバーライドするかを選択できます。

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

課題タイプ スキーム (Cloud では作業タイプ スキーム)

• 移行先のスキームに、移行元のスキームに含まれるすべての課題タイプ (追加の課題タイプがある場合はそれも含む) が含まれている場合、そのスキームは一致すると見なされます。

• 一致する移行先スキームが複数ある場合は、その中からいずれか 1 つを再利用するよう選択できます。

  • [DEFAULT] オプションを選択して、新しい課題タイプ スキームを作成することもできます。

• 課題タイプ スキームが段階的移行の一環としてすでに移行されている場合は、既存の移行先スキームにマージされます。この場合、移行先スキームの名前と既定の課題タイプが維持されます。

• 課題タイプ スキームに対して実行するアクションは選択できません。課題タイプ スキームは自動的にマージされます。

課題タイプ画面スキーム (Cloud では作業タイプ画面スキーム)

• 一致と見なされるためには、次の条件を満たしている必要があります。

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

  • 移行元の課題タイプと画面スキームの関連付けが、移行先と一致していること。

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

• 一致する移行先の課題タイプ画面スキームが複数ある場合は、その中のいずれかを再利用するか、[DEFAULT] オプションを選択して新しいスキームを作成できます。

• スキームが以前に移行されている場合は、次のいずれかを選択します。

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

通知スキーム

• 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 that match will be reused as much as possible.

• 段階的移行の一環としてすでに移行されているオプションについては、移行先のオプションを再利用するか、移行元のオプションでオーバーライドするかを選択できます。

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

• ユーザー フィルターはマージされます。

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

権限スキーム

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

優先度

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

プロジェクトロール

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

画面

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

• 一致する移行先画面が複数ある場合は、その中のいずれかを再利用するか、[DEFAULT] を選択して新しい画面を作成できます。

• 画面が段階的移行の一環として以前に移行されている場合は、既存の移行先画面にマージされ、その名前が維持されます。

  • 移行元の追加フィールドは、移行先の既存のタブに追加されます。

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

  • 移行前にタブ名を変更すると、そのタブは移行先で新しいタブとして作成されます。

  • フィールドが移行先の別のタブにすでに存在する場合、そのフィールドは移行元から再度追加されません。

• 画面は常にマージされるため、画面専用のポリシー設定はありません。

画面スキーム

• 一致と見なされるためには、移行先と移行元の画面スキームで、[既定]、[作成]、[編集]、[表示] に同じ画面を使用する必要があります。

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

• 一致する移行先画面スキームが複数ある場合は、その中のいずれかを選択できます。また、[DEFAULT] オプションを選択して新しい画面スキームを作成することもできます。

• 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

• 画面スキームをマージすることはできません。

ステータス

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

ワークフロー

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

ワークフロースキーム

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