すべての製品を別の組織に転送する

一元化されたユーザー管理をご利用の場合、このページは適用されません。

admin.atlassian.com の組織から、[ユーザー] と [グループ] の各リストが [ディレクトリ] タブにある場合は、一元化されたユーザー管理エクスペリエンスを使用しており、製品の転送は無効になっています。製品を別の組織に転送するか、新しい製品を組織に追加するには、サポートにお問い合わせください。

[ユーザーとグループ] ではなく新しい [ディレクトリ] タブを表示する、新しい admin.atlassian.com ビューの図

すべての製品インスタンスを転送して組織をマージできるかどうかは、いくつかの要因によって決まります。主に、組織の複雑さと、新しいユーザー管理機能を使用しているかどうかが影響します。組織のマージが可能かどうかをご確認ください。

1. 転送の計画

ここではまず、2 つの組織をマージすることの意味について十分に理解しているかを確認しましょう。アトラシアンの組織をマージできますか?

また、時間をかけて転送の計画を立て、変更内容を製品管理者に事前に伝えることをお勧めします。

  • 製品を他の組織に転送することを製品管理者に伝えます。
    転送は、製品管理者のロールや製品の管理方法には影響しませんが、新しい組織の構成が異なる場合は、製品ユーザーに影響を及ぼす可能性があります。

  • 両方の組織の管理者を確認します。
    転送元組織の組織管理者はすべて、転送先組織でも組織管理者になります。つまり、すべてのサイトのサイト管理者になるということです。他のユーザーにこの権限を与えない場合は、転送する前に、該当するユーザーの組織管理者ロールを削除します。

  • 既存の設定を確認し、転送先組織で必要な構成を再作成します。
    転送プロセスの一環として、必要のない組織の構成やサブスクリプションのほとんどを削除する必要があります。転送先組織で必要な構成を再作成できるように、既存の設定を書き留めておくことをお勧めします。

転送チェックリスト: 削除して再作成する設定とサブスクリプション

転送を開始する前に、テーブルでメンションされた構成とサブスクリプションがある場合は削除するように求められます。

こうした変更の一部はユーザーのログイン方法に影響するため、転送を開始する直前に既存の設定を削除することをお勧めします。

セキュリティ設定

どのグループもプロビジョニングを解除しないでください。移行する製品の既存のグループと権限設定を維持するには、まず Atlassian 側の構成で接続を解除します。

サブスクリプションとプラン

Atlassian Access を解約する場合、サブスクリプションを譲渡することはできませんが、古いサブスクリプションの払い戻しは可能です。払い戻しを依頼するには、請求書とライセンスに関するお問い合わせフォームに記入してください。

領域

DNS ホストによっては、ドメインが検証されて DNS の変更が有効になるまでに最大 72 時間かかる場合があります。最適な時間帯で計画することをお勧めします。

ユーザーの招待

HIPAA 準拠

  • HIPAA 準拠を必要とする製品がある場合は、転送を完了する前に、宛先の組織で Business Associate Agreement (BAA) 契約に署名してください。これらの製品に Standard プランまたは Premium プランが含まれる場合にのみ、これを行う必要があります。転送後、商品に HIPAA 準拠のタグが付けられていることをご確認ください。
    Business Associate Agreement (BAA) の締結

2. 製品すべての転送

このステップは、両方の組織が一元化されたユーザー管理機能を使用していない場合にのみ適用されます (ユーザー リストとグループ リストが admin.atlassian.com の [ディレクトリ] タブに表示されていれば、一元化されたユーザー管理を使用しています)。

一元化されたユーザー管理機能を使用している場合は、いくつかの選択肢があります。組織のマージが可能かどうかをご確認ください。

両方の組織で組織管理者になっている必要があります。また、上記で推奨する準備を完了していることも必要です。

転送プロセスを実行すると、元に戻すことはできません。

すべての製品インスタンスを 1 つの組織から別の組織に転送する方法は次のとおりです。

  1. admin.atlassian.com に移動します。組織が複数ある場合は組織を選択します。不要になった組織を選択しましょう。

  2. [設定] > [詳細] を選択します。

  3. 転送前チェックリストにあるタスクをすべて完了していることをご確認ください。

  4. [製品の転送] を選択して、手順に従います。転送先組織の選択と変更の確認を行ってから、転送を確認します。

  5. サポート チケットを作成し、Atlassian アカウントのデータを新しい組織に転送します。この転送が完了するまで、Atlassian Analytics、および Jira Service Management と Opsgenie の製品内の資産と運用のレポートでデータの不一致が発生する可能性があります。

製品インスタンスとアカウント データが転送されると、空になった組織が削除されます。

ユーザーのアクセスは中断されませんが、シングル サインオンの設定が転送先の組織で異なる場合は、ログインに多少の違いがあります。

転送チェックリストには、すべての製品を転送する前に削除する必要がある構成やサブスクリプションが記載されています。

これで、転送先の組織で API キー、許可リスト、ドメイン、その他の構成を再作成できるようになりました (まだ作成していない場合)。

すべての製品を別の組織に転送すると変更されること

すべての製品を転送して組織をマージした後に何が起きるかを知ることは重要です。

変更されないこと

  • ダウンタイムやアクセスの損失が発生することはありません。

  • 同じ製品アクセスと権限が保持されます。

  • 転送された製品の製品管理者は、引き続き、その製品インスタンスの製品管理者になります。

  • 転送されたサイトのサイト管理者は引き続き、それらのサイトのサイト管理者です。

  • 転送先組織の組織管理者は、引き続き組織管理者になります。

  • 転送された製品には、URL、権限、プロジェクト、スペース、コントロール、アプリが保持されます。

  • 転送された製品は分離されたままです。両方の組織に同じ製品があった場合、転送後に複数の製品インスタンスが存在することになります (マージされることはありません)。

  • 転送された製品の請求は分離されたままになるため、同じ数の請求書(Atlassian Access を除く)が発行されます。

  • 製品の請求書は、引き続きサイト別に分類されます。

変更されること

  • 転送元の組織で組織管理者のロールだったユーザーはすべて、転送先の組織でも組織管理者になり、関連するすべてのサイトのサイト管理者として追加されます。

  • admin.atlassian.com の [概要] タブと [製品] タブには、マージ後の組織の製品すべてが表示されます。

  • 必要なくなった組織は、admin.atlassian.com のランディング ページに表示されなくなります。

  • 転送の過程で追加された組織管理者に新しく製品アクセス権が付与された場合、請求額が増加する可能性があります (それらのユーザーに対する支払いを停止したい場合、転送後に該当ユーザーの管理および製品権限を更新できます)。

  • ユーザーのログイン方法が一時的に変わる場合があります。ユーザーは、必要のない組織で SSO をオフにした後、転送が完了して新しい組織で SSO が設定される前に、ログイン用のパスワードを設定する必要があります。

  • 転送を完了するために以前のユーザー管理に戻す必要があった場合は、admin.atlassian.com のナビゲーションが異なることがわかります。

その他のヘルプ