すべての製品を別の組織に転送する
一元化されたユーザー管理をご利用の場合、このページは対象外となります。 admin.atlassian.com の組織で、[ユーザー] と [グループ] の各リストが [ディレクトリ] タブにある場合は、一元化されたユーザー管理エクスペリエンスをご利用であるため、製品の転送は無効になっています。サポートにお問い合わせのうえ、ご利用の製品を別の組織に転送するか、新しい製品を組織に追加しましょう。 |
すべての製品インスタンスを転送して、組織をマージできるかどうかは、いくつかの要因によって決まります。これは主に組織の複雑さと、新しいユーザー管理機能を使用しているかどうかが影響します。組織のマージが可能かどうかをご確認ください。
1. 転送の計画
ここではまず、2 つの組織をマージすることの意味について十分に理解しているかを確認しましょう。アトラシアンの組織をマージできますか?
また、時間をかけて転送の計画を立て、変更内容を製品管理者に事前に伝えることをお勧めします。
製品を他の組織に転送することを製品管理者に伝えます。
転送は、製品管理者のロールや製品の管理方法には影響しませんが、新しい組織の構成が異なる場合は、製品ユーザーに影響を及ぼす可能性があります。両方の組織の管理者を確認します。
転送元組織の組織管理者はすべて、転送先組織でも組織管理者になります。つまり、すべてのサイトのサイト管理者になるということです。他のユーザーにこの権限を与えない場合は、転送する前に、該当するユーザーの組織管理者ロールを削除します。既存の設定を確認し、転送先組織で必要な構成を再作成します。
転送プロセスの一環として、必要のない組織の構成やサブスクリプションのほとんどを削除する必要があります。転送先組織で必要な構成を再作成できるように、既存の設定を書き留めておくことをお勧めします。
転送チェックリスト: 削除して再作成する設定とサブスクリプション
転送を開始する前に、転送元の組織から特定の設定とサブスクリプションを削除するように求められます。次の表で概要をご確認ください。
こうした変更の一部はユーザーのログイン方法に影響するため、転送を開始する直前に既存のセットアップを削除することをお勧めします。
セキュリティ設定 |
どのグループもプロビジョニングを解除しないでください。移行する製品の既存のグループと権限設定を維持するには、まず Atlassian 側の構成で接続を解除します。
|
|---|---|
サブスクリプションとプラン |
Atlassian Guard を解約する場合、サブスクリプションを譲渡することはできませんが、古いサブスクリプションの払い戻しは可能です。払い戻しを依頼するには、請求書とライセンスに関するお問い合わせフォームに記入してください。 Atlassian Guard Premium のトライアル版またはサブスクリプションを利用している場合は、製品を転送するのにサポート チームの支援が必要になります。これは、Atlassian Guard Premium には転送できない設定がいくつかあるためです。
|
領域 |
DNS ホストによっては、ドメインが検証されて DNS の変更が有効になるまでに最大 72 時間かかる場合があります。最適な時間帯で計画することをお勧めします。
|
ユーザーの招待 |
|
HIPAA 準拠 |
|
Atlassian Intelligence |
|
2. 製品すべての転送
このステップは、両方の組織が一元化されたユーザー管理機能を使用していない場合にのみ適用されます (ユーザー リストとグループ リストが admin.atlassian.com の [ディレクトリ] タブに表示されていれば、一元化されたユーザー管理を使用しています)。
一元化されたユーザー管理機能を使用している場合は、いくつかの選択肢があります。組織のマージが可能かどうかをご確認ください。
両方の組織で組織管理者になっている必要があります。また、上記で推奨する準備を完了していることも必要です。
転送プロセスを実行すると、元に戻すことはできません。
すべての製品インスタンスを 1 つの組織から別の組織に転送する方法は次のとおりです。
admin.atlassian.com に移動します。組織が複数ある場合は組織を選択します。不要になった組織を選択しましょう。
[設定] > [詳細] を選択します。
転送前チェックリストにあるタスクをすべて完了していることをご確認ください。
[製品の転送] を選択して、手順に従います。転送先組織の選択と変更の確認を行ってから、転送を確認します。
組織で Atlassian Analytics、Jira Service Management、または Opsgenie を使用している場合は、技術的な問題やバグに関するサポート チケットを作成して、Atlassian アカウントが新しい組織に適切に関連付けられるようにしてください。このリクエストが完了するまで、Atlassian Analytics、および Jira Service Management と Opsgenie の製品内の資産と運用のレポートでデータの不一致が発生する可能性があります。
製品インスタンスとアカウント データが転送されると、空になった組織が削除されます。
ユーザーのアクセスは中断されませんが、シングル サインオンの設定が転送先の組織で異なる場合は、ログインに多少の違いがあります。
これで、転送先の組織で API キー、許可リスト、ドメイン、その他の構成を再作成できるようになりました (まだ作成していない場合)。
すべての製品を別の組織に転送すると変更されること
すべての製品を転送して組織をマージした後に何が起きるかを知ることは重要です。
変更されないこと
ダウンタイムやアクセスの損失が発生することはありません。
同じ製品アクセスと権限が保持されます。
転送された製品の製品管理者は、引き続き、その製品インスタンスの製品管理者になります。
転送されたサイトのサイト管理者は引き続き、それらのサイトのサイト管理者です。
転送先組織の組織管理者は、引き続き組織管理者になります。
転送された製品には、URL、権限、プロジェクト、スペース、コントロール、アプリが保持されます。
転送された製品は分離されたままです。両方の組織に同じ製品があった場合、転送後に複数の製品インスタンスが存在することになります (マージされることはありません)。
転送された製品の請求は分離されたままになるため、同じ数の請求書 (Atlassian Guard Standard を除く) が発行されます。
製品の請求書は、引き続きサイト別に分類されます。
変更されること
転送元の組織で組織管理者のロールだったユーザーはすべて、転送先の組織でも組織管理者になり、関連するすべてのサイトのサイト管理者として追加されます。
admin.atlassian.com の [概要] タブと [製品] タブには、マージ後の組織の製品すべてが表示されます。
必要なくなった組織は、admin.atlassian.com のランディング ページに表示されなくなります。
転送の過程で追加された組織管理者に新しく製品アクセス権が付与された場合、請求額が増加する可能性があります (それらのユーザーに対する支払いを停止したい場合、転送後に該当ユーザーの管理および製品権限を更新できます)。
ユーザーのログイン方法が一時的に変わる場合があります。ユーザーは、必要のない組織で SSO をオフにした後、転送が完了して新しい組織で SSO が設定される前に、ログイン用のパスワードを設定する必要があります。
転送を完了するために以前のユーザー管理に戻す必要があった場合は、admin.atlassian.com のナビゲーションが異なることがわかります。
メンションとユーザー ピッカーのユーザー検索結果が、転送後最大 12 時間は一致しない可能性があります。
この内容はお役に立ちましたか?