Jira のユーザーとグループの移行方法
Jira Cloud Migration Assistant を使用すると、Jira ユーザーを Server または Data Center から Cloud に移行できます。ユーザーを個別に移行することも、プロジェクト データと一緒に移行することもできます。
Jira Work Management の移行に対する変更
Jira Software と Jira Work Management の Jira への統合に伴い、Jira Core (Jira Work Management と同等のサーバー版) 製品の Jira グループへのアクセス権限をクラウドに移行できなくなります。ただし、次のことはできます。
Assign the Jira permissions to relevant groups.
ユーザーの移行戦略
移行を開始する前に、特にサード パーティの ID プロバイダーを使用している場合は、セットアップに適したユーザー移行方法を選択してください。ユーザー移行戦略の詳細をご確認ください。
ユーザー移行オプション
ユーザーを移行する際、事前に、またはデータ移行の一環としてユーザーを移行できます。
1. Jira のユーザーとグループを事前に移行する場合 (推奨)
アシスタントのホーム画面にある [Migrate your users in advance (事前にユーザーを移行する)] カードを使用すると、ユーザーとグループを事前に移行できます。
このオプションでは、次のものを移行します。
すべてのユーザーまたはグループ
(オプション) グループ メンバーシップ
(オプション) Jira Service Management のすべてのカスタマー
2. Jira のユーザーとグループをデータ移行の一環として移行する場合
アシスタントのホーム画面にある [データの移行] カードを使用すると、データ移行の一環として Jira ユーザーを移行できます。
このオプションでは、ユーザーの移行方法について次の選択肢があります。
オプション | 説明 |
|---|---|
すべてのユーザーとグループを移行する | Jira Work Management と Jira Software のユーザーに加え、Jira Service Management のエージェントが対象になります。 |
プロジェクトで参照されているユーザーとグループのみを移行する | 同じ計画で移行するプロジェクト データ (構成、フィールド、コンテンツ) で参照されているユーザーが対象になります。 これは、プロジェクト データをそのまま維持するために最低限必要なものです。 |
このオプションを選択した場合、プロジェクト データで参照されていない追加の関連ユーザーも選択できます。次の項目を追加できます。
|
プロジェクトで参照されているユーザーとグループの移行方法
次のテーブルは、[プロジェクトで参照されているユーザーとグループのみを移行する] オプションを選択した場合に、移行に含まれるユーザーの詳細を示しています。
すべてのユーザーまたはグループ | 参照のみ | 参照 | 参照 | 参照 | |
|---|---|---|---|---|---|
プロジェクト フィールドまたはユーザー生成コンテンツ内で参照されるユーザー | |||||
プロジェクト ロールを割り当てられたユーザーとグループ | プロジェクトでも参照される場合を除く | プロジェクトでも参照される場合を除く | |||
プロジェクト ロールを割り当てられたグループのメンバー | プロジェクトでも参照される場合を除く | プロジェクトでも参照される場合を除く | |||
選択したプロジェクトのワークフローまたは権限スキームで参照されるユーザーまたはグループ | |||||
ワークフローまたは権限スキームで参照されるグループのメンバー | プロジェクトでも参照される場合を除く | プロジェクトでも参照される場合を除く | |||
上記以外のその他すべてのユーザーとグループ |
どのようにユーザーとグループ データがリンクされているか
クラウド内のユーザー アカウントは、一意のメール アドレスによって識別されます。
移行アシスタントを使用して移行すると、各ユーザーのクラウド サイトに新しいアカウントが作成されます。クラウド サイト内にメール アドレスがすでに存在する場合、そのメール アドレスは移行されません。代わりに、そのユーザーに接続されているすべてのデータがクラウド内のアカウントにリンクされます。
移行先のクラウド サイトにユーザーがすでに存在する場合は、次のようになります。
if a user has app access (previously known as product access) in cloud, but has disabled status in your Server site, they will continue to have product access in cloud after migration
if a user does not have app access in cloud, but is enabled and has product access in your Server site, they will be granted app access through the migration process
Your groups will also be linked to existing groups in cloud (if they are already there). Group linking is identified by group name and could result in permission escalation during migration. Make sure you check your groups before migrating. Learn how groups and permissions are migrated
グループの再移行で権限のエスカレーションが発生する可能性
クラウドにグループを再移行しても、既存のメンバーシップやグループ自体は更新されません。前回の移行の後にグループに登録された新規ユーザーのみが追加されます。このため、権限のエスカレーションが発生する可能性があります。次に例を示します。
管理者グループをクラウドに移行します。
その後、Server または Data Center で、このグループから一部のユーザーを削除し、グループを再移行します。
このとき、メンバーシップの変更はクラウドには反映されません。移行済みの情報はそのまま保持されるからです。削除されたユーザーは、クラウドの管理者グループのメンバーのままとなります。
ただし、新しいユーザーをグループに追加した場合、そのユーザーはクラウドのグループに追加されます。これは、既存のメンバーシップの変更ではなく、新しいメンバーシップの追加だからです。
段階的な移行を行うときは、上記のシナリオを考慮に入れる必要があります。管理者だけが参照できると考えてプロジェクトやスペースを移行することがありますが、実際には、クラウドの管理者はサーバーの管理者よりも多くのユーザーを抱えている場合があります。
移行済みの情報はそれ以上更新されずそのまま残ることを常に念頭に置いてください。
Server または Data Center のグループに変更を加える必要がある場合は必ず、対応するクラウド グループにも手動で同じ変更を加えてください。
Re-migrated users vs. new users
When a user already exists in cloud (based on their email address), we won’t update their username if it was different in Data Center. This behavior is similar to groups (see above).
If a user doesn’t exist in cloud, we’ll create them as a new user during the migration.
ユーザーの事前移行によるダウンタイムの短縮
プロジェクト データの前にユーザーを移行すると、移行日に時間を節約できます。これは、移行アシスタントがこれらのユーザーを再移行する必要がなくなるためです。特に、すべてのユーザーを移行する場合に役立ちます。
Jira のユーザーとグループを事前に移行する方法をご確認ください。
削除済みまたは非アクティブのユーザーとディレクトリ
Jira データで参照されている任意の削除済みのユーザーや非アクティブなディレクトリのユーザーは、移行後に Former user と表示されます。これらのユーザーへの参照を移行する必要がある場合は、移行前にそのユーザー (またはディレクトリ) を再アクティブ化する必要があります。
Users with disabled status in your Server site will be migrated as active but without any app access (previously known as product access). This means they will not be counted as active Jira users for billing purposes. Learn how users are managed in Cloud
権限の確認と承認
初めて移行した場合、移行後にグループ権限を確認および承認する必要があります。グループ権限を承認すると、クラウド サイトの任意のアクティブ ユーザーが請求対象に追加されます。
グローバル設定とグローバル サイト権限はこのツールでは移行されません。これらは移行の前後に手動で設定する必要があります。
プロジェクト ロールの移行と関連する制限事項
When you select a project for migration, the roles associated with that project will also be migrated. Unfortunately, at this point in time, project roles do not get removed when you delete a project in cloud, so when you migrate that same project again, the role will get migrated with the suffix: (migrated). This is a known issue and requires manual clean-up. If you need assistance with this, contact our support team.
ユーザーへの招待メールの送信
ユーザーにアクセス権を付与することを移行時に選択した場合であっても、ユーザーへの招待は送信されません。ユーザーを招待するには、移行後に管理スペースから招待を送信するか、自身でログインできるように当該ユーザーへリンクを送信します。
クラウドでの請求
Jira Cloud is subscription-based and billed on a per-user basis. If you plan to migrate your users, make sure you check the licensing options or calculate the cost with our pricing calculator. By default, cloud subscriptions are billed on a monthly basis, however you can choose annual billing if you prefer.
サード パーティのアイデンティティ プロバイダー
Cloud で外部の ID プロバイダーを使用することを予定している場合は、ユーザーとグループの移行のガイドをご確認ください。ユーザー移行戦略の詳細をご確認ください。
移行前に、ローカル ディレクトリと同期することをお勧めします。これは、データを転送する前にユーザーとグループが最新であることを確認するためです。
詳細情報とサポート
移行をサポートする多数のチャンネルをご用意しています。
For more migration planning information and FAQs, visit the Atlassian Cloud Migration Center.
Have a technical issue or need more support with strategy and best practices? Get in touch.
Looking for peer advice? Ask the Atlassian Community.
Want expert guidance? Work with an Atlassian Partner.
Support for Atlassian Server products ends in February, 2024. Learn more about the Server end of support timeline.
この内容はお役に立ちましたか?