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

مرحله ۱: وظایف منبع

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

   یادداشت‌ها:

   • برای جلوگیری از هزینه‌ها، می‌توانید از مجوزهای موقت یا آزمایشی در محیط منبع برای تهیه مجوز موقت استفاده کنید. با این حال، به نکات زیر توجه داشته باشید:
     • این مجوزها فرآیند تعویض هر دامنه دیگری با دامنه اصلی را مسدود می‌کنند. قبل از ارائه هرگونه مجوز موقت، دامنه اصلی را تغییر دهید.
     • اگر مجوزهای موجود در محیط مقصد، مجوزهای کامل باشند، در نتیجه انتقال، به کاربران مجوزهای کامل اختصاص داده می‌شود.
   • کاربرانی که در محیط منبع هستند و هیچ مجوزی به آنها اختصاص داده نشده است، همچنان می‌توانند مجوز خود را منتقل کنند.
2. لغو اشتراک‌های مجوز پشتیبانی نشده — لغو اشتراک‌های مجوز ممکن است پیامدهایی داشته باشد. محیط‌های منبع با Google Voice باید به این مرحله توجه بیشتری داشته باشند. برای جزئیات بیشتر، به مجوزهای منبع مراجعه کنید.
3. اضافه کردن یک دامنه جایگزین به Google Workspace (در صورت وجود) — یک نام دامنه ثانویه جدید در محیط منبع اضافه کنید و تأیید کنید که در نهایت جایگزین دامنه اصلی موجود خواهد شد. اگر دامنه ثانویه وجود دارد و نیازی به انتقال آن نیست، می‌توانید از آن استفاده کنید. برای جزئیات بیشتر، به افزودن دامنه مستعار کاربر یا دامنه ثانویه بروید.
4. یک مدیر جاساز ایجاد کنید و آن را به عنوان مدیر اصلی حساب کاربری تعیین کنید — یک حساب کاربری مرتبط با دامنه جاساز ایجاد کنید. اگر یک حساب کاربری قدیمی را تغییر کاربری می‌دهید، مطمئن شوید که هیچ دامنه انتقالی دیگری به عنوان نام مستعار به حساب کاربری متصل نشده باشد. به این کاربر نقش مدیر ارشد را اعطا کنید و او را به عنوان مدیر اصلی حساب کاربری تعیین کنید. برای اطلاعات بیشتر، به بخش ارسال اعلان‌های صورتحساب و حساب به یک مدیر دیگر مراجعه کنید. مطمئن شوید که تأیید صحت دو مرحله‌ای گوگل (Google 2-Step Verification) تنظیم شده است و حداقل یک بار برای تأیید دسترسی با حساب مدیر جاساز، وارد سیستم شوید.
5. دامنه اصلی را با دامنه جایگزین تعویض کنید — یک تعویض دامنه انجام دهید و دامنه جایگزین را به عنوان دامنه اصلی جدید ارتقا دهید.

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

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

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

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

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

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

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

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

7. به‌روزرسانی رکورد چارچوب سیاست فرستنده (SPF) خود (در صورت وجود) — اگر محیط مقصد از یک دروازه خروجی متفاوت از محیط منبع استفاده می‌کند، منبع باید رکورد SPF خود را به‌روزرسانی کند تا دروازه خروجی را نیز شامل شود.

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

8. حل تداخل منابع تقویم — اگر تداخل منابع تقویم وجود دارد، قبل از ادامه کار آنها را حل کنید:
   • شناسه‌های ساختمان — شناسه ساختمان در محیط مبدا نمی‌تواند با شناسه ساختمان در محیط مقصد یکسان باشد. برای دور زدن بلوک انتقال، دو گزینه دارید. می‌توانید ساختمان را در محیط مبدا حذف کنید. یا می‌توانید جزئیات دو ساختمان را یکسان کنید تا ساختمان‌های مبدا و مقصد ادغام شوند. برای یکسان کردن دو ساختمان، شناسه، نام، تمام فیلدهای آدرس، توضیحات و طبقه را برای هر دو ساختمان دقیقاً یکسان کنید.
   • نام ساختمان‌ها — اگر یک منبع ساختمان در محیط مبدا نامی مشابه با یک منبع ساختمان در محیط مقصد داشته باشد، برای حل این تداخل باید نام یکی از منابع را تغییر دهید. پس از اتمام فرآیند انتقال، می‌توانید دو منبع ساختمان را با هم ادغام کنید.
   • شناسه‌های منبع — منبعی در محیط مبدأ که شناسه منبع یکسانی با منبعی در محیط مقصد دارد، تداخلی ایجاد می‌کند که با فرآیند انتقال قابل حل نیست و منبع منتقل نمی‌شود. یکی از منابع تداخل‌دار را حذف کنید و آن را با شناسه‌ای بدون تداخل دوباره ایجاد کنید. 30 روز طول می‌کشد تا یک منبع حذف شده به طور کامل از سیستم پاک شود. می‌توانید منتظر بمانید تا منبع به طور کامل حذف شود، یا تیم انتقال دامنه می‌تواند درخواستی برای حذف دستی آن ارسال کند.
9. ارزیابی تأثیر بر سازمان مرتبط با Google Cloud (در صورت وجود) — اگر از Google Cloud استفاده می‌شود، مدیران آن محیط را در مورد تأثیرات احتمالی Google Workspace Domain Transfer بر Google Cloud مطلع کنید. در صورت لزوم، شریک Google Cloud یا مخاطبین خود در Google Cloud را برای کمک در ارزیابی تأثیرات و مراحل اصلاح درگیر کنید. تیم Google Workspace Domain Transfer در طول فرآیند انتقال دامنه، کمکی به Google Cloud ارائه نمی‌دهد.
10. به نماینده فروش Google Workspace خود اطلاع دهید (در صورت وجود) — زمان انتقال دامنه برنامه‌ریزی شده را به آنها اطلاع دهید و از آنها بخواهید که در طول دوره انتقال، حساب کاربری (مثلاً به‌روزرسانی اشتراک‌ها) را تغییر ندهند.

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

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

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

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

مرحله ۲: وظایف مقصد

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

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

   یادداشت‌ها :

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

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

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

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

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

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

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

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

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

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

   • فعال‌سازی سرویس (روشن/خاموش) — تأیید کنید که سرویس‌هایی که در محیط مبدا استفاده می‌کنید، در محیط مقصد نیز فعال باشند و واحد سازمانی ریشه انتقال مطابق انتظار رفتار کند. این امر به ویژه هنگام استفاده از 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 کاربران دسترسی داشته باشند. برای اطمینان از عملکرد صحیح کلاینت‌ها و محدوده‌ها، قبل از انتقال، واگذاری در سطح دامنه را در محیط مقصد تنظیم کنید.

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

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

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

مهم :

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

مرحله ۳: سایر وظایف و ملاحظات

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

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

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

نگهداری نامحدود Google Vault در محیط مقصد

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

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

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

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

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

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

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

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