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 グループへのアクセス権限をクラウドに移行できなくなります。ただし、次のことはできます。
ユーザーの移行戦略
移行を開始する前に、特にサード パーティの 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
グループは、Cloud にある既存のグループにもリンクされます (すでに存在する場合)。グループ リンクはグループ名で識別されて、移行時に権限がエスカレーションされる可能性があります。移行する前にグループをチェックしてください。グループと権限の移行方法をご確認ください。
グループの再移行で権限のエスカレーションが発生する可能性
クラウドにグループを再移行しても、既存のメンバーシップやグループ自体は更新されません。前回の移行の後にグループに登録された新規ユーザーのみが追加されます。このため、権限のエスカレーションが発生する可能性があります。次に例を示します。
管理者グループをクラウドに移行します。
その後、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
権限の確認と承認
初めて移行した場合、移行後にグループ権限を確認および承認する必要があります。グループ権限を承認すると、クラウド サイトの任意のアクティブ ユーザーが請求対象に追加されます。
グローバル設定とグローバル サイト権限はこのツールでは移行されません。これらは移行の前後に手動で設定する必要があります。
プロジェクト ロールの移行と関連する制限事項
移行するプロジェクトを選択すると、そのプロジェクトに関連付けられたロールも移行されます。残念ながら現時点では、クラウドでプロジェクトを削除してもプロジェクト ロールは削除されないため、同じプロジェクトを再度移行するとロールはサフィックス (migrated) 付きで移行されます。これは既知の課題で、手動でクリーンアップする必要があります。この問題に関してお困りの場合は、サポート チームまでお問い合わせください。
ユーザーへの招待メールの送信
ユーザーにアクセス権を付与することを移行時に選択した場合であっても、ユーザーへの招待は送信されません。ユーザーを招待するには、移行後に管理スペースから招待を送信するか、自身でログインできるように当該ユーザーへリンクを送信します。
クラウドでの請求
Jira Cloud はサブスクリプション ベースで、ユーザー単位で請求が行われます。ユーザーの移行を予定している場合は、ライセンス オプションを確認するか、価格シミュレーターを使用してコストを計算しておくことをおすすめします。既定では、クラウド サブスクリプションでは月単位での請求が行われますが、必要に応じて年間プランを選択できます。
サード パーティのアイデンティティ プロバイダー
Cloud で外部の ID プロバイダーを使用することを予定している場合は、ユーザーとグループの移行のガイドをご確認ください。ユーザー移行戦略の詳細をご確認ください。
移行前に、ローカル ディレクトリと同期することをお勧めします。これは、データを転送する前にユーザーとグループが最新であることを確認するためです。
詳細情報とサポート
移行をサポートする多数のチャンネルをご用意しています。
移行の詳細な計画情報や FAQ については、Atlassian Cloud 移行センターを参照してください。
技術的な問題が発生していたり、戦略やベスト プラクティスで支援が必要な場合、お問い合わせください。
専門的なアドバイスについては、アトラシアン コミュニティもご利用ください。
専門家によるサポートが必要な場合は、アトラシアン パートナーにご相談ください。
アトラシアン サーバー製品のサポートは 2024 年 2 月に終了します。サーバーのサポート終了スケジュールで詳細をご参照ください。
この内容はお役に立ちましたか?