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 Partner או את אנשי הקשר שלכם ב-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
   • היסטוריית הצ'אט – קובעת אם היסטוריית הצ'אט תישמר או לא לציטוט, ואם המשתמשים יכולים להגדיר את האכיפה בכל הצ'אטים או להגדיר אותה כברירת מחדל. אם בסביבת המקור אפשר להפעיל את היסטוריית הצ'אט, אבל בסביבת היעד היא מושבתת, היסטוריית הצ'אט תאבד. למרות ש-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 בסביבת היעד לא מוסרים או משתנים במהלך תהליך ההעברה, כי פעולה כזו עלולה לגרום לאובדן נתונים בלתי הפיך.