Confluence のユーザーとグループの移行方法

Confluence Cloud Migration Assistant を使用すると、Confluence ユーザーを Server または Data Center から Cloud に移行できます。ユーザーは単独でもスペース データと併せてでも移行できます。

ユーザー移行オプション

Confluence Cloud Migration Assistant には、ユーザーとグループを移行するためのオプションが 2 つあります。

admin.atlassian.com の改善されたユーザー管理

移行エクスペリエンスに影響する可能性のあるユーザー管理への変更を公開しています。admin.atlassian.com の組織で、[ユーザー] と [グループ] の各リストが [ディレクトリ] タブにある場合は、改善されたユーザー管理エクスペリエンスをご利用中です。つまり、複数サイト全体のユーザーとグループが組織にマージされます。

一部のユーザーとともに移行されたユーザー データ

[選択したスペースに関連するユーザーを移行する] を選択すると、移行しようとしているスペースに関連付けられている一部のユーザー データが引き続き移行されます。これは、メンション、コメント、ページ履歴をアクティブな状態に保つためです。

必ず移行されるユーザー データには、次の情報が含まれます。

• 氏名

• ユーザー名 (移行後に破棄)

• メール アドレス

このうち、移行しようとしているスペースへのアクセス権限を持つユーザーに関する情報のみが移行されます。これらのユーザーに製品アクセスは付与されません。これらのユーザーは、クラウド サイトにあるユーザーのリストに表示されます。ただし、追加されたグループに、このスペースにアクセスする権限が付与されている場合は、そのグループもユーザーとともに移行されます。

ユーザーをあとから移行することを選択した場合、それらのユーザーの製品およびグループ アクセスはあとで更新されます。

また、ユーザーとグループを移行しないことを選択し、Cloud に存在しないグループによって付与されたスペース権限がある場合、Confluence Cloud Migration Assistant では対応するスペース権限が移行されません。このシナリオを回避するには、移行の前に Cloud サイトで当該グループを作成することをお勧めします。

どのようにユーザーとグループ データがリンクされているか

クラウド内のユーザー アカウントは、一意のメール アドレスによって識別されます。

移行アシスタントを使用して移行すると、各ユーザーのクラウド サイトに新しいアカウントが作成されます。クラウド サイト内にメール アドレスがすでに存在する場合、そのメール アドレスは移行されません。代わりに、そのユーザーに接続されているすべてのデータがクラウド内のアカウントにリンクされます。

移行先のクラウド サイトにユーザーがすでに存在する場合は、次のようになります。

• ユーザーが Cloud で製品アクセスを持っているが、Server サイトでステータスが無効化されている場合は、移行後も Cloud 内で製品アクセスを持ちます。

• ユーザーが Cloud で製品アクセスを持っていないが、Server サイトで有効化されていて製品アクセスを持っている場合は、移行プロセスを通じて製品アクセスが付与されます。

グループは、Cloud にある既存のグループにもリンクされます (すでに存在する場合)。グループ リンクはグループ名で識別されて、移行時に権限がエスカレーションされる可能性があります。移行する前にグループをチェックしてください。ユーザー グループと権限の移行方法についてはこちらをご確認ください。

グループの再移行で権限のエスカレーションが発生する可能性

グループをクラウドに再移行しても、既存のメンバーシップやグループ自体は更新されません。前回の移行の後にグループに登録された新規ユーザーのみが追加されます。このため、権限のエスカレーションが発生する可能性があります。次に例を示します。

1. 管理者グループをクラウドに移行します。

2. その後、Server または Data Center で、このグループから一部のユーザーを削除し、グループを再移行します。

3. このとき、メンバーシップの変更はクラウドには反映されません。移行済みの情報はそのまま保持されるからです。削除されたユーザーは、クラウドの管理者グループのメンバーのままとなります。

4. ただし、新しいユーザーをグループに追加した場合、そのユーザーはクラウドのグループに追加されます。これは、既存のメンバーシップの変更ではなく、新しいメンバーシップの追加だからです。

段階的な移行を行うときは、上記のシナリオを考慮に入れる必要があります。管理者だけが参照できると思ってプロジェクトやスペースを移行することがありますが、実際には、クラウドの管理者はサーバーの管理者よりも多くのユーザーを抱えている場合があります。

移行済みの情報はそれ以上更新されずそのまま残ることを常に念頭に置いてください。

Server または Data Center のグループに変更を加える必要がある場合は必ず、対応するクラウド グループにも手動で同じ変更を加えてください。

ナレッジ ベースからユーザーを移行する方法

Confluence を Jira Service Management (旧 Jira Service Desk) のナレッジ ベースとして使用している場合は、Jira Service Management ユーザーが Confluence ユーザーとともに移行される可能性もあります。これは、Confluence の cwd_user テーブルに Jira Service Management ユーザーが表示される場合に発生します。

ダウンタイムを短縮するためのユーザーとグループの事前移行

スペース データの前にユーザーを移行すると、移行日に時間を節約できます。これは、移行アシスタントでこれらのユーザーを再移行する必要がなくなるためです。特に、すべてのユーザーを移行する場合に役立ちます。 

Confluence のユーザーとグループを事前に移行する方法をご確認ください。

テスト移行

テスト移行またはユーザー受け入れテスト (UAT) の場合、テスト用クラウド サイトを本番組織に含めないことをお勧めします。これは、関連するユーザーとグループのスムーズな移行を実現するためです。1 つの組織内のすべてのサイトで同じユーザーとグループを共有します。

削除済みまたは非アクティブのユーザーとディレクトリ

Confluence データで参照されている削除済みのユーザーや非アクティブなディレクトリのユーザーは、移行後に旧ユーザーと表示されます。これらのユーザーへの参照を移行する必要がある場合は、移行前にそのユーザー (またはディレクトリ) を再アクティブ化する必要があります。

サーバー インスタンスの無効ステータスのユーザーは、アクティブであるものの、製品アクセスまたはグループ メンバーシップを持たないユーザーとして移行されます。つまり、請求時にはアクティブな Confluence ユーザーとしてカウントされません。ユーザーがクラウドで管理される仕組みについてはこちらをご確認ください。

権限、グループ、製品アクセス

ユーザーを移行する場合、クラウドに移行されたユーザーは該当するグループに追加されます。初めての移行では、グループ権限を確認および承認する必要があります。グループ権限を承認すると、クラウド サイトのすべてのアクティブ ユーザーが請求対象に追加されます。

グローバル設定とグローバル サイト権限はこのツールでは移行されません。これらは移行の前後に手動で設定する必要があります。

ユーザー グループと権限の移行方法をご確認ください。

メール通知

ユーザーにアクセス権を付与することを移行時に選択した場合であっても、ユーザーへの招待は送信されません。ユーザーを招待するには、移行後に管理スペースから招待を送信するか、自身でログインできるように当該ユーザーへリンクを送信します。

クラウドの請求を変更する

Confluence Cloud はサブスクリプション ベースで、ユーザー単位で請求が行われます。ユーザーの移行を予定している場合は、ライセンス オプションを確認するか、価格シミュレーターを使用してコストを計算しておくことをおすすめします。既定では、クラウド サブスクリプションでは月単位での請求が行われますが、必要に応じて年間プランを選択できます。 

サード パーティのアイデンティティ プロバイダー

Cloud で外部の ID プロバイダーを使用することを予定している場合は、ユーザーとグループの移行のガイドをご確認ください。ユーザー移行戦略の詳細をご確認ください。

移行前に ID プロバイダーを Confluence と同期させることをおすすめします。これは、データを転送する前にユーザーとグループが最新であることを確認するためです。