۵. وظایف پیش از انتقال را انجام دهید

1. ارتقاء مجوزها (در صورت وجود) — مجوزها به عنوان بخشی از فرآیند انتقال منتقل نمی‌شوند. اگر محیط منبع از نسخه Google Workspace متفاوتی نسبت به محیط مقصد استفاده می‌کند، باید منبع را برای مطابقت با مقصد ارتقا دهید. برای اطلاعات بیشتر، انتقال مجوزها را در بخش وظایف مقصد بررسی کنید.

   یادداشت‌ها:

   • برای جلوگیری از هزینه‌ها، می‌توانید از مجوزهای موقت یا آزمایشی در محیط منبع برای تهیه مجوز موقت استفاده کنید. با این حال، به نکات زیر توجه داشته باشید:
     • این مجوزها فرآیند تعویض هر دامنه دیگری با دامنه اصلی را مسدود می‌کنند. قبل از ارائه هرگونه مجوز موقت، دامنه اصلی را تغییر دهید.
     • اگر مجوزهای موجود در محیط مقصد، مجوزهای کامل باشند، در نتیجه انتقال، به کاربران مجوزهای کامل اختصاص داده می‌شود.
   • کاربرانی که در محیط منبع هستند و هیچ مجوزی به آنها اختصاص داده نشده است، همچنان می‌توانند مجوز خود را منتقل کنند.
2. لغو اشتراک‌های مجوز پشتیبانی نشده — در برخی موارد، شما باید مجوزهای پشتیبانی نشده را از کاربران انتقالی حذف کنید، در حالی که کاربران غیر انتقالی می‌توانند مجوزهای خود را حفظ کنند. در غیر این صورت، شما باید تمام مجوزهای پشتیبانی نشده را به طور کامل لغو یا حذف کنید. آزمایش عملی، مجوزهایی را که باید لغو کنید، تأیید می‌کند.

   شما باید Google Voice را برای همه کاربران لغو کنید. لغو اشتراک مجوز ممکن است پیامدهایی داشته باشد. محیط‌های منبع دارای Google Voice باید به این مرحله توجه کنند. برای جزئیات بیشتر، به مجوزهای منبع مراجعه کنید.

3. اگر می‌خواهید دامنه اصلی فعلی را منتقل کنید، یک دامنه اصلی جدید اختصاص دهید — این مرحله فقط در صورتی لازم است که بخواهید دامنه اصلی فعلی خود را منتقل کنید. یک مبادله دامنه انجام دهید و هر دامنه دیگری را به عنوان دامنه اصلی جدید ارتقا دهید. هر دامنه غیرقابل انتقال را می‌توان برای این منظور به عنوان دامنه اصلی ارتقا داد.

   قبل از تعویض دامنه:

   وقتی آماده تعویض شدید، به تغییر دامنه اصلی خود برای Google Workspace بروید.

   • تمام اشتراک‌های دستگاه، از جمله سخت‌افزار Google Meet و Chrome Enterprise را لغو کنید.
   • ممکن است لازم باشد برخی از مجوزهای پشتیبانی نشده قبل از انتقال حذف شوند. برای جزئیات بیشتر، به مجوزهای منبع مراجعه کنید.
   • اگر محیط منبع دارای مجوزهای آزمایشی باشد، مبادله مسدود خواهد شد. قبل از تهیه هرگونه مجوز موقت، مطمئن شوید که مبادله انجام می‌شود.
   • تغییر دامنه اصلی و استفاده از دامنه‌های ثانویه مشکلات شناخته‌شده‌ای دارد. جایگزین‌های تغییر دامنه اصلی خود را بررسی کنید.
   • پس از تغییر نام دامنه اصلی، نام کاربران یا گروه‌های انتقالی را تغییر ندهید. کاربران و گروه‌ها باید در دامنه‌های انتقالی خود باقی بمانند.
   • اگر SSO را با استفاده از یک ارائه‌دهنده هویت شخص ثالث راه‌اندازی کنید و از یک صادرکننده خاص دامنه استفاده کنید، ادعای SAML تغییر می‌کند تا دامنه اصلی جدید را منعکس کند. پیکربندی ارائه‌دهنده هویت خود را بررسی کنید تا مطمئن شوید که کاربران می‌توانند پس از تعویض دامنه اصلی احراز هویت شوند. برای جزئیات بیشتر، به الزامات ادعای SSO مراجعه کنید.
4. قوانین نگهداری اطلاعات در گوگل والت را تعیین کنید - قوانین نگهداری سفارشی نامحدودی تنظیم کنید.

   برای برنامه‌های زیر یک قانون ایجاد کنید:

   • جیمیل — برای واحد سازمانی، واحد سازمانی ریشه را انتخاب کنید.
   • گروه‌های گوگل - برای گروه‌ها، همه گروه‌ها را انتخاب کنید.

   برای برنامه‌های زیر دو قانون ایجاد کنید:

   • چت — واحد سازمانی را انتخاب کنید واحد سازمانی ریشه. برای قانون دوم، همه فضاهای چت را انتخاب کنید.
   • درایو — واحد سازمانی را انتخاب کنید واحد سازمانی ریشه. برای قانون دوم، همه درایوهای مشترک را انتخاب کنید.
   • ملاقات — انتخاب واحد سازمانی واحد سازمانی ریشه را انتخاب کنید و گزینه «شامل موارد از درایوهای مشترک» را روشن کنید. برای قانون دوم، «همه درایوهای مشترک» را انتخاب کنید.
   • سایت‌ها - واحد سازمانی را انتخاب کنید واحد سازمانی ریشه را انتخاب کنید و گزینه «شامل موارد از درایوهای مشترک» را روشن کنید. برای قانون دوم، «همه درایوهای مشترک» را انتخاب کنید.

   علاوه بر این، قوانین نگهداری سفارشی نامحدود قبل از انتقال در محیط مقصد تنظیم می‌شوند. برای جزئیات بیشتر، به نگهداری نامحدود Google Vault در محیط مقصد مراجعه کنید. برای اطلاعات بیشتر در مورد انتقال از Vault، به Transfer your Vault data with domain transfer مراجعه کنید.

5. Back up Vault artifacts and remove references to transfer entities —Download and back up the Vault configurations and reports for the transfer entities, as they might not be accessible in the source environment after the transfer. This information includes matters, holds, searches, and exports.

   پس از پشتیبان‌گیری، ارجاعات به موجودیت‌های انتقال را از Google Vault Artifacts حذف کنید. Vault خطا می‌دهد و اگر هر یک از مصنوعات Vault حاوی ارجاعات به موجودیت‌های انتقال باشند، ممکن است قابل دسترسی نباشند.

   • نگهداری و حفاظت، مانع از عدم موفقیت در انتقال موجودیت‌ها نمی‌شود.
   • تمام ارجاعات به انتقال کاربران، انتقال گروه‌ها و انتقال درایوهای مشترک را از موارد، لیست‌های مشترک، انبارها و قوانین نگهداری حذف کنید. Vault به شما اجازه نمی‌دهد که یک انبار Vault در یک مستاجر داشته باشید که به موجودیتی در مستاجر دیگر ارجاع می‌دهد.
   • برای حفظ داده‌های کاربر انتقالی در مستأجر منبع، مدیران باید یک کاربر جدید بدون انتقال ایجاد کنند و تمام داده‌های Gmail و Drive را از کاربران انتقالی که در حالت انتظار هستند، به کاربر جدید کپی کنند. سپس، کاربران جدید بدون انتقال را بایگانی کنند و مطمئن شوند که به یک دامنه بدون انتقال تعلق دارند. در عوض، معادل Vault holds را برای کاربر جدید بدون انتقال ایجاد کنید و holds را برای کاربر انتقالی اصلی حذف کنید.
   • برای حفظ داده‌های کاربر در زمان انتقال در مستأجر مقصد، از پشتیبان‌ها برای اضافه کردن معادل‌های نگهداری در مستأجر مقصد پس از انتقال استفاده کنید.
   • لازم نیست ارجاعات غیرمستقیم را حذف کنید. ارجاعات غیرمستقیم مربوط به یک واحد سازمانی است که شامل یک کاربر انتقالی است.
   • لازم نیست ارجاعات را در جستجوها و خروجی‌های تکمیل‌شده حذف کنید. این ارجاعات دانلود می‌شوند.
6. به‌روزرسانی رکورد چارچوب سیاست فرستنده (SPF) خود (در صورت وجود) — اگر محیط مقصد از یک دروازه خروجی متفاوت از محیط منبع استفاده می‌کند، منبع باید رکورد SPF خود را به‌روزرسانی کند تا دروازه خروجی را نیز شامل شود.

   Note: If you're using DomainKeys Identified Mail (DKIM), the transfer shouldn't impact your Domain-based Message Authentication, Reporting, and Conformance (DMARC) policy. The SPF record will continue to align post transfer, even if DKIM temporarily does not. Also, make sure to complete the DKIM post-transfer task in the destination environment.

7. ارزیابی تأثیر بر سازمان مرتبط با Google Cloud (در صورت وجود) — اگر از Google Cloud استفاده می‌شود، مدیران آن محیط را در مورد تأثیرات احتمالی واگذاری انتقال دامنه Google Workspace بر Google Cloud مطلع کنید. در صورت لزوم، شریک Google Cloud یا مخاطبین خود در Google Cloud را برای کمک در ارزیابی تأثیرات و مراحل اصلاح درگیر کنید. تیم واگذاری انتقال دامنه Google Workspace در طول تعامل انتقال دامنه، کمکی به Google Cloud ارائه نمی‌دهد.
8. به نماینده فروش Google Workspace خود اطلاع دهید (در صورت وجود) — زمان انتقال دامنه برنامه‌ریزی شده را به آنها اطلاع دهید و از آنها بخواهید که در طول دوره انتقال، حساب کاربری (مثلاً به‌روزرسانی اشتراک‌ها) را تغییر ندهند.

9. ثبت نام در هر برنامه آلفا یا بتا که محیط مبدا یا مقصد در آن شرکت می‌کند (در صورت وجود) — ثبت نام‌های برنامه آلفا و بتا در محیط مبدا منتقل نمی‌شوند. به همین ترتیب، محیط مبدا ممکن است به ثبت نام‌ها در محیط مقصد بستگی داشته باشد. محیط ثبت نام نشده باید برای ادامه استفاده از آن برنامه‌ها، به آنها درخواست داده و در آنها پذیرفته شود.
   توصیه می‌کنیم قبل از انتقال، در برنامه‌های آلفا یا بتا ثبت‌نام کنید تا کاربران انتقالی شما در طول فرآیند انتقال از ویژگی‌های یکسانی برخوردار باشند. با این حال، فرآیند ثبت‌نام ممکن است مدتی طول بکشد و موفقیت تضمین نمی‌شود. بنابراین، توصیه می‌شود اما الزامی نیست.

10. برای انتقال دستگاه‌های ثبت‌نام‌شده بدون لمس کروم:
    1. در محیط مبدا، توکن پیش‌تأمین موجود را لغو کنید و دسترسی همه دستگاه‌ها را قطع کنید. دستگاه‌ها را به تنظیمات پیش‌فرض کارخانه برگردانید.
    2. در محیط مقصد، یک توکن پیش‌تأمین جدید ایجاد کنید.
    3. توکن جدید را به شریک مجاز خود در پیش‌تأمین (preprovisioning partner) ارائه دهید. شریک شما از این توکن برای پیش‌تأمین دستگاه‌ها در محیط مقصد استفاده می‌کند.

    دستگاه‌ها به محض اتصال به اینترنت، خود را ثبت می‌کنند. وضعیت دستگاه به Provisioned تغییر می‌کند.

    برای اطلاعات بیشتر در مورد دستگاه‌های بدون تماس، به ثبت نام بدون تماس مراجعه کنید.

11. Update group membership —Remove all transfer users and groups from nontransfer groups, and remove all nontransfer users and groups from transfer groups. For example, remove user@to-stay-insource.com and group@to-stay-insource.com from group@to-be-transfer.com.

    توجه: این مرحله اختیاری است زیرا می‌توانید به کاربران و گروه‌های خارجی در گروه‌های دیگر ارجاع دهید. پیامدهای مدیریت گروه‌ها را در حالی که یک مستاجر دیگر، گروه‌ها و کاربران عضو را مدیریت می‌کند، در نظر بگیرید.

12. حذف کاربران و گروه‌های انتقال از مخاطبان هدف — مخاطبان هدف منتقل نمی‌شوند، بنابراین مدیر مقصد پس از انتقال هیچ کنترلی بر مخاطبان هدف محیط مبدا ندارد.

    Note: This step is optional, as target audiences allow references to external users and groups. Users retain access to documents that were shared to target audiences.

13. به‌روزرسانی سیاست‌های مبتنی بر گروه — شما باید هرگونه سیاست مبتنی بر گروه را که به گروه‌های انتقال از مستأجر منبع ارجاع می‌دهند، حذف کنید.

    Important: If the source tenant contains group-based policies that reference transfer groups, the group-based policy disappears from the Admin Console, make it uneditable. It is still in effect for any nontransfer users in the transfer group, but you can't see or edit it. This is another reason to remove cross-tenant groups in step 12.

14. Set mobile device management to Basic —Deprovision mobile management for transfer users or set it to Basic.

15. دایرکتوری‌های سفارشی — یک مشکل شناخته‌شده در مورد دایرکتوری‌های سفارشی وجود دارد. دایرکتوری‌های سفارشی منتقل نمی‌شوند و شما باید قبل از انتقال، تمام گروه‌های انتقال را حذف کنید.

    مهم: اگر گروه‌های انتقال را حذف نکنید، دایرکتوری غیرقابل ویرایش و غیرقابل حذف می‌شود و ممکن است رفتار آن متناقض باشد.

16. به‌روزرسانی عضویت واحد سازمانی — مطمئن شوید که هیچ واحد سازمانی در محیط منبع، هم کاربر انتقالی و هم کاربر غیر انتقالی نداشته باشد. کاربران انتقالی و کاربران غیر انتقالی باید در واحدهای جداگانه باشند و نمی‌توانند در یک واحد در محیط منبع با هم ترکیب شوند.

17. به‌روزرسانی مجوز خودکار — برای واحدهای سازمانی که شامل کاربران انتقالی هستند، مطمئن شوید که پیکربندی مجوز خودکار خاموش است.

1. ایجاد یک محیط مقصد — واگذاری انتقال دامنه Google Workspace به طور خودکار یک محیط مقصد Google Workspace ایجاد نمی‌کند. شما باید از قبل یکی ایجاد کنید. حتماً صورتحساب را تنظیم کرده و نام دامنه اصلی را در محیط مقصد تأیید کنید.

2. مجوزها به عنوان بخشی از فرآیند انتقال منتقل نمی‌شوند، بنابراین شما باید مجوزهای اضافی Google Workspace کافی برای پشتیبانی از همه کاربران انتقالی فراهم کنید. — هنگام انتقال کاربران، همان مجموعه‌ای از مجوزها در محیط مقصد به آنها اختصاص داده می‌شود که در محیط مبدا داشتند. بنابراین، باید در زمان انتقال، مجوزهای اضافی کافی از همان نوع در محیط مقصد وجود داشته باشد.

   اگر محیط مقصد از نسخه Google Workspace متفاوتی نسبت به محیط منبع استفاده می‌کند، با ارتقاء مجوزها در محیط منبع یا مقصد، مطمئن شوید که مجوزها مطابقت دارند.

   یادداشت‌ها :

   • گوگل توصیه می‌کند برای جلوگیری از فعال شدن فرآیند حذف سرویس (SWP)، مجوزها را ارتقا دهید.
   • هرگونه لایسنس از دست رفته را فراهم کنید تا چندین اشتراک در محیط مقصد وجود داشته باشد. می‌توانید پس از انتقال، به صورت اختیاری لایسنس‌های تک تک کاربران را ارتقا یا تنزل دهید. توجه داشته باشید که همه انواع لایسنس از مجوز دامنه جزئی (PDL) پشتیبانی نمی‌کنند.
   • مطمئن شوید که مجوزهای یدکی کافی در محیط مقصد موجود است. در نظر بگیرید که آیا کاربران بیشتری (مثلاً استخدام‌های جدید) بین شروع و پایان فرآیند انتقال به هر محیط مبدا اضافه می‌شوند یا خیر. اگر چندین انتقال وجود دارد، باید تعداد کل کاربران مبدا را در تمام انتقال‌ها نیز در نظر بگیرید.
   • کاربرانی که در محیط مبدا هیچ مجوزی به آنها اختصاص داده نشده است، همچنان می‌توانند منتقل شوند. نحوه تخصیص خودکار مجوزها در محیط مقصد را بررسی کنید تا مطمئن شوید که این کاربران مجوزی دریافت نمی‌کنند.
   • انتقال دامنه، طرح‌های صورتحساب ویژه Google Workspace را برای تطبیق با خرید مجوزهای اضافی در طول انتقال ارائه نمی‌دهد. اگر مجوزهای محیط مبدا تحت یک طرح صورتحساب سالانه باشند، تا پایان قرارداد طرح سالانه شما فعال می‌مانند و صورتحساب آنها صادر می‌شود. در صورت داشتن سوالات بیشتر در مورد طرح‌های صورتحساب Google Workspace، با نماینده فروش یا مدیر حساب خود مشورت کنید.

3. اطمینان حاصل کنید که مجوزها به درستی برای کاربران انتقالی اعمال می‌شوند، زمانی که چندین مجوز وجود دارد - برخی از پیکربندی‌ها در محیط مقصد ممکن است بر نحوه تخصیص مجوزها به کاربران انتقالی تأثیر بگذارند. این وضعیت ممکن است منجر به این شود که کاربران انتقالی در نهایت مجوزی متفاوت از آنچه انتظار می‌رود دریافت کنند. این پیکربندی‌ها شامل مجوز خودکار و لغو مجوز خودکار برای سازمان‌های خاص است.

   برای اطمینان از اینکه هیچ تغییر غیرمنتظره‌ای در مجوزها در طول انتقال رخ نمی‌دهد، باید اقدامات زیر را اعمال کنید:

   • اگر پیکربندی مجوز خودکار محیط مقصد «برای همه غیرفعال» باشد یا اگر محیط مقصد فقط یک نوع مجوز واحد داشته باشد، نیازی به تغییر نیست.
   • اگر پیکربندی مجوز خودکار محیط مقصد «برای همه روشن» است (برای مثال، مجوزهای Google Workspace)، مطمئن شوید که لغو مجوز برای واحدهای سازمانی خاص روشن است. برای واحد سازمانی ریشه انتقال، مطمئن شوید که پیکربندی مجوز خودکار خاموش است و هیچ لغو مجوز دیگری برای واحدهای سازمانی فرزند انجام نمی‌شود.

4. Create the transfer root organizational unit and, optionally, re-create the source environment organizational unit structure —Create an organizational unit to serve as the parent organizational unit for all transfer users. Once created, you have 2 options:

   • هیچ کاری انجام ندهید — فرآیند انتقال دامنه، ساختار واحد سازمانی را از محیط منبع تحت واحد سازمانی ریشه انتقال جدید بازسازی می‌کند. برای انجام این مرحله، گزینه انتقال "ساختار واحد سازمانی را از قبل بازسازی کنید" را روی خیر تنظیم کنید. همه کاربران انتقال ورودی، سیاست‌هایی را که شما در سطح واحد سازمانی اعمال می‌کنید، به ارث می‌برند.
   • Manually re-create the source environment organizational unit structure under the transfer root organizational unit —Domain transfer ensures that the source environment's entire organizational unit structure is properly replicated before proceeding with the transfer. To do this step, set the transfer option "recreate the organizational unit structure in advance" to Yes. This option is useful if you want to set distinct policies on different child organizational units.

     توجه : انتقال دامنه فقط ساختار واحد سازمانی را تأیید می‌کند. این مسئولیت شماست که مطمئن شوید سیاست‌های مناسب روی واحدهای سازمانی تنظیم شده‌اند.

5. سیاست‌ها و تنظیمات مناسب را برای انعکاس الزامات محیط مبدا و مقصد ایجاد کنید. سیاست‌ها و تنظیمات محیط مبدا به محیط مقصد منتقل نمی‌شوند. علاوه بر این، پس از اتمام فرآیند انتقال، فقط سیاست‌ها و تنظیمات محیط مقصد برای انتقال کاربران و داده‌های آنها اعمال می‌شود.

   شما باید سیاست‌ها و تنظیمات خود را در محیط مقصد بررسی کرده و آنها را با محیط مبدا مقایسه کنید. این اقدام شامل تنظیمات عمومی و اختصاصی برای واحد سازمانی ریشه انتقال است تا مطمئن شوید که همه موجودیت‌ها و کاربران انتقال ورودی را پوشش می‌دهند.

   در زیر لیستی غیر جامع از سیاست‌ها و تنظیماتی که باید به عنوان بخشی از فرآیند راه‌اندازی تأیید کنید، آمده است. همچنین، یک ممیزی کامل از هر دو محیط انجام دهید تا مطمئن شوید که تمام بخش‌های مربوطه تجزیه و تحلیل شده‌اند:

   • فعال‌سازی سرویس (روشن/خاموش) — تأیید کنید که سرویس‌هایی که در محیط مبدا استفاده می‌کنید، در محیط مقصد نیز فعال باشند و واحد سازمانی ریشه انتقال مطابق انتظار رفتار کند. این امر به ویژه هنگام استفاده از Google Vault اهمیت دارد، زیرا در صورت خاموش بودن سرویس، ممکن است قوانین Vault اعمال نشوند.
   • Gmail, advanced settings, and MX records —Review settings such as mail routing, compliance rules, and IMAP enablement and delegation. For details, go to Activate Gmail with Google Workspace .
   • مدیریت رمز عبور — سیاست‌های رمز عبور خود را بررسی کنید تا مطمئن شوید که با رویه‌های سازمان شما همسو هستند. پس از انتقال کاربران به محیط مقصد، سیاست‌های مدیریت رمز عبور در محیط مقصد را به ارث می‌برند.
   • 2-Step Verification —Controls whether users are allowed to add a 2-Step Verification configuration to their account, whether it's allowed or it's enforced. If transfer users with 2-Step Verification turned on are transferred into a destination environment or organizational unit where 2-Step Verification is turned off, destination administrators will be unable to manage them. Instead, admins can either move these users to a different organizational unit where 2-Step Verification is turned on to make changes, or they can remove 2-Step Verification from accounts before the transfer.
   • Sharing settings —Controls whether users can share their content outside the organization. If the source environment blocks sharing and the destination environment does not, then transfer content might be accessible outside your organization. If the source environment has open sharing by default and the destination environment does not, then transfer content might be inaccessible to users in your organization. Learn more about sharing options for Google Drive and Google Calendar .
   • Data loss prevention (DLP) rules —Monitors and prevents users from sharing sensitive information outside your organization. When DLP prevents users from sharing information in the source environment, and content is transferred into a destination environment without DLP setup, users in the destination environment can share information outside your organization. Learn more about Gmail DLP rules and Drive DLP rules .
   • Chat history —Controls whether chat history is on or off the record, and whether users can set enforcement on all chats or make it the default. If the source environment allows for chat history to be turned on, but the destination environment forces it to be off, then chat history is lost. While Google Chat is listed as unsupported for the transfer, direct messages (DMs) will transfer.
   • Data countries/regions —Controls which specific geographic location to store your migrated data. Transfer users that need to stay in a specific geographic location must have this policy set appropriately in the destination environment to make sure their data does not unexpectedly leave their required data country/region. For details, go to Data regions: Choose a geographic location for your data .
   • برنامه‌های با امنیت کمتر (که با نام رمزهای عبور برنامه نیز شناخته می‌شوند) — اگر برنامه‌های با امنیت کمتر در محیط مبدا فعال و در محیط مقصد غیرفعال باشند، اتصال با برنامه‌ای که از برنامه‌های با امنیت کمتر استفاده می‌کند، دچار وقفه و بسته شدن می‌شود. دوره‌های وقفه بسته به برنامه متفاوت است، اما معمولاً ظرف ۶۰ دقیقه منقضی می‌شوند. درخواست‌های دسترسی آینده توسط برنامه ناامن مسدود می‌شوند. برای جزئیات بیشتر، به کنترل دسترسی به برنامه‌های با امنیت کمتر مراجعه کنید.
   • OAuth scopes, single sign-on (SSO) for SAML, trusted apps, and Chrome extensions —OAuth controls determine the level of API access allowed to users and third-party applications. SSO for SAML, whether supplied by Google Workspace or implemented as a custom application, allows users to leverage their Google Workspace credentials to access other applications or services. Trusted apps determine the applications users can install from the Google Workspace Marketplace or Chrome Web Store and which apps are allowed to bypass OAuth restrictions. Learn more about how to control third-party & internal apps , SAML SSO , Google Workspace Marketplace apps , and Chrome apps and extensions .
   • واگذاری در سطح دامنه — به برنامه‌ها اجازه می‌دهد تا به داده‌های Google Workspace کاربران دسترسی داشته باشند. برای اطمینان از عملکرد صحیح کلاینت‌ها و محدوده‌ها، قبل از انتقال، واگذاری در سطح دامنه را در محیط مقصد تنظیم کنید.

   مهم : عدم توانایی در ایجاد صحیح سیاست‌ها و تنظیمات ممکن است منجر به موارد زیر شود:

   • قرار گرفتن ناخواسته داده‌های شما در خارج از سازمان (برای مثال، محیط مقصد تنظیمات بازتری نسبت به محیط منبع دارد)
   • دسترسی محدود به داده‌هایی که قبلاً قابل دسترسی بوده‌اند (برای مثال، محیط مقصد تنظیمات محدودتری نسبت به محیط منبع دارد)
6. Accept agreements that govern transferred data —Review the Data Processing Amendment (DPA), model contract clause, and HIPAA Business Associate Amendment (BAA) in the destination environment. For details, go to Privacy compliance and records for Google Workspace and Cloud Identity .
7. اگر Vault در محیط مبدأ استفاده می‌شود، آن را روشن کنید — اگر محیط مقصد از Vault استفاده نمی‌کند اما محیط مبدأ از آن استفاده می‌کند، محیط مقصد باید Vault را روشن کند.
8. به نماینده فروش Google Workspace خود اطلاع دهید (در صورت وجود) — زمان انتقال دامنه برنامه‌ریزی شده را به آنها اطلاع دهید و از آنها بخواهید که در طول دوره انتقال، حساب کاربری (مثلاً به‌روزرسانی اشتراک‌ها) را تغییر ندهند.

9. ثبت نام در هر برنامه آلفا یا بتا که محیط مبدا یا مقصد در آن شرکت می‌کند (در صورت وجود) — ثبت نام‌های برنامه آلفا و بتا در محیط مبدا منتقل نمی‌شوند. به همین ترتیب، محیط مبدا ممکن است به ثبت نام‌ها در محیط مقصد بستگی داشته باشد. محیط ثبت نام نشده باید برای ادامه استفاده از آن برنامه‌ها، به آنها درخواست داده و در آنها پذیرفته شود.
   توصیه می‌کنیم قبل از انتقال، در برنامه‌های آلفا یا بتا ثبت‌نام کنید تا کاربران انتقالی شما در طول فرآیند انتقال از ویژگی‌های یکسانی برخوردار باشند. با این حال، فرآیند ثبت‌نام ممکن است مدتی طول بکشد و موفقیت تضمین نمی‌شود. بنابراین، توصیه می‌شود اما الزامی نیست.

مهم :

• Downgrading licenses might cause a loss in Google Workspace services and functionality. Carefully review the differences between Google Workspace editions and the impact of both upgrading and downgrading before making any changes. Learn more about Google Workspace editions .
• تنزل رتبه مجوزها ممکن است باعث فعال شدن SWP شود که می‌تواند انتقال را تا ۹۰ روز به تأخیر بیندازد.

• Change management —Both the Google Workspace Domain Transfer team or the transfer process do not automatically provide users with information on the transfer's execution during the transfer process. It's highly recommended that source and destination environment representatives inform users of the transfer process, and its potential impacts, in advance.

  تمام اقدامات مدیر در هر دو محیط مبدا و مقصد در طول انتقال مسدود می‌شود، از جمله دسترسی به API و کنسول مدیریت گوگل. اکیداً توصیه می‌شود که نمایندگان محیط مبدا و مقصد قبل از انتقال و پس از اتمام آن، به همه مدیران ارشد دامنه و مدیران واگذار شده اطلاع دهند.

• External dependencies —If you use Google Cloud Directory Sync (GCDS), GAM (a third-party command-line tool for Google Workspace administrators to manage domain and user settings), or a third-party single sign-on (SSO) provider, make sure to analyze the effect of the transfer. Also examine how having the source and destination environments coexisting in a single environment affects your system and the timing of your transfer execution.

Google Workspace Domain Transfer Divestiture sets up indefinite custom retention rules in the destination environment. No action is required by destination environment admins.

بایگانی Vault برای کاربران انتقالی منتقل می‌شود، اما قوانین نگهداری Vault از محیط مبدا منتقل نمی‌شوند. برای اطمینان از اینکه هیچ داده Vault در حین و پس از انتقال در معرض خطر قرار نمی‌گیرد، فرآیند انتقال قبل از اجرای هرگونه اقدام انتقال، قوانین نگهداری Vault زیر را در محیط مقصد ایجاد می‌کند:

• Gmail - قانون نگهداری سفارشی نامحدود (محدوده: انتقال واحد سازمانی ریشه).
• تقویم گوگل - قانون حفظ سفارشی نامحدود (محدوده: انتقال واحد سازمانی ریشه).
• گوگل چت - قانون نگهداری سفارشی نامحدود (محدوده: پیام‌های مستقیم با کاربران انتقالی در واحد سازمانی ریشه انتقال، اما نه در Spaces).
• گوگل درایو - قانون نگهداری سفارشی نامحدود، شامل درایوهای اشتراکی نمی‌شود (محدوده: انتقال واحد سازمانی ریشه).
• گروه‌های گوگل - قانون نگهداری سفارشی نامحدود (محدوده: واحد سازمانی ریشه). داده‌ها را برای همه گروه‌های موجود در محیط مقصد، از جمله گروه‌هایی که در فرآیند انتقال گنجانده نشده‌اند، نگهداری می‌کند.
• گوگل میت - به دو قانون حفظ سفارشی نامحدود نیاز دارد:
  1. شامل درایوهای مشترک نمی‌شود (محدوده: انتقال واحد سازمانی ریشه).
  2. شامل تمام درایوهای مشترک (محدوده: واحد سازمانی ریشه).

     داده‌های مربوط به تمام درایوهای مشترک در محیط مقصد، از جمله آن‌هایی که در فرآیند انتقال لحاظ نشده‌اند، را حفظ می‌کند.

• سایت‌های گوگل - به ۲ قانون نگهداری سفارشی نامحدود نیاز دارد.
  1. شامل درایوهای مشترک نمی‌شود (محدوده: انتقال واحد سازمانی ریشه).
  2. شامل تمام درایوهای مشترک (محدوده: واحد سازمانی ریشه).

     داده‌های مربوط به تمام درایوهای مشترک در محیط مقصد، از جمله آن‌هایی که در فرآیند انتقال لحاظ نشده‌اند، را حفظ می‌کند.

• درایوهای اشتراکی — قانون نگهداری سفارشی نامحدود روی تمام درایوهای اشتراکی (محدوده: واحد سازمانی ریشه). داده‌ها را برای تمام درایوهای اشتراکی در محیط مقصد، از جمله آن‌هایی که در فرآیند انتقال گنجانده نشده‌اند، نگهداری می‌کند.

مهم : قوانین نگهداری اطلاعات در محیط مقصد در طول فرآیند انتقال حذف یا اصلاح نمی‌شوند، زیرا انجام این کار می‌تواند به طور بالقوه باعث از دست رفتن غیرقابل برگشت داده‌ها شود.