5. 移行前のタスクを完了する

1. ライセンスをアップグレードする（該当する場合） - 移行プロセスの一環として、ライセンスが移動されることはありません。移行元の環境と移行先の環境で使用している Google Workspace エディションが異なる場合は、移行先に合わせて移行元をアップグレードする必要があります。詳しくは、移行先のタスクでライセンスの移行をご確認ください。

   注:

   • 移行元の環境で、一時的なライセンスとして猶予ライセンスまたは試用ライセンスを利用し、費用の発生を避けることができます。ただし、以下の点にご注意ください。
     • これらのライセンスでは、プレースホルダ ドメインとプライマリ ドメインを入れ替えるプロセスがブロックされます。一時ライセンスをプロビジョニングする前に、プレースホルダ ドメインをプライマリ ドメインと交換してください。
     • 移行先の環境で利用可能なライセンスが完全なライセンスである場合、移行の結果として、ユーザーに完全なライセンスが割り当てられます。
   • 移行元の環境でライセンスが割り当てられていない場合でも、そのユーザーは移行されます。
2. サポートされていないライセンスのサブスクリプションをキャンセルする - ライセンスのサブスクリプションをキャンセルすると、影響が生じるおそれがあります。移行元の環境で Google Voice を使用している場合は、特に注意して手順を進める必要があります。詳しくは、移行元のライセンスをご覧ください。
3. プレースホルダ ドメインを Google Workspace に追加する（該当する場合） - 最終的に既存のプライマリ ドメインに代わる予定の新しいセカンダリ ドメイン名を移行元の環境に追加して、所有権を証明します。セカンダリ ドメインが存在するものの、移行する必要がない場合は、代わりにそのセカンダリ ドメインを使用できます。詳しくは、ユーザー エイリアス ドメインまたはセカンダリ ドメインを追加するをご覧ください。
4. プレースホルダ管理者を作成してアカウントのメインの管理者にする - ユーザー アカウントを作成し、プレースホルダ ドメインと関連付けます。既存のアカウントを再利用する場合は、エイリアスとして存在する、他の移行ドメインがアカウントと関連付けられていないことを確認してください。このユーザーに特権管理者のロールを付与し、アカウントのメインの管理者にします。詳しくは、お支払いとアカウントに関する通知を別の管理者に送信するをご覧ください。

   注: このアカウントで Google 2 段階認証プロセスが無効になっていることと、アクセスを確認するために少なくとも 1 回はログイン済みであることを確認してください。

5. プライマリ ドメインをプレースホルダ ドメインと交換する - ドメインの交換を実行し、プレースホルダ ドメインを新しいプライマリ ドメインにします。

   ドメインを切り替える前に:

   切り替えの準備ができたら、Google Workspace のプライマリ ドメインを変更するをご覧ください。

   • すべてのデバイス サブスクリプション（Google Meet ハードウェア、Chrome Enterprise、Jamboard を含む）を解約します。
   • 場合によっては、移行前にサポート対象外のライセンスを削除する必要があります。詳しくは、移行元のライセンスをご覧ください。
   • 移行元の環境に試用版ライセンスがあるとドメインの交換がブロックされるため、ドメインの交換は必ず一時ライセンスをプロビジョニングする前に実行してください。
   • プライマリ ドメインを変更してセカンダリ ドメインを使用するにあたり、既知の問題があります。プライマリ ドメインの変更に代わる方法をご覧ください。
   • プライマリ ドメイン名を変更した後は、移行ユーザーまたはグループの名前を変更しないでください。ユーザーとグループは、移行ドメインに保存する必要があります。
   • サードパーティの ID プロバイダを使用して SSO を設定し、ドメイン固有の発行元を使用している場合、SAML アサーションは新しいプライマリ ドメインを反映するように変更されます。プライマリ ドメインの切り替え後にユーザーが認証できるよう、ID プロバイダの設定を確認します。詳しくは、SSO アサーションの要件をご覧ください。
6. Google Vault の保持ルールを設定する - 無期限のカスタム保持ルールを設定します。

   次のアプリケーションに対して 1 つのルールを作成します。

   • Gmail - [組織部門] でルート組織部門を選択します。
   • Google グループ - [グループ] で [すべてのグループ] を選択します。

   次のアプリケーションに対して 2 つのルールを作成します。

   • Chat - [組織部門] ルート組織部門を選択します。2 つ目のルールで、[すべての Chat スペース] を選択します。
   • ドライブ - [組織部門] ルート組織部門を選択します。2 つ目のルールで、[ すべての共有ドライブ] を選択します。
   • Meet - [組織部門] ルート組織部門を選択して、[共有ドライブのアイテムを含める] をオンにします。2 つ目のルールで、[すべての共有ドライブ] を選択します。
   • Google サイト - [組織部門] ルート組織部門を選択して、[共有ドライブのアイテムを含める] をオンにします。2 つ目のルールで、[すべての共有ドライブ] を選択します。

   また、移行する前に、移行先の環境で無期限のカスタム保持ルールが設定されます。詳しくは、移行先の環境での Google Vault の無期限の保持をご覧ください。Vault からの移行の詳細については、Domain Transfer で Vault データを移行するをご覧ください。

7. Sender Policy Framework（SPF）レコードを更新する（該当する場合） - 移行先の環境と移行元の環境で異なる送信ゲートウェイを使用している場合、移行元の環境で SPF レコードを変更して移行先の環境の送信ゲートウェイを含める必要があります。

   注: DomainKeys Identified Mail（DKIM）を使用している場合、この移行が Domain-based Message Authentication, Reporting, and Conformance（DMARC）ポリシーに影響することはありません。DKIM が一時的に使用されない場合でも、SPF レコードは移行後も引き続きそのまま使用されます。また、移行先の環境で DKIM に関する移行後の環境のタスクを完了する必要があります。

8. カレンダー リソースの競合を解決する - カレンダー リソースの競合がある場合は、次に進む前に競合を解決します。
   • ビルディング ID - 移行元の環境のビルディング ID を、移行先の環境のビルディング ID と同じにすることはできません。移行のブロックを回避するには、2 つの方法があります。移行元の環境のビルディングを削除することができます。または、2 つのビルディングの詳細を同一にして、元のビルディングと移動先のビルディングを統合することもできます。2 つのビルディングを同一にするには、ID、名前、すべてのアドレス項目、説明、階数を、両方のビルディングで完全に同じにします。
   • ビルディング名 - 移行元の環境のビルディング リソースと移行先の環境のビルディング リソースに同じ名前がある場合、いずれかのリソース名を変更して競合を解決する必要があります。移行プロセスの完了後は、2 つのビルディング リソースを統合できます。
   • リソース ID - 移行元の環境内のリソースと移行先のリソースでリソース ID が同じ場合、競合が発生します。この競合は移行プロセスで解決できず、リソースは移行されません。競合するリソースの 1 つを削除して、競合しない ID で再作成してください。削除したリソースは、システムから完全に消去されるまで 30 日ほどかかります。リソースが完全に削除されるまで待つか、Domain Transfer チームが手動で削除リクエストを送信することができます。
9. 関連する Google Cloud 組織への影響を評価する（該当する場合） - Google Cloud を使用している場合は、その環境の管理者に潜在的な影響（Google Workspace Domain Transfer が Google Cloud に与える可能性のある影響）について通知します。必要に応じて Google Cloud パートナーまたは Google Cloud の担当者に連絡し、影響の評価と対処方法に関するサポートを受けてください。ドメインの移行中に、Google Workspace Domain Transfer チームが Cloud Console のサポートを提供することはありません。
10. Google Workspace 販売パートナーに通知する（該当する場合） - 販売パートナーにドメインの移行予定時間を通知し、移行期間中はサブスクリプションの更新などの変更をアカウントに加えないよう依頼します。
11. 移行元または移行先の環境で参加しているアルファ版またはベータ版プログラムに登録する（該当する場合） - Google Workspace Domain Transfer では、移行元の環境のアルファ版プログラムとベータ版プログラムの登録は移行されません。同様に、移行先の環境で移行元の環境に依存するプログラムに登録済みの可能性があります。未登録の環境でプログラムを引き続き使用するには、プログラムに申し込み、承認を受ける必要があります。

    移行プロセス前後で移行ユーザーが同じ機能を継続して利用できるようにするため、移行前にアルファ版プログラムまたはベータ版プログラムに登録しておくことをおすすめします。ただし、登録プロセスには時間がかかることがあります。また、必ず登録できるとは限りません。したがって、登録をおすすめしますが必須ではありません。

12. Chrome のゼロタッチ登録デバイスを移行するには
    1. 移行元の環境で、既存の事前プロビジョニング トークンを取り消して、すべてのデバイスのプロビジョニングを解除します。デバイスを出荷時の設定にリセットします。
    2. 移行先の環境で、新しい事前プロビジョニング トークンを作成します。
    3. 新しいトークンを事前プロビジョニングの認定パートナーに提供してください。パートナーはこのトークンを使用して、移行先の環境でデバイスを事前プロビジョニングします。

       デバイスはインターネットに接続されると自動的に登録されます。デバイスの状態は [プロビジョニング済み] に変わります。

    ゼロタッチ登録について詳しくは、ゼロタッチ登録をご覧ください。

1. ライセンスは移行プロセスの一環として移行されないため、すべての移行ユーザーをサポートするのに十分な予備の Google Workspace ライセンスをプロビジョニングする必要がある - ユーザーの移行時には、移行元の環境で使用していたものと同じライセンスが移行先の環境で割り当てられます。したがって、移行時には移行先の環境に同じ種類の予備のライセンスが十分になくてはなりません。

   移行元の環境と移行先の環境とで使用している Google Workspace エディションが異なる場合は、そのどちらかの環境のライセンスをアップグレードすることで、ライセンスが一致するようにしてください。

   注:

   • ライセンスをアップグレードして、サービス消去処理（SWP）がトリガーされないようにすることをおすすめします。
   • 移行先の環境で複数のサブスクリプションを利用するには、不足しているライセンスをプロビジョニングします。必要に応じて、移行後に個々のユーザー ライセンスをアップグレードまたはダウングレードできます。ドメインへの部分的ライセンス付与（PDL）は、すべての種類のライセンスでサポートされているわけではありません。
   • 移行先の環境で十分な数の予備のライセンスが使用可能であることを確認します。移行プロセスの開始から終了までの間に、移行元の各環境に追加されたユーザー（新入社員など）がいないかご注意ください。複数の移行を行う場合は、すべての移行で移行元の環境のユーザーの合計数も考慮する必要があります。
   • 移行元の環境でライセンスが割り当てられていない場合でも、そのユーザーは移行されます。移行先の環境でライセンスの自動割り当て設定を確認し、これらのユーザーがライセンスを取得できないようにします。
   • Google Workspace Domain Transfer で、移行中の予備のライセンス購入に対応する Google Workspace の特別なお支払いプランが提供されることはありません。移行元の環境で年間プランのライセンスをご利用の場合、このライセンスは無効にならず、年間プランの契約が終了するまで引き続き請求が行われます。猶予ライセンスと試用ライセンスのご利用は移行元の環境でのみサポートされているため、請求は行われない場合があります。Google Workspace のお支払いプランについてご不明な点がある場合は、営業担当者またはアカウント マネージャーまでお問い合わせください。
2. 複数のライセンスがある場合は移行ユーザーにライセンスが正しく適用されていることを確認する - 移行先の環境には、移行ユーザーにライセンスを割り当てる方法に影響する可能性のある設定がいくつかあります。設定によっては、移行ユーザーに想定外のライセンスが割り当てられる場合があります。このような設定には、ライセンスの自動割り当てと組織部門のライセンスの自動割り当てのオーバーライドが含まれます。

   移行中に想定外のライセンス変更がないことを確認するには、次の操作を行う必要があります。

   • 移行先の環境で自動ライセンスの設定が [オフ（すべてのユーザー）] の場合、または移行先の環境のライセンスが 1 種類のみの場合、変更は必要ありません。
   • 移行先の環境の自動ライセンス割り当て設定が [オン（すべてのユーザー）]（Google Workspace ライセンスなど）になっている場合は、特定の組織部門に対してオーバーライドがオンになっていることを確認します。移行ルート組織部門を [オフ] にして、その子組織部門の設定をオーバーライドしないようにします。
3. 移行先のルート組織部門を作成する（必要に応じて移行元の環境の組織部門の構造を再作成する） - すべての移行ユーザーの親組織部門として機能する組織部門を作成します。組織部門を作成したら、次のいずれかを選択します。
   • 何もしない - Google Workspace Domain Transfer によって、新しい移行ルート組織部門の下に移行元の環境の組織部門の構造が再作成されます。これを行うには、移行オプション [事前に組織部門の構造を再作成する] を [いいえ] に設定します。すべての移行ユーザーは、管理者が移行ルート組織部門レベルに適用したポリシーを継承します。
   • 移行ルート組織部門の下に移行元の環境の組織部門構造を手動で再作成する - 移行の開始前に、Google Workspace Domain Transfer によって、移行元の環境の組織部門の構造全体が正しく複製されているかどうかが検証されます。これを行うには、移行オプション [事前に組織部門の構造を再作成する] を [はい] に設定します。このオプションは、子組織部門ごとに個別のポリシーを設定する場合に便利です。

     注: Google Workspace Domain Transfer では、組織部門の構造のみが検証されます。組織部門に適切なポリシーが設定されているかどうかを確認するのは、お客様の責任となります。

4. 移行元と移行先の環境の要件を反映する適切なポリシーと設定を適用する - 移行元の環境のポリシーと設定は、移行先の環境に移行されません。また、移行プロセスの完了後は、移行先の環境のポリシーと設定のみが移行ユーザーとそのデータに適用されます。

   移行先の環境のポリシーと設定を確認し、移行元の環境のものと比較する必要があります。一般設定と移行ルート組織部門の固有の設定の両方を比較して、移行されるすべての移行エンティティと移行ユーザーに確実に適用されるようにします。

   以下は、セットアップ プロセスの一環として確認する必要があるポリシーと設定の一部を紹介するリストです（すべてを網羅しているわけではありません）。また、両方の環境の完全な監査を行い、関連するすべての項目が分析されていることを確認します。

   • サービスの有効化（オン / オフ） - 移行元の環境で使用しているサービスが移行先の環境でオンになっていて、移行ルート組織部門が想定どおりに動作することを確認します。Google Vault を使用している場合はサービスがオフになっていると、Vault ルールが適用されない可能性があるため特に注意する必要があります。
   • Gmail、詳細設定、MX レコード - メールのルーティング、コンプライアンス ルール、IMAP の有効化、委任、Google Sync などの設定を確認します。詳しくは、Google Workspace で Gmail を有効にするをご覧ください。
   • パスワードの管理 - 組織のパスワード ポリシーを確認し、その方針に沿うようにします。移行ユーザーが移行先環境に移動すると、それらのユーザーには移行先環境のパスワード管理ポリシーが継承されます。
   • 2 段階認証プロセス - アカウントへの 2 段階認証プロセスの追加を許可するか、2 段階認証プロセスを任意にするか必須にするかを指定します。2 段階認証プロセスが有効になっている移行ユーザーが、2 段階認証プロセスが無効になっている移行先の環境または組織部門に移行されると、移行先の管理者はそれらのユーザーを管理できなくなります。このような場合、管理者はこれらのユーザーを 2 段階認証プロセスが有効な別の組織部門に移行して変更を加えるか、移行の前にアカウントから 2 段階認証プロセスを無効にするかのいずれかを行うことができます。
   • 共有設定 - ユーザーが組織外部とコンテンツを共有できるかどうかを制御します。移行元の環境では共有がブロックされていて、移行先の環境ではブロックされていない場合、組織の外部から移行コンテンツにアクセスできる可能性があります。移行元の環境では一般公開の共有がデフォルトで、移行先の環境ではデフォルトではない場合、組織内のユーザーが移行コンテンツにアクセスできない可能性があります。詳しくは、Google ドライブ、従来の Google サイト、Google カレンダーの共有オプションに関する記事をご覧ください。
   • データ損失防止（DLP）ルール - DLP を使用すると、ユーザーによる組織外のユーザーとの機密情報の共有を監視して防ぐことができます。移行元の環境では DLP によってユーザーが情報を共有できない場合でも、DLP が未設定の移行先の環境にコンテンツが移行されると、移行先の環境のユーザーは組織外のユーザーと情報を共有できるようになります。詳しくは、Gmail の DLP ルールとドライブの DLP ルールに関する記事をご覧ください。
   • チャットの履歴 - チャット履歴をオンにするかオフにするか、ユーザーがすべてのチャットに強制を設定できるかどうか、強制をデフォルトにするかどうかを制御できます。移行元の環境ではチャットの履歴をオンにできるが、移行先の環境ではチャットの履歴が強制的にオフの場合、チャットの履歴は失われます。Google Chat は移行の対象外とされていますが、ダイレクト メッセージ（DM）は移行されます。
   • データのある国 / データ リージョン - 移行したデータの地理的な保管場所を制御します。移行ユーザーを特定の地理的な場所から移動しないようにする必要がある場合は、必要なデータのある国 / データ リージョンからデータが意図せず移動されないように、移行先の環境でこのポリシーを適切に設定する必要があります。詳しくは、データ リージョン: データの地理的な保管場所を選択するをご覧ください。
   • 安全性の低いアプリ（アプリ パスワードとも呼ばれる） - 移行元の環境では安全性の低いアプリが有効になっていて、移行先の環境では無効になっている場合、安全性の低いアプリを使用しているアプリケーションとの接続がタイムアウトして切断されます。タイムアウト期間はアプリケーションによって異なりますが、通常は 60 分以内に期限切れになります。安全性の低いアプリケーションによる今後のアクセス要求はブロックされます。詳しくは、安全性の低いアプリへのアクセスを管理するをご覧ください。
   • OAuth スコープ、SAML シングル サインオン（SSO）、信頼できるアプリ、Chrome 拡張機能 - OAuth コントロールは、ユーザーとサードパーティ製アプリケーションに許可される API アクセスのレベルを決定します。SAML SSO は、Google Workspace によって提供されているか、カスタム アプリケーションとして導入されているかにかかわらず、ユーザーが Google Workspace の認証情報を使用して他のアプリケーションやサービスにアクセスできるようにします。信頼できるアプリは、ユーザーが Google Workspace Marketplace または Chrome ウェブストアからインストールできるアプリケーションと、OAuth 制限をバイパスできるアプリを決定します。詳しくは、サードパーティ製アプリと内部アプリを制御する方法、SAML SSO、Google Workspace Marketplace アプリ、Chrome アプリと拡張機能に関する記事をご覧ください。
   • ドメイン全体での委任 - ユーザーの Google Workspace データへのアクセスをアプリに許可します。クライアントとスコープが正しく機能するように、移行先の環境でのドメイン全体の委任設定を移行前に行います。

   重要: ポリシーと設定を正しく適用しないと、次のようになる可能性があります。

   • 組織外部への意図しないデータ漏えい（たとえば、移行先の環境の設定が移行元の環境よりも緩い場合）
   • 以前はアクセス可能だったデータへのアクセスの制限（たとえば、移行先の環境の設定が移行元の環境よりも厳しい場合）
5. 移行データに適用される条項に同意する - 移行先の環境でデータ処理の修正条項（DPA）、モデル契約条項、HIPAA 業務提携の修正条項（BAA）を確認します。詳しくは、Google Workspace および Cloud Identity のプライバシー コンプライアンスと記録をご覧ください。
6. 移行元の環境で使用されている場合は Vault を有効にする - 移行先の環境では Vault を使用していないが、移行元の環境では使用している場合、移行先の環境で Vault を有効にする必要があります。
7. Google Workspace 販売パートナーに通知する（該当する場合） - 販売パートナーにドメインの移行予定時間を通知し、移行期間中はサブスクリプションの更新などの変更をアカウントに加えないよう依頼します。
8. 移行元または移行先の環境で参加しているアルファ版またはベータ版プログラムに登録する（該当する場合） - Google Workspace Domain Transfer では、移行元の環境のアルファ版プログラムとベータ版プログラムの登録は移行されません。同様に、移行先の環境で移行元の環境に依存するプログラムに登録済みの可能性があります。未登録の環境でプログラムを引き続き使用するには、プログラムに申し込み、承認を受ける必要があります。

   移行プロセス前後で移行ユーザーが同じ機能を継続して利用できるようにするため、移行前にアルファ版プログラムまたはベータ版プログラムに登録しておくことをおすすめします。ただし、登録プロセスには時間がかかることがあります。また、必ず登録できるとは限りません。したがって、登録をおすすめしますが必須ではありません。

• チェンジ マネジメント - 移行プロセスが実施されている間、移行の情報が Google Workspace Domain Transfer チームやシステムからユーザーに自動的に通知されることはありません。移行元と移行先の環境の担当者が、移行プロセスとその潜在的な影響についてユーザーに事前に通知することを強くおすすめします。

  移行中は、API や Google 管理コンソールへのアクセスなど、移行元と移行先の両方の環境ですべての管理操作がブロックされます。移行元と移行先の環境の担当者が、移行前および移行の完了後に、すべてのドメインの特権管理者および代理管理者に通知することを強くおすすめします。

• 外部との依存関係 - Google Cloud Directory Sync (GCDS)、GAM（Google Workspace 管理者がドメインとユーザーの設定を管理するためのサードパーティのコマンドライン ツール）、サードパーティのシングル サインオン（SSO）プロバイダを使用している場合は、移行による影響を必ず分析してください。また、1 つの環境に移行元と移行先の環境を共存させることによる、システムと移行の実施タイミングへの影響を調べます。

Google Workspace Domain Transfer によって、移行先の環境に無期限のカスタム保持ルールが設定されます。移行先の環境の管理者による操作は必要ありません。

移行ユーザーの Vault アーカイブは移動されますが、移行元の環境の Vault 保持ルールは移動されません。移行中および移行後の Vault データが危険にさらされないよう、移行プロセスでは移行アクションを実行する前に、移行先の環境に次の Vault 保持ルールが作成されます。

• Gmail - 無期限のカスタム保持ルール（対象: 移行先のルート組織部門）。
• Google カレンダー - 無期限のカスタム保持ルール（対象: 移行ルート組織部門）。
• Google Chat - 無期限のカスタム保持ルール（対象: スペースを除く、移行先のルート組織部門の移行ユーザーのダイレクト メッセージ）。
• Google ドライブ - 共有ドライブを除く無期限のカスタム保持ルール（対象: 移行先のルート組織部門）。
• Google グループ - 無期限のカスタム保持ルール（対象: 移行先のルート組織部門）。 移行先の環境内にあるすべてのグループのデータが保持されます（移行プロセスの対象ではないものも含む）。
• Google Meet - 次の 2 つの無期限のカスタム保持ルール（必須）。
  1. 共有ドライブを含まない（対象: 移行ルート組織部門）。
  2. すべての共有ドライブを含む（対象: 移行先のルート組織部門）。

     移行先の環境内にあるすべての共有ドライブのデータが保持されます（移行プロセスの対象ではないものも含む）。

• Google サイト - 次の 2 つの無期限のカスタム保持ルール（必須）。
  1. 共有ドライブを含まない（対象: 移行ルート組織部門）。
  2. すべての共有ドライブを含む（対象: 移行先のルート組織部門）。

     移行先の環境内にあるすべての共有ドライブのデータが保持されます（移行プロセスの対象ではないものも含む）。

• 共有ドライブ - すべての共有ドライブに対する無期限のカスタム保持ルール（対象: 移行先のルート組織部門）。 移行先の環境内にあるすべての共有ドライブのデータが保持されます（移行プロセスの対象ではないものも含む）。

重要: 移行プロセス中に移行先の環境の Vault 保持ルールが削除または変更されることはありません。削除すると、元に戻せないデータ損失が発生する可能性があるためです。