מאמר

מ‑Exchange מקומי ל‑Microsoft 365: מדריך מעשי

ILS Networks 26 באוגוסט 2026 מדריך ב‑8 חלקים

התמיכה ב‑Exchange Server 2016 ו‑2019 הסתיימה. המדריך הזה עוסק במה שקורה אחרי ההחלטה: איך בוחרים שיטת הגירה, מה מודדים לפני, מה נשבר בפועל, ואיך נראית חזרה לאחור אם משהו משתבש.

רוב מנהלי ה‑IT בישראל כבר לא מתלבטים אם לעבור ל‑Microsoft 365. הם תקועים באמצע ההחלטה איך: איזו שיטת הגירה, איזה רישוי, מה קורה למערכות שמייצרות דואר, ומה עושים אם ביום שני בבוקר הדואר לא נכנס.

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

ILS Networks היא Microsoft Cloud Solution Provider ומלווה תשתיות IT ארגוניות בישראל משנת 2009. ב‑Galmarine ביצענו את המעבר הזה ממש — הגירת הדואר משרת Exchange 2019 מקומי ל‑Microsoft 365. ב‑Combe ביצענו הגירה מלאה של סביבת העבודה, כולל שכבת הקבצים, לצד הכנת הארגון לעמידה בדרישות אבטחת מידע מול מוסדות ממשלתיים.

מה מכריח את ההחלטה עכשיו

לפני שנכנסים לשיטות, כדאי להבין שהשעון כבר רץ. זו לא החלטה שאפשר לדחות בשקט לשנה הבאה:

התמיכה ב‑Exchange Server 2019 ו‑2016 הסתיימה. בלשון Microsoft: "Support for Exchange Server 2019 and 2016 ended on October 14, 2025."
השרת ממשיך לרוץ — אבל בלי עדכוני אבטחה, בלי תיקוני באגים, בלי תמיכה טכנית ובלי עדכוני אזורי זמן. מבחינת סקר סיכונים זו מערכת ללא תמיכה שמחזיקה את הדואר הארגוני.
שלושה יעדים לגיטימיים: Microsoft 365, שדרוג ל‑Exchange Server Subscription Edition בסביבה המקומית, או שילוב. להישאר על 2016/2019 הוא לא אחד מהם.
Exchange 2019 משודרג ל‑SE במקום (In-Place). Exchange 2016 לא — צריך לעבור דרך Exchange 2019 CU14/CU15, או לצרף שרת SE לארגון הקיים.
לארגונים בישראל שעובדים מול מוסדות ממשלתיים או מול לקוחות עם דרישות אבטחת מידע: שרת דואר ללא תמיכה הוא ממצא ביקורת שמחכה לקרות, לא חוב טכני שאפשר לגלגל.
מועד ההחלטה אינו מועד המעבר. מיפוי, פיילוט וחיתוך נמדדים בשבועות ובחודשים — לא בסוף שבוע אחד.

מיפוי לפני שבוחרים שיטה

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

כמות התיבות, הגודל הכולל, והתיבה הגדולה ביותר בנפרד. מגבלת הפריט בהעברה היא 150MB להודעה.
תיבות משותפות, תיבות משאב (חדרים וציוד) ותיבות תיקיות ציבוריות — נספרות בנפרד. תיקיות ציבוריות הן הסיבה הנפוצה ביותר לכך שהגירה "פשוטה" מפסיקה להיות פשוטה.
כל מערכת שמייצרת דואר: ERP, סורקים ומדפסות רב‑תכליתיות, ניטור, התראות גיבוי ומערכות ליבה. לרשום לכל אחת את כתובת ה‑IP השולחת, שיטת האימות ונפח השליחה היומי.
שרתי הקבצים: נפח כולל, מספר קבצים, הנתיב העמוק ביותר, השם הארוך ביותר, הקובץ הגדול ביותר — ומי מחזיק הרשאות NTFS בפועל, לא מי אמור להחזיק.
זהות: האם חשבונות המשתמשים מנוהלים ב‑Active Directory מקומי, והאם Entra Connect כבר פרוס. התשובה קובעת אם סנכרון ספריות הוא דרישה או בחירה.
אזור ה‑DNS הקיים: MX, רשומת SPF, autodiscover, DKIM — ומה שמישהו הוסיף לפני שבע שנים ואף אחד כבר לא זוכר בשביל מה.
ארכיונים, מדיניות שימור (Journaling) ורכיבי ארכוב של צד שלישי שיושבים על נתיב הדואר.

בחירת שיטת ההגירה

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

Cutover — כל התיבות בקבוצה אחת, בלי דו‑קיום ובלי סנכרון ספריות. נתמך עד 2,000 תיבות, אבל Microsoft מסייגת שסביר יותר לבצע עד 150 משתמשים.
Staged — העברה בקבוצות, מחייבת סנכרון ספריות. רלוונטית לגרסאות Exchange ישנות יותר כמקור.
Minimal Hybrid (Express) — העברה חד‑פעמית בקבוצות עם סנכרון ספריות, בלי דו‑קיום ארוך טווח. נקודת האיזון לארגונים שצריכים גלים אבל לא צריכים שיתוף לוחות זמנים בין הסביבות.
Full Hybrid — דו‑קיום מלא: פנוי/תפוס בין הסביבות, ניתוב אחיד, וזו השיטה הנייטיבית היחידה שגם מחזירה תיבות בחזרה לסביבה המקומית. יתרון מעשי גדול: ה‑GUID של התיבה לא משתנה, כך שפרופילי Outlook וקבצי ה‑OST שורדים את המעבר.
IMAP ‏+ ייבוא PST — מעבירה דואר בלבד, בלי יומן, אנשי קשר ומשימות. מסלול גיבוי למקורות שאינם Exchange.
כלי צד שלישי — מצדיקים את הרישיון כשצריך תזמון גרנולרי, מעברי דלתא חוזרים, מיפוי הרשאות מורכב או מקור שהכלים הנייטיביים לא מגיעים אליו.
ההמלצה של Microsoft עצמה, במסמך פירוק הסביבה ההיברידית: "We strongly recommend consideration of cutover or staged migration for organizations with fewer than 2,000 mailboxes." היברידי קונה דו‑קיום, ומשלם עליו בסיבוכיות.
הכלל המעשי: בוחרים את השיטה הפשוטה ביותר שעונה על דרישת הדו‑קיום האמיתית של הארגון — לא את המרשימה ביותר.

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

הרישוי נקבע לפני הפיילוט, לא אחריו — כי הוא זה שקובע גודל תיבה, התנהגות ארכיון ומה בכלל אפשר להזיז:

משפחת Business‏ (Basic, Standard, Premium) מוגבלת ל‑300 משתמשים לטננט על פני כל המשפחה. מעל זה — תוכניות Enterprise.
Business Basic ו‑Standard כוללות Exchange Online Plan 1; ‏E3 ו‑E5 כוללות Plan 2. ההבדל המעשי: תיבה של 50GB מול 100GB, והתנהגות הארכיון.
לא כולם צריכים את אותה תוכנית. אפשר לשלב תוכניות Enterprise,‏ Business ותוכניות עצמאיות (למשל Exchange Online Plan 1) בטננט אחד.
תיבות משותפות ותיבות משאב לא דורשות רישיון משלהן — אבל ללא רישיון הן מוגבלות ל‑50GB. תיבה משותפת שאמורה להחזיק שנים של תכתובת צריכה החלטה מודעת.
רישוי דרך CSP‏ — ILS Networks היא Microsoft Cloud Solution Provider — משאיר את הרישוי, הטננט והתמיכה אצל גורם אחד, כולל שינויי כמות ומעבר בין תוכניות.
לתמחר לפי מצב היעד, כולל תיבות משותפות, חשבונות שירות ומשתמשים שכבר לא פעילים. הגירה היא ההזדמנות הטובה ביותר לנקות רשימת משתמשים.

החצי השני: שרתי הקבצים

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

להחליט יעד לכל שיתוף בנפרד: תוכן של משתמש יחיד — OneDrive; תוכן צוותי — ספריית SharePoint או Teams.
לא להעתיק את עץ התיקיות כמו שהוא. תכנון ההרשאות והמבנה נעשה לפני ההעברה; העתקה 1:1 מעבירה גם את הבלגן.
מה עובר ומה לא: קבצים, מבנה תיקיות, הרשאות ברמת פריט ומטא‑דאטה עוברים. הרשאות Deny מפורשות, מאפייני קובץ מוסתרים וקבצים מעל 15GB לא עוברים. Microsoft מנסחת זאת ישירות: "After migration, all advanced NTFS permissions are removed."
שמות ונתיבים: לתקן לפני ההעברה, לא אחריה. הפתרון הנכון לעצי תיקיות עמוקים הוא לפרק אותם, לא להילחם במגבלה.
להריץ סריקת הערכה לפני שמעבירים בית אחד — SPMT מספק מצב סריקה בלבד עם דוח ממצאים.
להקצות OneDrive למשתמשים מראש (Pre-provision) לפני שמזרימים אליו תוכן.
להעתיק אינקרמנטלית ברקע, ואז לבצע אירוע חיתוך אחד. את השיתוף הישן משאירים לקריאה בלבד — לא מוחקים.
קצב ההעברה אינו אינסופי: תעבורת הגירה ברקע מוגבלת (Throttling) חזק יותר בשעות העבודה בימי חול, ורצה מהר יותר בערבים ובסופי שבוע. מתכננים את לוח הזמנים לפי זה.

מה באמת נשבר: DNS, ריליי ומגבלות

רוב תקלות ההגירה לא קורות בהעברת התיבות. הן קורות בשכבות שמסביב:

DNS חיצוני: רשומת MX אחת שמצביעה על הטננט, ו‑SPF יחיד. Microsoft חד‑משמעית: "you can only have a single SPF record for your domain." מספר בדיקות ה‑DNS ברשומה מוגבל ל‑10.
DNS פנימי, לא רק חיצוני: רשומת autodiscover אל autodiscover.outlook.com, והסרת ערכי ה‑SCP מהשרתים המקומיים. שרת ישן שממשיך לפרסם SCP ימשיך למשוך את Outlook אליו.
ריליי SMTP — כאן נופלים הכי הרבה ארגונים. תיבה ב‑Exchange Online מוגבלת ל‑30 הודעות בדקה ול‑10,000 נמענים ביממה. ה‑ERP ששולח חשבוניות בלילה ייתקל בזה בשבוע הראשון.
קיימת גם מגבלת נמענים חיצוניים ברמת הטננט (TERRL) שנגזרת מכמות הרישיונות. ארגון עם דיוור פנימי כבד צריך לבדוק אותה מראש.
תיקיות ציבוריות דורשות הגירת אצווה נפרדת והחלטה נפרדת — האם עוברות, האם מומרות לתיבות משותפות, או האם מצדיקות שרת מקומי שנשאר.
פרופילי Outlook ומכשירים ניידים: בכל שיטה שאינה היברידית הפרופיל נבנה מחדש והמכשירים נדרשים להתחבר מחדש. זה עומס על מוקד התמיכה — צריך לתקצב אותו.
הרשאות על תיבות משותפות, הרשאות Delegate ו‑Send As לא תמיד שורדות את המעבר. בודקים אותן במפורש בפיילוט, לא בייצור.
אחרי SPF מגדירים DKIM ו‑DMARC. Microsoft מציינת ש‑SPF לבדו אינו מכסה את כל טכניקות הזיוף.

הקשחת הטננט לפני שהתיבה הראשונה זזה

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

אימות רב‑שלבי כבר אינו אופציונלי: Microsoft אוכפת MFA בכניסה למרכזי הניהול, ומאז 1 באוקטובר 2025 גם ללקוחות ניהול המשאבים — Azure CLI,‏ PowerShell,‏ SDK ו‑REST API.
חשבונות חירום (Break-Glass) נמצאים בתוך התחולה. ההמלצה הרשמית היא Passkey‏ (FIDO2) או אימות מבוסס תעודה — לא סיסמה בכספת.
כל סקריפט שמתחבר עם שם משתמש וסיסמה (זרימת ROPC) יישבר. לאתר אותם לפני שהאכיפה מאתרת אותם.
חשבון השירות של Entra Connect אינו מושפע מהדרישה — פריט אחד ברשימה שאפשר לסמן בלי עבודה.
Conditional Access דורש רישוי Entra ID P1/P2. בהיעדרו — Security Defaults, שזה עדיין הרבה יותר טוב מכלום.
מדיניות גישה, חסימת אימות מיושן ומיקומים מורשים — מוגדרים כשהטננט ריק. זה ההבדל בין הגדרה לבין שינוי בסביבת ייצור.
לארגונים שעובדים מול מוסדות ממשלתיים בישראל: ההקשחה והתיעוד שלה הם חלק מהתוצר, לא נספח. ב‑Combe הכנו את הארגון בדיוק לעמידה בדרישות האלה, לצד ההגירה עצמה.

חיתוך, חזרה לאחור והשרת האחרון

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

קבוצת פיילוט קודם: צוות ה‑IT, צוות עסקי אחד, משתמש Outlook כבד אחד ומשתמש שעובד רק מהנייד. הקומבינציה הזו חושפת כמעט את כל התקלות.
תכנית החזרה ב‑Cutover היא DNS: מורידים TTL לפני החיתוך, לא אחריו, ומשאירים את רשומת ה‑MX הישנה מוכנה לשחזור.
תכנית החזרה בהיברידי היא העברת תיבה בחזרה לסביבה המקומית — השיטה הנייטיבית היחידה שתומכת בכיוון הזה.
ברגע שסנכרון הספריות פעיל, מאפייני הנמענים מנוהלים מהסביבה המקומית. הסרת כל שרתי Exchange תשאיר אתכם בלי יכולת לנהל נמענים בענן.
שתי יציאות לגיטימיות: לכבות סנכרון ספריות ולנהל הכול בענן, או לשמור את Entra Connect ולהשאיר שרת אחד (עדיף שניים) לניהול נמענים — משודרג ל‑Exchange Server SE.
מה שבפועל משאיר את השרת האחרון בחיים הוא בדרך כלל תיקיות ציבוריות או ריליי SMTP. זו החלטה שמקבלים במודע, לא בדיעבד.
לפני פירוק: לוודא זרימת דואר פנימה והחוצה, פנוי/תפוס, מכשירים ניידים, גישה לארכיון, הרשאות Delegate — ושחזור אמיתי מהגיבוי.
לסיום: לעדכן תיעוד, ניטור ונהלי תפעול. ILS Networks מעניקה תמיכה 24/7 לסביבות שהיא מלווה.

מקורות

מקורות רשמיים לעובדות המרכזיות

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

קריאה נוספת

איך זה נראה בפועל

שירותי Microsoft 365 סיפור לקוח: Combe

על הכותבים

ILS Networks

ILS Networks היא Microsoft Cloud Solution Provider, ומלווה תשתיות IT ארגוניות בישראל משנת 2009 — ענן ודואר, רשתות, אבטחת מידע וגיבוי — עם תמיכה זמינה 24/7.

פורסם: 26 באוגוסט 2026 · עודכן: 26 באוגוסט 2026