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

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. پشتیبان‌گیری از مصنوعات Vault و حذف ارجاعات به موجودیت‌های انتقالی — پیکربندی‌ها و گزارش‌های Vault را برای موجودیت‌های انتقالی دانلود و پشتیبان‌گیری کنید، زیرا ممکن است پس از انتقال در محیط منبع قابل دسترسی نباشند. این اطلاعات شامل موارد، نگهداری‌ها، جستجوها و صادرات می‌شود.

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

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

   توجه: اگر از DomainKeys Identified Mail (DKIM) استفاده می‌کنید، انتقال نباید روی سیاست Domain-based Message Authentication, Reporting, and Conformance (DMARC) شما تأثیر بگذارد. رکورد SPF به هماهنگ‌سازی پس از انتقال ادامه خواهد داد، حتی اگر DKIM موقتاً این کار را انجام ندهد. همچنین، مطمئن شوید که وظیفه پس از انتقال DKIM را در محیط مقصد انجام داده‌اید.

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. به‌روزرسانی عضویت گروه — تمام کاربران و گروه‌های انتقالی را از گروه‌های غیرقابل انتقال حذف کنید، و تمام کاربران و گروه‌های غیرقابل انتقال را از گروه‌های انتقالی حذف کنید. برای مثال، user@to-stay-insource.com و group@to-stay-insource.com را از group@to-be-transfer.com حذف کنید.

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

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

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

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

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

14. مدیریت دستگاه تلفن همراه را روی حالت پایه تنظیم کنید — مدیریت تلفن همراه را برای کاربران انتقالی غیرفعال کنید یا آن را روی حالت پایه تنظیم کنید.

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

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

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

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

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

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

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

   یادداشت‌ها :

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

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

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

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

4. واحد سازمانی ریشه انتقال را ایجاد کنید و در صورت تمایل، ساختار واحد سازمانی محیط منبع را دوباره ایجاد کنید — یک واحد سازمانی ایجاد کنید تا به عنوان واحد سازمانی والد برای همه کاربران انتقالی عمل کند. پس از ایجاد، دو گزینه دارید:

   • هیچ کاری انجام ندهید — فرآیند انتقال دامنه، ساختار واحد سازمانی را از محیط منبع تحت واحد سازمانی ریشه انتقال جدید بازسازی می‌کند. برای انجام این مرحله، گزینه انتقال "ساختار واحد سازمانی را از قبل بازسازی کنید" را روی خیر تنظیم کنید. همه کاربران انتقال ورودی، سیاست‌هایی را که شما در سطح واحد سازمانی اعمال می‌کنید، به ارث می‌برند.
   • ساختار واحد سازمانی محیط مبدا را به صورت دستی تحت واحد سازمانی ریشه انتقال، دوباره ایجاد کنید — انتقال دامنه تضمین می‌کند که کل ساختار واحد سازمانی محیط مبدا قبل از ادامه انتقال به درستی تکرار شود. برای انجام این مرحله، گزینه انتقال "ساختار واحد سازمانی را از قبل بازسازی کنید" را روی بله تنظیم کنید. این گزینه در صورتی مفید است که بخواهید سیاست‌های متمایزی را روی واحدهای سازمانی فرزند مختلف تنظیم کنید.

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

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

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

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

   • فعال‌سازی سرویس (روشن/خاموش) — تأیید کنید که سرویس‌هایی که در محیط مبدا استفاده می‌کنید، در محیط مقصد نیز فعال باشند و واحد سازمانی ریشه انتقال مطابق انتظار رفتار کند. این امر به ویژه هنگام استفاده از Google Vault اهمیت دارد، زیرا در صورت خاموش بودن سرویس، ممکن است قوانین Vault اعمال نشوند.
   • جیمیل، تنظیمات پیشرفته و رکوردهای MX — تنظیماتی مانند مسیریابی ایمیل، قوانین انطباق و فعال‌سازی و واگذاری IMAP را بررسی کنید. برای جزئیات بیشتر، به فعال‌سازی جیمیل با Google Workspace بروید.
   • مدیریت رمز عبور — سیاست‌های رمز عبور خود را بررسی کنید تا مطمئن شوید که با رویه‌های سازمان شما همسو هستند. پس از انتقال کاربران به محیط مقصد، سیاست‌های مدیریت رمز عبور در محیط مقصد را به ارث می‌برند.
   • تأیید دو مرحله‌ای — کنترل می‌کند که آیا کاربران مجاز به اضافه کردن پیکربندی تأیید دو مرحله‌ای به حساب خود هستند یا خیر، چه مجاز باشد و چه اجباری. اگر کاربران انتقالی که تأیید دو مرحله‌ای آنها فعال است به محیط یا واحد سازمانی مقصدی منتقل شوند که تأیید دو مرحله‌ای در آن غیرفعال است، مدیران مقصد قادر به مدیریت آنها نخواهند بود. در عوض، مدیران می‌توانند این کاربران را برای ایجاد تغییرات به واحد سازمانی دیگری که تأیید دو مرحله‌ای در آن فعال است منتقل کنند، یا می‌توانند تأیید دو مرحله‌ای را قبل از انتقال از حساب‌ها حذف کنند.
   • تنظیمات اشتراک‌گذاری —کنترل می‌کند که آیا کاربران می‌توانند محتوای خود را در خارج از سازمان به اشتراک بگذارند یا خیر. اگر محیط مبدا اشتراک‌گذاری را مسدود کند و محیط مقصد این کار را نکند، ممکن است محتوای انتقالی در خارج از سازمان شما قابل دسترسی باشد. اگر محیط مبدا به طور پیش‌فرض اشتراک‌گذاری آزاد داشته باشد و محیط مقصد این کار را نکند، ممکن است محتوای انتقالی برای کاربران سازمان شما غیرقابل دسترس باشد. درباره گزینه‌های اشتراک‌گذاری برای Google Drive و Google Calendar بیشتر بدانید.
   • قوانین پیشگیری از نشت داده‌ها (DLP) — نظارت و جلوگیری از به اشتراک گذاشتن اطلاعات حساس توسط کاربران در خارج از سازمان شما. هنگامی که DLP از به اشتراک گذاشتن اطلاعات توسط کاربران در محیط مبدا جلوگیری می‌کند و محتوا بدون تنظیمات DLP به محیط مقصد منتقل می‌شود، کاربران در محیط مقصد می‌توانند اطلاعات را در خارج از سازمان شما به اشتراک بگذارند. درباره قوانین Gmail DLP و Drive DLP بیشتر بدانید.
   • تاریخچه چت — کنترل می‌کند که آیا تاریخچه چت فعال باشد یا غیرفعال، و اینکه آیا کاربران می‌توانند برای همه چت‌ها محدودیت اعمال کنند یا آن را پیش‌فرض قرار دهند. اگر محیط مبدا اجازه فعال کردن تاریخچه چت را بدهد، اما محیط مقصد آن را غیرفعال کند، تاریخچه چت از بین می‌رود. در حالی که گوگل چت برای انتقال پشتیبانی نمی‌شود، پیام‌های مستقیم (DM) منتقل می‌شوند.
   • کشورها/مناطق داده — کنترل می‌کند که کدام موقعیت جغرافیایی خاص برای ذخیره داده‌های منتقل‌شده شما در نظر گرفته شود. کاربران انتقالی که نیاز به ماندن در یک موقعیت جغرافیایی خاص دارند، باید این خط‌مشی را به طور مناسب در محیط مقصد تنظیم کنند تا مطمئن شوند داده‌های آنها به طور غیرمنتظره از کشور/منطقه داده مورد نیازشان خارج نمی‌شود. برای جزئیات بیشتر، به مناطق داده بروید: یک موقعیت جغرافیایی برای داده‌های خود انتخاب کنید .
   • برنامه‌های با امنیت کمتر (که با نام رمزهای عبور برنامه نیز شناخته می‌شوند) — اگر برنامه‌های با امنیت کمتر در محیط مبدا فعال و در محیط مقصد غیرفعال باشند، اتصال با برنامه‌ای که از برنامه‌های با امنیت کمتر استفاده می‌کند، دچار وقفه و بسته شدن می‌شود. دوره‌های وقفه بسته به برنامه متفاوت است، اما معمولاً ظرف ۶۰ دقیقه منقضی می‌شوند. درخواست‌های دسترسی آینده توسط برنامه ناامن مسدود می‌شوند. برای جزئیات بیشتر، به کنترل دسترسی به برنامه‌های با امنیت کمتر مراجعه کنید.
   • دامنه‌های OAuth، ورود یکپارچه (SSO) برای SAML، برنامه‌های قابل اعتماد و افزونه‌های Chrome - کنترل‌های OAuth سطح دسترسی API مجاز برای کاربران و برنامه‌های شخص ثالث را تعیین می‌کنند. SSO برای SAML، چه توسط Google Workspace ارائه شده باشد و چه به عنوان یک برنامه سفارشی پیاده‌سازی شده باشد، به کاربران اجازه می‌دهد تا از اعتبارنامه‌های Google Workspace خود برای دسترسی به سایر برنامه‌ها یا خدمات استفاده کنند. برنامه‌های قابل اعتماد، برنامه‌هایی را که کاربران می‌توانند از Google Workspace Marketplace یا Chrome Web Store نصب کنند و اینکه کدام برنامه‌ها مجاز به دور زدن محدودیت‌های OAuth هستند، تعیین می‌کنند. درباره نحوه کنترل برنامه‌های شخص ثالث و داخلی ، SAML SSO ، برنامه‌های Google Workspace Marketplace و برنامه‌ها و افزونه‌های Chrome بیشتر بدانید.
   • واگذاری در سطح دامنه — به برنامه‌ها اجازه می‌دهد تا به داده‌های Google Workspace کاربران دسترسی داشته باشند. برای اطمینان از عملکرد صحیح کلاینت‌ها و محدوده‌ها، قبل از انتقال، واگذاری در سطح دامنه را در محیط مقصد تنظیم کنید.

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

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

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

مهم :

• تنزل رتبه مجوزها ممکن است باعث از دست رفتن خدمات و قابلیت‌های Google Workspace شود. قبل از ایجاد هرگونه تغییر، تفاوت‌های بین نسخه‌های Google Workspace و تأثیر ارتقا و تنزل رتبه را با دقت بررسی کنید. درباره نسخه‌های Google Workspace بیشتر بدانید.
• تنزل رتبه مجوزها ممکن است SWP را فعال کند، که می‌تواند انتقال را تا ۹۰ روز به تأخیر بیندازد.

• مدیریت تغییر — نه تیم انتقال دامنه Google Workspace و نه فرآیند انتقال، به طور خودکار اطلاعاتی در مورد اجرای انتقال در طول فرآیند انتقال در اختیار کاربران قرار نمی‌دهند. اکیداً توصیه می‌شود که نمایندگان محیط مبدا و مقصد، کاربران را از قبل در مورد فرآیند انتقال و تأثیرات احتمالی آن مطلع کنند.

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

• وابستگی‌های خارجی — اگر از Google Cloud Directory Sync (GCDS)، GAM (یک ابزار خط فرمان شخص ثالث برای مدیران Google Workspace جهت مدیریت تنظیمات دامنه و کاربر) یا یک ارائه‌دهنده‌ی ورود یکپارچه (SSO) شخص ثالث استفاده می‌کنید، حتماً تأثیر انتقال را تجزیه و تحلیل کنید. همچنین بررسی کنید که چگونه وجود همزمان محیط‌های مبدأ و مقصد در یک محیط واحد، بر سیستم شما و زمان اجرای انتقال شما تأثیر می‌گذارد.

واگذاری انتقال دامنه Google Workspace قوانین نگهداری سفارشی نامحدودی را در محیط مقصد تنظیم می‌کند. هیچ اقدامی از سوی مدیران محیط مقصد لازم نیست.

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

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

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

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

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

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

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