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

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

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

   הערות:

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

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

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

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

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

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

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

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

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

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

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

8. פתרון בעיות שקשורות למשאבים לתזמון ביומן – אם יש בעיות שקשורות למשאבים לתזמון ביומן, צריך לפתור אותן לפני שממשיכים:
   • מזהי מבנים – מזהה מבנה בסביבת המקור לא יכול להיות זהה למזהה מבנה בסביבת היעד. יש שתי דרכים לעקוף את החסימה של ההעברה. אפשר למחוק את הבניין בסביבת המקור. אפשר גם להזין פרטים זהים לשני הבניינים כדי למזג את בניין המקור ובניין היעד. כדי ששני הבניינים יהיו זהים, צריך לוודא שהמזהה, השם, כל שדות הכתובת, התיאור והקומה יהיו זהים בשני הבניינים.
   • שמות של בניינים – אם למשאב בניין בסביבת המקור יש שם זהה לשם של משאב בניין בסביבת היעד, צריך לשנות את השם של אחד מהמשאבים כדי לפתור את הבעיה. אחרי שתהליך ההעברה יסתיים, תוכלו למזג את שני משאבי הבניין.
   • מזהי משאבים – אם יש משאב בסביבת המקור עם מזהה משאב זהה למשאב בסביבת היעד, נוצר קונפליקט שלא ניתן לפתור בתהליך ההעברה, והמשאב לא יועבר. מוחקים את אחד המשאבים שמתנגשים ויוצרים אותו מחדש עם מזהה שלא מתנגש. יעברו 30 ימים עד שהמערכת תסיר באופן מלא משאב שנמחק. אפשר לחכות עד שהמשאב יימחק לגמרי, או שהצוות של העברת הדומיין יכול לשלוח בקשה למחיקה ידנית שלו.
9. הערכת ההשפעה על הארגון המשויך ב-Google Cloud (אם רלוונטי) – אם נעשה שימוש ב-Google Cloud, צריך להודיע לאדמינים של הסביבה הזו על ההשפעות הפוטנציאליות של העברת דומיין ב-Google Workspace על 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
   • כללים למניעת אובדן נתונים (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. כדי לוודא שהלקוחות וההיקפים פועלים בצורה תקינה, מגדירים העברת הרשאות לכל הדומיין בסביבת היעד לפני ההעברה.

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

   • חשיפה לא מכוונת של הנתונים מחוץ לארגון (לדוגמה, בסביבת היעד יש הגדרות פתוחות יותר מאשר בסביבת המקור)
   • גישה מוגבלת לנתונים שאפשר היה לגשת אליהם בעבר (לדוגמה, בסביבת היעד יש הגדרות מגבילות יותר מאשר בסביבת המקור)
5. אישור הסכמים שחלים על נתונים שמועברים – צריך לעיין בתיקון לעיבוד נתונים (DPA), בסעיף החוזה לדוגמה ובתיקון בנושא שותף עסקי לפי חוק 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& מגדירה כללי שמירה מותאמים אישית ללא הגבלת זמן בסביבת היעד. לא נדרשת פעולה מצד האדמינים בסביבת היעד.

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

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

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

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

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

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

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