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

שלב 1: משימות המקור

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

   הערות:

   • כדי להימנע מעלויות, אפשר להשתמש ברישיונות תקופת חסד או ברישיונות ניסיון בסביבת המקור לצורך רכישת רישיונות זמנית. עם זאת, חשוב לשים לב לנקודות הבאות:
     • הרישיונות האלה חוסמים את תהליך ההחלפה של כל דומיין אחר בדומיין הראשי. לפני שמקצים רישיונות זמניים, צריך לשנות את הדומיין הראשי.
     • אם הרישיונות שזמינים בסביבת היעד הם רישיונות מלאים, למשתמשים יוקצו רישיונות מלאים כתוצאה מההעברה.
   • גם משתמשים בסביבת המקור שלא הוקצו להם רישיונות מועברים.
2. ביטול מינויים לרישיונות שלא נתמכים – יכול להיות שיהיו השלכות לביטול מינויים לרישיונות. בסביבות מקור עם Google Voice, חשוב לשים לב במיוחד לשלב הזה. פרטים נוספים זמינים במאמר בנושא רישיונות במקור.
3. הוספת פלייסהולדר לדומיין ל-Google Workspace (אם רלוונטי) – מוסיפים ומאמתים שם דומיין משני חדש בסביבת המקור, שיחליף בסופו של דבר את הדומיין הראשי הקיים. אם קיים דומיין משני ולא צריך להעביר אותו, אפשר להשתמש בו במקום זאת. פרטים נוספים זמינים במאמר הוספת דומיין חלופי או דומיין משני של משתמש.
4. יצירת אדמין זמני והגדרתו כאדמין הראשי של החשבון – יוצרים חשבון משתמש שמשויך לדומיין הזמני. אם אתם משתמשים מחדש בחשבון ישן, חשוב לוודא שלא מצורפים לחשבון דומיינים אחרים להעברה שקיימים ככתובות אימייל חלופיות. נותנים למשתמש את תפקיד הסופר-אדמין והופכים אותו לאדמין הראשי בחשבון. מידע נוסף זמין במאמר בנושא איך לשלוח התראות על חיובים וחשבונות לאדמין אחר. מוודאים שהאימות הדו-שלבי של Google מוגדר, ונכנסים לחשבון לפחות פעם אחת כדי לאמת את הגישה באמצעות חשבון פלייסהולדר לאדמין.
5. החלפת הדומיין הראשי בדומיין הפלייסהולדר – ביצוע החלפת דומיין, והפיכת דומיין הפלייסהולדר לדומיין הראשי החדש.

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

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

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

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

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

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

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

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

7. עדכון רשומת Sender Policy Framework ‏ (SPF) (אם רלוונטי) – אם סביבת היעד משתמשת בשער דואר יוצא ששונה מסביבת המקור, בסביבת המקור צריך לעדכן את רשומת ה-SPF כך שתכלול את שער הדואר היוצא.

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

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

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

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

שלב 2: משימות ביעד

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

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

   הערות:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

חשוב:

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

שלב 3: משימות ושיקולים נוספים

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

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

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

שמירת נתונים ב-Google Vault ללא הגבלת זמן בסביבת היעד

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

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

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

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

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

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

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

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