Cloud 移行を計画する
Atlassian Server または Data Center 製品の移行準備に役立つドキュメント。
ユーザーの移行時、そのユーザーが所属するグループがクラウドにすでに存在するかどうかが、グループの名前に基づいて確認されます。
存在する場合は、次のアクションが実行されます。
新規ユーザーを既存のクラウド グループに移行します
サーバー グループは移行せず、元のグループをクラウドに残します
サーバー グループから製品へのアクセスを移行せず、本来のアクセスをクラウドに残します
同じグループを再移行するのであれば、これによって何らかの問題が生じることはありません。ただし、異なる製品からの重複したグループの移行や、移行間でのメンバーシップの変更などを行う場合は、ユーザーが本来持つべきではないアクセスや権限を取得する可能性があります。
クラウド内の重複グループがサーバー グループよりも多くの製品にアクセスできる場合、ユーザーは追加の製品アクセスを取得でき、その延長として権限も取得できます。
この例では、次のグループがあります。
サーバー: マーケティング (このグループには Confluence で閲覧のみの権限が設定されています)
クラウド: マーケティング (このグループには Confluence で閲覧および編集の権限が設定されています)
移行する際、サーバー グループのユーザーは移行されますが、グループは移行されません。これは、クラウド内に同じ名前のグループがすでに存在しているためです。Confluence Cloud はクラウド グループにより多くの権限を与えるように設定されているため、移行されたユーザーに追加の編集権限が付与されます。
クラウド内の重複したグループがそれぞれ異なる製品に設定されている場合、ユーザーに誤った製品アクセスが付与される可能性があります。
この例では、次のグループがあります。
サーバー: チーム リード (Jira へのアクセス)
クラウド: チーム リード (Confluence へのアクセス)
移行する際、サーバー グループのユーザーは移行されますが、グループは移行されません。これは、クラウド内に同じ名前のグループがすでに存在しているためです。これにより、サーバー グループから移行されたユーザーは、Jira ではなく Confluence へのアクセスという異なるアクセス権が付与されます。
グループをクラウドに移行し、サーバー側でメンバーを変更すると、新しいメンバーだけがクラウド グループに追加されます。ユーザーの削除など、既存のメンバーシップが変更されることはありません。
この例では、次のような同等のグループがあります。
サーバー:管理者(4 ユーザー)
クラウド:管理者(4 ユーザー)
サーバーの管理者グループからユーザーを削除して、このグループをクラウドに再移行した場合、そのユーザーはクラウド グループから削除されません。グループに新しいユーザーを追加できますが、既存のメンバーシップは変更できません。
これは、段階的な移行において、異なるプロジェクトやスペースを異なるタイミングで移行する場合に特に重要となります。プロジェクトやスペースは管理者のみが閲覧できると思われがちですが、実際のところ、クラウドの管理者はサーバーの管理者よりも多くのユーザーを抱えている場合があります。
グループの名前を変更するか、新しいグループを作成してユーザーを移動することで、これらの問題を回避する方法があります。
サーバー グループの名前を変更するのは、データベースを変更する必要があるため、簡単ではありません。移行前に名前を変更すると、そのグループは元の製品アクセスを持つ固有のグループとして移行されます。
サーバーとは異なり、クラウドではグループの名前を変更できます。移行前に名前を変更すると、移行済みのサーバー グループはクラウドでの重複したグループを失い、新しい固有のグループとして移行されます。
また、新しいグループを作成し (例: チーム リード → Jira チーム リード、Confluence チーム リード)、移行したユーザーを移行前または移行後にこれらのグループに移動することもできます。
グループ メンバーシップを維持せずにユーザーを移行することもできます。これにより、移行直後に別の製品へのアクセス権が付与されるのを防ぐことができます。
移行間でグループ メンバーシップを変更する場合は、手動による更新が再移行されないことを常に想定する必要があります。サーバー側でこのような変更を加える際は、常に同じ変更をクラウドで行ってください。
この内容はお役に立ちましたか?