5. השלמת משימות לפני ההעברה

1. שדרוג רישיונות (אם רלוונטי) – הרישיונות לא מועברים כחלק מתהליך ההעברה. אם סביבת המקור משתמשת במהדורת Google Workspace שונה מזו של סביבת היעד, צריך לשדרג את המקור כך שיתאים ליעד. מידע נוסף זמין בקטע בנושא העברת רישיונות משימות של סביבת היעד.

   הערות:

   • אתם יכולים להשתמש ברישיונות חסד או ברישיונות ניסיון בסביבת המקור כדי לרכוש רישיונות זמניים ולחסוך בעלויות. עם זאת, חשוב לזכור את הנקודות הבאות:
     • הרישיונות האלה חוסמים את תהליך ההחלפה של כל דומיין אחר בדומיין הראשי. לפני שמקצים רישיונות זמניים, צריך לשנות את הדומיין הראשי.
     • אם הרישיונות שזמינים בסביבת היעד הם רישיונות מלאים, למשתמשים מוקצים רישיונות מלאים כתוצאה מההעברה.
   • גם משתמשים בסביבת המקור שלא הוקצו להם רישיונות מועברים.
2. ביטול מינויים לרישיונות שלא נתמכים – במקרים מסוימים, צריך להסיר רישיונות שלא נתמכים מהמשתמשים להעברה, אבל משתמשים שלא מועברים יכולים לשמור על הרישיונות שלהם. אחרת, עליך לבטל או להסיר לחלוטין את כל הרישיונות שלא נתמכים. ההרצה היבשה מאמתת אילו רישיונות צריך לבטל.

   צריך לבטל את Google Voice לכל המשתמשים. לביטול מינויים לרישיונות יכולות להיות השלכות. בסביבות מקור שבהן נעשה שימוש ב-Google Voice, חשוב לשים לב לשלב הזה. פרטים נוספים זמינים במאמר בנושא רישיונות במקור.

3. הקצאת דומיין ראשי חדש אם רוצים להעביר את הדומיין הראשי הנוכחי – השלב הזה נדרש רק אם רוצים להעביר את הדומיין הראשי הנוכחי. מבצעים החלפת דומיין, ומקדמים דומיין אחר כדומיין הראשי החדש .כל דומיין שלא ניתן להעברה יכול להיות דומיין ראשי למטרה הזו.

   לפני שמחליפים את הדומיין:

   כשמוכנים להחליף, עוברים אל 'איך משנים את הדומיין הראשי ב-Google Workspace'.

   • ביטול כל המינויים למכשירים, כולל הציוד ל-Google Meet ו-Chrome Enterprise.
   • יכול להיות שתצטרכו להסיר חלק מהרישיונות שלא נתמכים כדי לבצע את ההעברה. פרטים נוספים זמינים במאמר בנושא רישיונות במקור.
   • אם בסביבת המקור יש רישיונות לתקופת ניסיון, ההחלפה תיחסם. חשוב לוודא שההחלפה מתבצעת לפני הקצאה של רישיונות זמניים.
   • יש בעיות מוכרות שקשורות לשינוי הדומיין הראשי ולשימוש בדומיינים משניים. כדאי לעיין בחלופות לשינוי הדומיין הראשי.
   • לא לשנות את השם של משתמשים או קבוצות להעברה אחרי שינוי של שם הדומיין הראשי. המשתמשים והקבוצות צריכים להישאר בדומיינים שלהם להעברה.
   • אם הגדרתם כניסה יחידה (SSO) באמצעות ספק זהויות מצד שלישי ואתם משתמשים במנפיק ספציפי לדומיין, טענת הנכוֹנוּת (assertion) ב-SAML משתנה בהתאם לדומיין הראשי החדש. בודקים את ההגדרה של ספק הזהויות כדי לוודא שהמשתמשים יוכלו לבצע אימות אחרי החלפת הדומיין הראשי. פרטים נוספים זמינים במאמר בנושא דרישות טענת נכוֹנוּת (assertion) ב-SSO.
4. הגדרת כללי שמירה ב-Google Vault – הגדרת כללי שמירה מותאמים אישית ללא הגבלת זמן.

   יוצרים כלל אחד לאפליקציות הבאות:

   • ‫Gmail – ביחידה הארגונית, בוחרים את יחידת הארגון הבסיסית.
   • קבוצות Google – בקטע 'קבוצות', בוחרים באפשרות 'כל הקבוצות'.

   יוצרים 2 כללים לאפליקציות הבאות:

   • ‫Chat – בוחרים באפשרות יחידה ארגונית היחידה הארגונית הבסיסית. בכלל השני, בוחרים באפשרות כל המרחבים ב-Chat.
   • ‫Drive – בוחרים באפשרות יחידה ארגונית היחידה הארגונית הבסיסית. בכלל השני, בוחרים באפשרות כל תיקיות האחסון השיתופי.
   • ‫Meet – בוחרים באפשרות יחידה ארגונית יחידה ארגונית בסיסית ומפעילים את האפשרות כולל פריטים מתיקיות אחסון שיתופי. בכלל השני, בוחרים באפשרות כל תיקיות האחסון השיתופי.
   • ‫Sites – בוחרים באפשרות יחידה ארגונית היחידה הארגונית הבסיסית ומפעילים את האפשרות כולל פריטים מתיקיות אחסון שיתופי. בכלל השני, בוחרים באפשרות כל תיקיות האחסון השיתופי.

   בנוסף, כללי שמירה מותאמים אישית ללא הגבלת זמן מוגדרים בסביבת היעד לפני ההעברה. פרטים נוספים זמינים במאמר בנושא שמירה ללא הגבלת זמן ב-Google Vault בסביבת היעד. מידע נוסף על העברה מ-Vault זמין במאמר העברת נתוני Vault באמצעות העברת דומיין.

5. גיבוי של ארטיפקטים ב-Vault והסרת הפניות לישויות להעברה – מורידים ומגבים את ההגדרות והדוחות של Vault עבור הישויות להעברה, כי יכול להיות שלא תהיה אליהם גישה בסביבת המקור אחרי ההעברה. המידע הזה כולל עניינים, החזקות לצורך משפטי, חיפושים וייצואים.

   אחרי הגיבוי, מסירים הפניות לישויות ההעברה מפריטי המידע ב-Google Vault. אם יש ארטיפקטים ב-Vault שמכילים הפניות לישויות ההעברה, המערכת תחזיר שגיאות ולא תהיה אפשרות לגשת ל-Vault.

   • השמירה והשימור לא אוכפים את ההחזקות שנכשלו על ישויות ההעברה.
   • מסירים את כל ההפניות למשתמשים להעברה, לקבוצות להעברה ולתיקיות באחסון שיתופי להעברה מתיקים משפטיים, מרשימות משותפות, מהקפאות ומכללי שמירה. ב-Vault אי אפשר להגדיר הקפאה לצורך משפטי בדייר אחד שמפנה לישות בדייר אחר.
   • כדי לשמור על הקפאת נתונים בהעברת נתוני משתמש בדייר המקור, אדמינים צריכים ליצור משתמש חדש שלא מיועד להעברה ולהעתיק את כל הנתונים ב-Gmail וב-Drive מהמשתמשים המוקפאים למשתמש החדש. לאחר מכן, מארכבים את המשתמשים החדשים שלא מועברים ומוודאים שהם שייכים לדומיין שלא מועבר. במקום זאת, צריך ליצור הקפאות מקבילות ב-Vault עבור המשתמש החדש שלא מועבר, ולהסיר את ההקפאות של המשתמש המקורי להעברה.
   • כדי לשמור את ההשעיות על העברת נתוני משתמשים בדייר היעד, משתמשים בגיבויים כדי להוסיף השעיות מקבילות בדייר היעד אחרי ההעברה.
   • אין צורך להסיר הפניות עקיפות. הפניות עקיפות קשורות ליחידה ארגונית שמכילה משתמש להעברה.
   • אין צורך להסיר הפניות בחיפושים ובייצוא שהושלמו. ההפניות האלה יורדו.
6. עדכון רשומת Sender Policy Framework ‏ (SPF) (אם רלוונטי) – אם סביבת היעד משתמשת בשער דואר יוצא ששונה מסביבת המקור, צריך לעדכן את רשומת ה-SPF של המקור כך שתכלול את שער הדואר היוצא.

   הערה: אם אתם משתמשים ב-DomainKeys Identified Mail ‏ (DKIM), ההעברה לא אמורה להשפיע על המדיניות שלכם בנושא פרוטוקול מבוסס-דומיין לאימות, דיווח והתאמה של הודעות (DMARC). רשומת ה-SPF תמשיך להתאים אחרי ההעברה, גם אם רשומת ה-DKIM לא תתאים באופן זמני. בנוסף, חשוב להשלים את המשימה שקשורה ל-DKIM אחרי ההעברה בסביבת היעד.

7. הערכת ההשפעה על הארגון המשויך ב-Google Cloud (אם רלוונטי) – אם נעשה שימוש ב-Google Cloud, צריך להודיע לאדמינים של הסביבה הזו על ההשפעות הפוטנציאליות של פיצול העברת דומיין ב-Google Workspace על Google Cloud. במקרה הצורך, אפשר לערב את השותף שלכם ב-Google Cloud או את אנשי הקשר שלכם ב-Google Cloud כדי לקבל עזרה בהערכת ההשפעות ובשלבי התיקון. צוות Google Workspace Domain Transfer Divestiture לא מציע עזרה ב-Google Cloud במהלך העברת דומיין.
8. מודיעים למפיץ של Google Workspace (אם רלוונטי) – חשוב לעדכן אותו לגבי הזמן המתוכנן להעברת הדומיין ולבקש ממנו לא לשנות את החשבון (לדוגמה, לעדכן מינויים) במהלך תקופת ההעברה.

9. הרשמה לתוכניות אלפא או בטא שסביבת המקור או היעד משתתפות בהן (אם רלוונטי) – הרשמות לתוכניות אלפא ובטא לא מועברות בסביבת המקור. באופן דומה, יכול להיות שסביבת המקור תהיה תלויה בהרשמות בסביבת היעד. כדי להמשיך להשתמש בתוכניות האלה, צריך להגיש בקשה להצטרפות אליהן עבור הסביבה שלא רשומה בהן, ולקבל אישור.
   מומלץ להירשם לתוכניות אלפא או בטא לפני ההעברה, כדי שלמשתמשים שיועברו יהיו אותן תכונות זמינות לאורך תהליך ההעברה. עם זאת, תהליך ההרשמה עשוי להימשך זמן מה, ואין ערובה להצלחה. לכן, מומלץ להשתמש בו, אבל לא חובה.

10. כדי להעביר מכשירי Chrome שמשויכים אוטומטית לארגון:
    1. בסביבת המקור,מבטלים את האסימון הקיים של הקצאת הרשאות מראש ומבטלים את הקצאת ההרשאות של כל המכשירים. מאפסים את המכשירים להגדרות המקוריות.
    2. בסביבת היעד, יוצרים טוקן חדש לניהול ידני מראש של הקצאות.
    3. מעבירים את הטוקן החדש לשותף המורשה להקצאת הרשאות מראש. השותף משתמש בטוקן כדי להקצות מראש הרשאות למכשירים בסביבת היעד.

    המכשירים נרשמים אוטומטית ברגע שהם מחוברים לאינטרנט. מצב המכשיר משתנה ל'הוקצה לשימוש'.

    מידע נוסף על מכשירים עם הרשמה דרך הארגון זמין במאמר בנושא הרשמה דרך הארגון.

11. עדכון החברות בקבוצות – הסרת כל המשתמשים והקבוצות להעברה מקבוצות שלא מועברות, והסרת כל המשתמשים והקבוצות שלא מועברים מקבוצות להעברה. לדוגמה, צריך להסיר את user@to-stay-insource.com ואת group@to-stay-insource.com מהקבוצה group@to-be-transfer.com.

    הערה: השלב הזה הוא אופציונלי, כי אפשר להפנות למשתמשים ולקבוצות חיצוניים בתוך קבוצות אחרות. השלכות של ניהול קבוצות כשדייר אחר מנהל קבוצות של חברים ומשתמשים

12. הסרת משתמשים וקבוצות להעברה ממשתמשי היעד – משתמשי היעד לא מועברים, ולכן לאדמין ביעד אין שליטה על משתמשי היעד בסביבת המקור אחרי ההעברה.

    הערה: השלב הזה הוא אופציונלי, כי קהלי יעד מאפשרים הפניות למשתמשים ולקבוצות חיצוניים. למשתמשים תהיה גישה למסמכים ששותפו עם קהלי היעד.

13. עדכון של כללי מדיניות שמבוססים על קבוצות – צריך להסיר ממאגר המידע של הדייר המקורי את כל כללי המדיניות שמבוססים על קבוצות ומפנים לקבוצות העברה.

    חשוב: אם דייר המקור מכיל מדיניות מבוססת-קבוצות שמפנה לקבוצות העברה, המדיניות מבוססת-הקבוצות נעלמת ממסוף Admin ולא ניתן לערוך אותה. היא עדיין בתוקף לגבי משתמשים שלא מועברים בקבוצת ההעברה, אבל אי אפשר לראות או לערוך אותה. זו סיבה נוספת להסרת קבוצות חוצות דיירים בשלב 12.

14. הגדרת ניהול מכשירים ניידים לניהול בסיסי – ביטול הקצאת ניהול מכשירים ניידים למשתמשים שמועברים או הגדרת ניהול בסיסי.

15. ספריות מותאמות אישית – יש בעיה מוכרת בספריות מותאמות אישית. ספריות בהתאמה אישית לא מועברות, ולפני ההעברה צריך להסיר את כל קבוצות ההעברה.

    חשוב: אם לא מסירים קבוצות להעברה, אי אפשר לערוך או למחוק את הספרייה, וההתנהגות שלה עשויה להיות לא עקבית.

16. עדכון החברות ביחידה ארגונית – מוודאים שביחידה ארגונית כלשהי בסביבת המקור לא מופיעים גם משתמשים שמועברים וגם משתמשים שלא מועברים. משתמשים להעברה ומשתמשים שלא מיועדים להעברה צריכים להיות ביחידות נפרדות, ואי אפשר לערבב אותם ביחידה בסביבת המקור.

17. עדכון הקצאת רישיונות אוטומטית – ביחידות ארגוניות שמכילות משתמשים להעברה, צריך לוודא שההגדרה של הקצאת רישיונות אוטומטית מושבתת.

1. יצירת סביבת יעד – הכלי Google Workspace Domain Transfer Divestiture לא יוצר באופן אוטומטי סביבת יעד ב-Google Workspace. צריך ליצור אותו מראש. חשוב להגדיר חיוב ולאמת שם דומיין ראשי בסביבת היעד.

2. הרשיונות לא מועברים כחלק מתהליך ההעברה, ולכן צריך להקצות מספיק רשיונות נוספים ב-Google Workspace כדי לתמוך בכל המשתמשים להעברה – כשמעבירים משתמשים, מוקצה להם אותו סט של רשיונות בסביבת היעד שהיה להם בסביבת המקור. לכן, צריכים להיות מספיק רישיונות פנויים מאותו סוג בסביבת היעד בזמן ההעברה.

   אם בסביבת היעד נעשה שימוש במהדורת Google Workspace שונה מזו שמוגדרת בסביבת המקור, צריך לוודא שהרישיונות תואמים על ידי שדרוג הרישיונות בסביבת המקור או בסביבת היעד.

   הערות:

   • ‫Google ממליצה לשדרג את הרישיונות כדי למנוע הפעלה של תהליך מחיקת השירות (SWP).
   • הקצאת רישיונות חסרים כדי שיהיו כמה מינויים בסביבת היעד. אחרי ההעברה, אפשר לשדרג או לשנמך רישיונות של משתמשים ספציפיים. שימו לב שלא כל סוגי הרישיונות תומכים ברישוי דומיין בשיטה חלקית (PDL).
   • מוודאים שיש מספיק רישיונות פנויים בסביבת היעד. כדאי לבדוק אם נוספים עוד משתמשים (למשל, עובדים חדשים) לכל סביבת מקור בין ההתחלה לסיום של תהליך ההעברה. אם יש כמה העברות, צריך גם לקחת בחשבון את המספר הכולל של משתמשי המקור בכל ההעברות.
   • גם משתמשים בסביבת המקור שלא הוקצו להם רישיונות מועברים. כדאי לעקוב אחרי הקצאת הרישיונות האוטומטית בסביבת היעד כדי לוודא שהמשתמשים האלה לא יקבלו רישיונות.
   • במהלך העברת דומיין, לא מוצעים תוכניות חיוב מיוחדות ב-Google Workspace לרכישת רישיונות נוספים. אם הרישיונות בסביבת המקור הם במסגרת תוכנית חיוב שנתית, הם יישארו פעילים ותחויבו עליהם עד לסיום החוזה של התוכנית השנתית. אם יש לכם שאלות נוספות לגבי תוכניות החיוב של Google Workspace, אתם יכולים לפנות לנציג המכירות או למנהל החשבון שלכם.

3. לוודא שהרישיונות מוחלים בצורה נכונה על המשתמשים בהעברה כשקיימים כמה רישיונות – הגדרות מסוימות בסביבת היעד עשויות להשפיע על האופן שבו מוקצים רישיונות למשתמשים בהעברה.מצב כזה עלול לגרום לכך שהמשתמשים בהעברה יקבלו רישיון שונה מהרישיון שציפיתם שיקבלו. ההגדרות האלה כוללות הקצאת רישיונות אוטומטית וביטול של הקצאת רישיונות אוטומטית לארגונים ספציפיים.

   כדי לוודא שלא יהיו שינויים לא צפויים ברישיונות במהלך ההעברה, צריך לבצע את הפעולות הבאות:

   • אם ההגדרה של הרישוי האוטומטי בסביבת היעד היא 'מושבת לכולם' או אם בסביבת היעד יש רק סוג רישיון אחד, לא צריך לבצע שינויים.
   • אם ההגדרה של הרישוי האוטומטי בסביבת היעד היא 'מופעל לכולם' (לדוגמה, רישיונות ל-Google Workspace), צריך לוודא שההגדרה 'ביטול הגדרות ברירת המחדל' מופעלת ליחידות ארגוניות ספציפיות. ביחידה הארגונית הבסיסית להעברה, מוודאים שההגדרה של הקצאת רישיונות אוטומטית מושבתת, ואין שינויים נוספים ביחידות הבת הארגוניות.

4. יוצרים את היחידה הארגונית הבסיסית להעברה, ואם רוצים, יוצרים מחדש את מבנה היחידות הארגוניות של סביבת המקור – יוצרים יחידה ארגונית שתשמש כיחידת הארגון הראשית לכל המשתמשים שיועברו. אחרי שיוצרים את הקבוצה, יש 2 אפשרויות:

   • לא לבצע פעולה – תהליך העברת הדומיין יוצר מחדש את מבנה היחידות הארגוניות מסביבת המקור תחת היחידה הארגונית הבסיסית החדשה להעברה. כדי לבצע את השלב הזה, צריך להגדיר את אפשרות ההעברה 'יצירה מחדש של מבנה היחידה הארגונית מראש' ל'לא'. כל המשתמשים שמועברים יקבלו בירושה את המדיניות שאתם מחילים ברמת היחידה הארגונית.
   • יצירה מחדש באופן ידני של מבנה היחידות הארגוניות בסביבת המקור מתחת ליחידה הארגונית הבסיסית להעברה – העברת הדומיין מוודאת שכל מבנה היחידות הארגוניות בסביבת המקור משוכפל בצורה נכונה לפני שממשיכים בהעברה. כדי לבצע את השלב הזה, צריך להגדיר את אפשרות ההעברה 'יצירה מחדש של מבנה היחידה הארגונית מראש' לערך 'כן'. האפשרות הזו שימושית אם רוצים להגדיר מדיניות שונה ביחידות צאצא ארגוניות שונות.

     הערה: העברת דומיין מאמתת רק את המבנה של היחידה הארגונית. באחריותכם לוודא שהמדיניות המתאימה מוגדרת ביחידות הארגוניות.

5. הגדרת המדיניות וההגדרות המתאימות בהתאם לדרישות של סביבת המקור וסביבת היעד – המדיניות וההגדרות בסביבת המקור לא מועברות לסביבת היעד. בנוסף, אחרי שתהליך ההעברה יסתיים, רק המדיניות וההגדרות בסביבת היעד יחולו על המשתמשים שהועברו ועל הנתונים שלהם.

   צריך לבדוק את המדיניות וההגדרות בסביבת היעד ולהשוות אותן לאלה שבסביבת המקור. הפעולה הזו כוללת הגדרות כלליות וספציפיות עבור היחידה הארגונית הבסיסית של ההעברה, כדי לוודא שהן מכסות את כל הישויות והמשתמשים בהעברה הנכנסת.

   בהמשך מופיעה רשימה חלקית של מדיניות והגדרות שכדאי לבדוק כחלק מתהליך ההגדרה. בנוסף, מבצעים ביקורת מלאה של שני הסביבות כדי לוודא שכל החלקים הרלוונטיים נותחו:

   • הפעלת שירותים (מופעל/מושבת) – מוודאים שהשירותים שבהם אתם משתמשים בסביבת המקור מופעלים בסביבת היעד, ושהיחידה הארגונית הבסיסית להעברה מתנהגת כמצופה. זה חשוב במיוחד כשמשתמשים ב-Google Vault, כי יכול להיות שכללי Vault לא יחולו אם השירות מושבת.
   • Gmail, הגדרות מתקדמות ורשומות MX – בודקים הגדרות כמו ניתוב דואר, כללי תאימות, הפעלה והקצאת הרשאות של IMAP. פרטים נוספים מופיעים במאמר הפעלת Gmail עם Google Workspace.
   • ניהול סיסמאות – כדאי לבדוק את מדיניות הסיסמאות כדי לוודא שהיא תואמת לנהלים של הארגון. אחרי שהמשתמשים שהועברו עוברים לסביבת היעד, הם יורשים את כללי המדיניות לניהול סיסמאות בסביבת היעד.
   • אימות דו-שלבי – קובעת אם המשתמשים יכולים להוסיף לחשבון שלהם הגדרה של אימות דו-שלבי, אם זה מותר או נאכף. אם מעבירים משתמשים שהפעילו אימות דו-שלבי לסביבת יעד או ליחידה ארגונית שבה האימות הדו-שלבי מושבת, אדמינים ביעד לא יוכלו לנהל אותם. במקום זאת, אדמינים יכולים להעביר את המשתמשים האלה ליחידה ארגונית אחרת שבה האימות הדו-שלבי מופעל כדי לבצע שינויים, או להסיר את האימות הדו-שלבי מהחשבונות לפני ההעברה.
   • הגדרות שיתוף – קובעות אם משתמשים יכולים לשתף את התוכן שלהם מחוץ לארגון. אם שיתוף התוכן חסום בסביבת המקור ולא חסום בסביבת היעד, יכול להיות שאנשים מחוץ לארגון יוכלו לגשת לתוכן המועבר. אם השיתוף בסביבת המקור פתוח כברירת מחדל ובסביבת היעד לא, יכול להיות שהתוכן שיועבר לא יהיה נגיש למשתמשים בארגון. מידע נוסף על אפשרויות השיתוף של Google Drive ושל יומן Google
   • כללים למניעת אובדן נתונים (DLP) – מאפשרים לעקוב אחרי שיתוף מידע רגיש מחוץ לארגון ולמנוע אותו. כש-DLP מונע ממשתמשים לשתף מידע בסביבת המקור, ותוכן מועבר לסביבת יעד ללא הגדרת DLP, משתמשים בסביבת היעד יכולים לשתף מידע מחוץ לארגון. מידע נוסף על כללי DLP ב-Gmail ועל כללי DLP ב-Drive
   • היסטוריית הצ'אט – קובעת אם היסטוריית הצ'אט תישמר או לא, ואם המשתמשים יכולים להגדיר את האכיפה בכל הצ'אטים או להגדיר אותה כברירת מחדל. אם בסביבת המקור אפשר להפעיל את היסטוריית הצ'אט, אבל בסביבת היעד היא מושבתת, היסטוריית הצ'אט תאבד. למרות ש-Google Chat מופיע ברשימת האפליקציות שלא נתמכות בהעברה, צ'אטים ישירים יועברו.
   • מדינות או אזורים גיאוגרפיים לאחסון נתונים – קובעים באיזה מיקום גיאוגרפי ספציפי יאוחסנו הנתונים שהועברו. משתמשים להעברה שצריכים להישאר במיקום גיאוגרפי מסוים חייבים להגדיר את המדיניות הזו בצורה מתאימה בסביבת היעד, כדי לוודא שהנתונים שלהם לא עוברים באופן בלתי צפוי מהמדינה או האזור הנדרשים. פרטים נוספים מופיעים במאמר בנושא אזורים גיאוגרפיים לאחסון נתונים: בחירת מיקום גיאוגרפי לנתונים.
   • אפליקציות ברמת אבטחה נמוכה (נקראות גם סיסמאות לאפליקציות) – אם אפליקציות ברמת אבטחה נמוכה מופעלות בסביבת המקור ומושבתות בסביבת היעד, החיבור לאפליקציה באמצעות אפליקציות ברמת אבטחה נמוכה יפוג וייסגר. תקופות הזמן הקצוב לתפוגה משתנות בהתאם לאפליקציה, אבל בדרך כלל הן מסתיימות תוך 60 דקות. בקשות גישה עתידיות שיישלחו מהאפליקציה הלא מאובטחת ייחסמו. פרטים נוספים זמינים במאמר בנושא שליטה על הגישה לאפליקציות ברמת אבטחה נמוכה.
   • היקפי הרשאות OAuth, כניסה יחידה (SSO) ל-SAML, אפליקציות מהימנות ותוספי Chrome – אמצעי הבקרה של OAuth קובעים את רמת הגישה לממשקי API שמותרת למשתמשים ולאפליקציות של צד שלישי. כניסה יחידה (SSO) ל-SAML, בין אם היא מסופקת על ידי Google Workspace או מיושמת כאפליקציה בהתאמה אישית, מאפשרת למשתמשים להשתמש בפרטי הכניסה שלהם ב-Google Workspace כדי לגשת לאפליקציות או לשירותים אחרים. אפליקציות מהימנות קובעות אילו אפליקציות המשתמשים יכולים להתקין מ-Google Workspace Marketplace או מחנות האינטרנט של Chrome, ואילו אפליקציות יכולות לעקוף את ההגבלות של OAuth. מידע נוסף על שליטה באפליקציות של צד שלישי ואפליקציות פנימיות, ב-SSO מבוסס SAML, באפליקציות של Google Workspace Marketplace ובאפליקציות ותוספים ל-Chrome.
   • הענקת הרשאות גישה ברמת הדומיין – מאפשרת לאפליקציות לגשת לנתונים של משתמשים ב-Google Workspace. כדי לוודא שהלקוחות וההיקפים פועלים בצורה תקינה, מגדירים העברת הרשאות לכל הדומיין בסביבת היעד לפני ההעברה.

   חשוב: אם לא מצליחים להגדיר מדיניות והגדרות בצורה נכונה, יכולות להיות לכך השלכות כמו:

   • חשיפה לא מכוונת של הנתונים מחוץ לארגון (לדוגמה, בסביבת היעד יש הגדרות פתוחות יותר מאשר בסביבת המקור)
   • גישה מוגבלת לנתונים שאפשר היה לגשת אליהם בעבר (לדוגמה, בסביבת היעד יש הגדרות מגבילות יותר מאשר בסביבת המקור)
6. אישור הסכמים שחלים על נתונים שמועברים – צריך לעיין בתיקון לעיבוד נתונים (DPA), בסעיף החוזה לדוגמה ובתיקון בנושא שותף עסקי לפי חוק HIPAA בסביבת היעד. פרטים נוספים מופיעים במאמר תאימות לפרטיות ורשומות ב-Google Workspace וב-Cloud Identity.
7. הפעלה של Vault אם נעשה בו שימוש בסביבת המקור – אם בסביבת היעד לא נעשה שימוש ב-Vault אבל בסביבת המקור כן, צריך להפעיל את Vault בסביבת היעד.
8. מודיעים למפיץ של Google Workspace (אם רלוונטי) – חשוב לעדכן אותו לגבי הזמן המתוכנן להעברת הדומיין ולבקש ממנו לא לשנות את החשבון (לדוגמה, לעדכן מינויים) במהלך תקופת ההעברה.

9. הרשמה לתוכניות אלפא או בטא שסביבת המקור או היעד משתתפות בהן (אם רלוונטי) – הרשמות לתוכניות אלפא ובטא לא מועברות בסביבת המקור. באופן דומה, יכול להיות שסביבת המקור תהיה תלויה בהרשמות בסביבת היעד. כדי להמשיך להשתמש בתוכניות האלה, צריך להגיש בקשה להצטרפות אליהן עבור הסביבה שלא רשומה בהן, ולקבל אישור.
   מומלץ להירשם לתוכניות אלפא או בטא לפני ההעברה, כדי שלמשתמשים שיועברו יהיו אותן תכונות זמינות לאורך תהליך ההעברה. עם זאת, תהליך ההרשמה עשוי להימשך זמן מה, ואין ערובה להצלחה. לכן, מומלץ להשתמש בו, אבל לא חובה.

חשוב:

• הורדת רמת הרישיונות עלולה לגרום לאובדן של שירותים ופונקציות של Google Workspace. לפני שמבצעים שינויים, חשוב לעיין בקפידה בהבדלים בין מהדורות Google Workspace ובהשפעה של שדרוג ושל הורדת רמה. מידע נוסף על מהדורות Google Workspace
• הורדת רמת הרישיונות עשויה להפעיל את SWP, מה שיכול לעכב את ההעברה עד 90 ימים.

• ניהול שינויים – צוות העברת הדומיין של Google Workspace או תהליך ההעברה לא מספקים למשתמשים באופן אוטומטי מידע על ביצוע ההעברה במהלך תהליך ההעברה. מומלץ מאוד שנציגים של סביבת המקור וסביבת היעד יודיעו למשתמשים מראש על תהליך ההעברה ועל ההשפעות האפשריות שלו.

  כל פעולות האדמין בסביבת המקור ובסביבת היעד נחסמות במהלך ההעברה, כולל גישה ל-API ולמסוף Google Admin. מומלץ מאוד שנציגים של סביבת המקור וסביבת היעד יודיעו לכל הסופר-אדמינים והאדמינים עם הרשאות בדומיין לפני ההעברה ועם סיומה.

• תלות חיצונית: אם אתם משתמשים ב-Google Cloud Directory Sync‏ (GCDS), ב-GAM (כלי של צד שלישי בשורת הפקודה שמיועד לאדמינים ב-Google Workspace לניהול הגדרות של דומיין ומשתמשים) או בספק של צד שלישי לכניסה יחידה (SSO), חשוב שתנתחו את ההשפעה של ההעברה. כדאי גם לבדוק איך קיום סביבות המקור והיעד בסביבה אחת משפיע על המערכת ועל התזמון של ביצוע ההעברה.

העברת דומיין של Google Workspace לצורך מכירת חלק מהעסק מגדירה כללי שמירה מותאמים אישית ללא הגבלת זמן בסביבת היעד. אדמינים בסביבת היעד לא נדרשים לבצע פעולה כלשהי.

הארכיון ב-Vault של משתמשים להעברה מועבר, אבל כללי השמירה ב-Vault מסביבת המקור לא מועברים. כדי לוודא שנתונים ב-Vault לא יימחקו בטעות במהלך ההעברה ואחריה, תהליך ההעברה יוצר את כללי השמירה הבאים ב-Vault בסביבת היעד לפני שהוא מבצע פעולות העברה כלשהן:

• ‫Gmail – כלל שמירה מותאם אישית ללא הגבלת זמן (היקף: יחידה ארגונית בסיסית להעברה).
• יומן Google – כלל שמירה מותאם אישית ללא הגבלת זמן (היקף: העברה של יחידה ארגונית בסיסית).
• ‫Google Chat – כלל שמירה מותאם אישית ללא הגבלת זמן (היקף: צ'אטים ישירים עם משתמשים להעברה ביחידה הארגונית הבסיסית להעברה, אבל לא מרחבים).
• ‫Google Drive – כלל שמירה מותאם אישית ללא הגבלת זמן, לא כולל תיקיות באחסון השיתופי (היקף: יחידה ארגונית בסיסית להעברה).
• קבוצות Google – כלל שמירה מותאם אישית ללא הגבלת זמן (היקף: יחידה ארגונית בסיסית). שומר את הנתונים של כל הקבוצות בסביבת היעד, כולל אלה שלא נכללות בתהליך ההעברה.
• ‫Google Meet – נדרשים 2 כללי שמירה מותאמים אישית ללא הגבלת זמן:
  1. לא כולל תיקיות של אחסון שיתופי (היקף: היחידה הארגונית הבסיסית להעברה).
  2. כולל כל תיקיות האחסון השיתופי (ההיקף: היחידה הארגונית הבסיסית).

     שומר את הנתונים של כל האחסונים השיתופיים בסביבת היעד, כולל אלה שלא נכללים בתהליך ההעברה.

• ‫Google Sites – נדרשים 2 כללי שמירה מותאמים אישית ללא הגבלת זמן.
  1. לא כולל תיקיות של אחסון שיתופי (היקף: היחידה הארגונית הבסיסית להעברה).
  2. כולל כל תיקיות האחסון השיתופי (ההיקף: היחידה הארגונית הבסיסית).

     שומר את הנתונים של כל האחסונים השיתופיים בסביבת היעד, כולל אלה שלא נכללים בתהליך ההעברה.

• תיקיות אחסון שיתופי – כלל שמירה מותאם אישית ללא הגבלת זמן בכל תיקיות האחסון השיתופי (היקף: יחידה ארגונית בסיסית). שומר את הנתונים של כל האחסונים השיתופיים בסביבת היעד, כולל אלה שלא נכללים בתהליך ההעברה.

חשוב: כללי השמירה ב-Vault בסביבת היעד לא מוסרים או משתנים במהלך תהליך ההעברה, כי פעולה כזו עלולה לגרום לאובדן נתונים בלתי הפיך.