いずれかの移行アシスタントを使用してユーザーやグループを移行する場合、グループがクラウド サイト内にすでに存在するかどうかが確認されます。このページでは、グループのリンク方法や、何を確認すべきかについて説明します。このガイダンスは、Confluence Cloud Migration Assistant および Jira Cloud Migration Assistant に適用されます。

クラウド サイトのユーザー管理と権限

Jira または Confluence Cloud では、製品権限はグループを通じて適用されます。Confluence へのアクセス権を持つグループにユーザーを追加した場合、新しいユーザーは Confluence へのアクセス権が与えられ、Confluence のライセンスと請求に追加されます。ユーザーへの製品アクセスの提供についてご確認ください。

サーバー製品とクラウド製品では、ユーザーとグループの管理方法が異なります。クラウド製品では、グループと権限はサイト全体で一元的に管理されます。そのため、Jira と Confluence の両方の権限を管理するグループを持つか、それぞれに別のグループを持つことができます。クラウド製品でのグループと権限についてご確認ください。

グループのリンク

Migration Assistant がユーザーを移行すると、そのユーザーが所属しているグループも移行されます。クラウド サイト内に移行するグループと同じ名前のグループがある場合、そのグループは移行されません。代わりに、サーバー製品のグループのユーザーがクラウド製品のグループに追加されます。これらのユーザーには、クラウド製品のグループと同じ権限が与えられます。

サーバー サイトとクラウド サイトでユーザーとグループが同じ (同じユーザーと権限を持つ) 場合、グループを統合しても問題は発生しないと考えられます。

ただし、同じグループではないが、グループの名前が同である場合、問題が発生する可能性があります。この説明に役立つよう、いくつかの例をまとめました。

例 1

Neha の会社はすでに 1 つの Confluence Cloud サイトを持っています。この会社では最近別の会社を買収し、Neha は、買収した Confluence Server サイトを既存のクラウド サイトに移行するように依頼されました。

クラウド製品には、すべてのスペースへの編集アクセスを持つ、"マーケティング" と呼ばれるグループがあります。サーバー製品にも "マーケティング" と呼ばれるグループがありますが、このグループはすべてのスペースへの表示アクセス権のみを持ちます。

Neha が Migration Assistant を使用すると、サーバー製品のマーケティング グループのユーザーは、クラウド製品のマーケティング グループに追加されます。つまり、これらのユーザーには編集アクセス権が付与されます。

これを回避するため、Neha は移行前にサーバー サイトのグループの名前を "ビューアー"に変更します。*その後に移行すると、サーバー製品のユーザーに追加のアクセス権は付与されません。

*次の手順に従い、Jira Server または Confluence Server サイトでグループの名前を変更できます。

例 2

Alex の会社にはサーバー製品とクラウド サイトがあります。彼らは、サーバー製品で Jira、クラウドで Confluence を使用しています。コストを削減するため、サーバー製品のすべてのデータをクラウド サイトに移行してから、クラウド サイトのみを使用することを希望しています。

Alex の Jira Server サイトには、ユーザー A、B、および C が属する "チーム リード" というグループがあります。このグループは Jira Software Server への製品アクセスを許可します。

Alex の Confluence Cloud サイトには、異なるユーザー (ユーザー 1、2、および 3) が属する "チーム リード" というグループがありますが、このグループは Confluence への製品アクセスのみを許可します。

Alex が Migration Assistant を使用してサーバー製品からクラウド製品に Jira Software プロジェクトを移行する際、Migration Assistant はユーザー (A、B および C) をサーバー製品のチーム リード グループから、クラウド製品のチーム リード グループに追加します。

つまり、クラウドのチーム リーダー グループには、ユーザー A、B、C、およびユーザー 1、2、3 が含まれるようになります。これらのユーザーはすべて Confluence へのアクセス権のみを持ち、Confluence ライセンスにカウントされます。

移行後、Alex は "Jira リード" という名前の (Jira 製品アクセスを持つ) 新しいグループを作成し、ユーザー A、B、および C (サーバー製品からのユーザー) を新しいグループに手動で移します。

例 3

Omar の会社では、サーバー上で Jira Software を使用している他、クラウド組織 Acme Inc の 2 つのサイト (サイト Acme-Global とサイト Acme-Europe) でも Jira Software を使用しています。 

Jira Software Server には Engineers (ユーザー A、B、C) というグループがあり、クラウド組織にも Engineers (ユーザー D、E、F) というグループがあります。このグループは、Acme-Europe の Jira Software Cloud へのアクセスを許可します。

Omar は、Jira Software Server のすべてのプロジェクトを Acme-Global の Jira Software Cloud に移行したいと考えています。

Omar が Migration Assistant を使用してサーバーからクラウドにプロジェクトを移行すると、Migration Assistant によって、Jira Software Server の Engineers グループのユーザー (A、B、C) がクラウド組織の Engineers グループ (Ame-Europe の Jira Software へのアクセスを許可するグループ) に追加されます。ユーザー (A、B、C) は、Acme-Global の Jira Software Cloud にはアクセスできなくなります。

これを回避するためには、移行後にユーザー (A、B、C) を Ame-Global の Jira Software Cloud へのアクセスを許可する新しいグループに手動で移動するか、移行前にサーバー上の Engineers グループの名前を変更します。

管理アクセスを管理するグループ 

管理アクセスを管理する一部のデフォルト グループは (Migration Assitant によって) ブロックリストに追加されており、移行されません。これは、管理アクセス権を持つべきでないユーザーに誤ってアクセス権を割り当てるのを防ぐためです。

ブロックリストに追加されるグループは以下のとおりです。

• "site-admins"

• "system-administrators"

• "atlassian-addons"

• "Atlassian-addons-admin"

• "administrators"

これらのグループのユーザーは引き続き移行されますが、ユーザーをいずれかのブロックリスト グループに追加したい場合、移行後に手動で追加する必要があります。

管理アクセスを管理する他のグループは移行されます。管理アクセス権を持つグループを移行する際は、慎重に行ってください。

移行後

移行後にグループが適切にセットアップされるよう、以下を行うことをおすすめします。

• [管理] > [ユーザー管理] に移動して、グループのメンバーを確認し、権限を承認します。

• 必要に応じ、汎用の管理グループ (またはブロックリストに含まれるグループ) にユーザーを追加します。 

• 外部のユーザー管理システムを使用している場合は、グループが正しく同期されていることを確認します。外部アイデンティティ プロバイダーで移行する場合はこのガイドをご覧ください。 

準備が整ったら、ユーザーを招待できます。ユーザーが初めてログインすると、新しいパスワードを設定し、個人情報を追加するように求めるメッセージが表示される場合があります。

詳細情報とサポート

移行をサポートする多数のチャンネルをご用意しています。

• 移行の詳細な計画情報や FAQ については、Atlassian Cloud 移行センターを参照してください。
• 技術的な問題が発生していたり、戦略やベスト プラクティスで支援が必要な場合、お問い合わせください。
• また、アトラシアン コミュニティもご利用ください。
• エキスパートによる支援が必要な場合、アトラシアン パートナーにご相談ください。