Cloud LMS מול התקנה מקומית: מטריצת החלטה
פורסם: · עודכן:
Cloud LMS היא מערכת ניהול למידה בענן, ללא שרתים מקומיים. עם פתיחת אזור AWS בתל אביב, גם ארגונים ישראליים רגישים יכולים ליהנות מהיתרונות: הקמה תוך שעות במקום חודשים, עלויות תפעול נמוכות ב-30%-50%, גמישות תפוסה מיידית, ועדכוני אבטחה אוטומטיים - הכל תוך שמירה על ריבונות נתונים ישראלית.
ארגונים ישראליים רבים ניצבים היום בפני החלטה אסטרטגית: להמשיך לתחזק מערכת ניהול למידה (LMS) על שרתים פנימיים, או לעבור לפתרון ענן מודרני. המעבר לענן חדל להיות שאלה של "אם" והפך לשאלה של "מתי" ו"איך". במאמר זה נסביר לעומק מהי Cloud LMS, מדוע דווקא עכשיו זה הזמן הנכון לישראליים, וכיצד לבחור נכון.
מהי Cloud LMS?
Cloud LMS היא מערכת ניהול למידה המתארחת על תשתית ענן ציבורית (AWS, Azure, GCP) במקום על שרתים פיזיים בחוות השרתים של הארגון. הגישה למערכת מתבצעת דרך דפדפן בלבד, ללא צורך בהתקנה מקומית, והספק אחראי על כל שכבת התשתית: שרתים, גיבויים, אבטחה, עדכונים וניטור.
למעשה, מדובר במעבר תפיסתי מ-CapEx (הוצאה הונית חד-פעמית על חומרה ורישוי) ל-OpEx (הוצאה תפעולית חודשית לפי צריכה). הארגון משלם עבור מה שהוא באמת משתמש, מתי שהוא משתמש.
Cloud LMS מול On-Premise: השוואה מפורטת
ההבדלים בין שתי הגישות משמעותיים בכל היבט תפעולי ופיננסי:
זמן הקמה
מערכת On-Premise דורשת רכש חומרה, התקנה פיזית, הגדרת רשת, אבטחת מידע ותצורה ראשונית. תהליך זה נמשך בממוצע 3-6 חודשים. מערכת Cloud LMS זמינה תוך שעות ספורות מרגע ההזמנה, וניתן להתחיל להשתמש בה מיידית.
תחזוקה ועדכונים
ב-On-Premise, צוות ה-IT הפנימי אחראי על כל עדכון גרסה, תיקון פרצות אבטחה וגיבויים. עלות התחזוקה השנתית מגיעה לרוב ל-20%-25% מהעלות הראשונית. בענן, כל אלו כלולים במחיר החודשי והספק דואג להם באופן שקוף למשתמש.
גמישות ותפוסה
הרחבה של מערכת On-Premise מ-100 ל-10,000 משתמשים דורשת רכש חומרה נוסף, תכנון קיבולת ותהליך מיגרציה. בענן, ניתן להגדיל את התפוסה במאות אחוזים תוך דקות, ולהקטין אותה חזרה כשהעומס יורד. זה קריטי במיוחד בעונות שיא כמו רבעונים אחרונים או קמפיינים ארגוניים.
מבנה עלויות
ההשקעה הראשונית ב-On-Premise עשויה לנוע בין 200,000 ל-2,000,000 ש"ח, תלוי בגודל הארגון. Cloud LMS מתחיל ב-אלפי שקלים לחודש, ללא השקעה מקדימה. לאורך זמן, ה-TCO (Total Cost of Ownership) של פתרון ענן נמוך יותר עבור רוב הארגונים עד 5,000 משתמשים.
מדוע עכשיו זה הזמן הנכון בישראל?
שלוש התפתחויות מרכזיות הופכות את 2026 לנקודת מפנה עבור ארגונים ישראליים:
פתיחת אזור AWS בתל אביב
אמזון פתחה בשנת 2023 אזור ענן מלא (Region) בתל אביב, הכולל שלושה Availability Zones. משמעות הדבר היא שנתונים של ארגונים ישראליים יכולים להיות מאוחסנים פיזית על אדמת ישראל, עם השהיה נמוכה מאוד (Latency) ועמידה מלאה בדרישות הרגולציה המקומית. זהו שינוי מהותי עבור גופים ביטחוניים, חברות ביטוח, בנקים וגופי בריאות שקודם לכן נאלצו להישאר On-Premise בלבד.
ריבונות נתונים ותקנות
חוק הגנת הפרטיות הישראלי, תקנות משרד הביטחון, ורגולציית הבנקאות מחייבים במקרים רבים אחסון נתונים בתחומי המדינה. Cloud LMS המתארחת באזור AWS ישראל עונה על דרישות אלו במלואן, ומאפשרת גם לגופים רגישים ליהנות מיתרונות הענן.
תמיכה בעברית ו-RTL
לא כל פתרון Cloud LMS גלובלי תומך באמת בעברית מלאה. תמיכת RTL אמיתית דורשת עבודה מעמיקה על ממשק המשתמש, שדות טופס, דוחות, ייצוא ל-PDF, ואפילו הודעות מערכת. פלטפורמות כמו מגדלור, המבוססות על Moodle עם שכבת התאמות מקיפה, מספקות חוויית משתמש עברית מלאה שאינה מרגישה "מתורגמת".
מי הכי מרוויח מהמעבר?
לא כל ארגון צריך למהר לענן, אבל ישנן קטגוריות ברורות שהמעבר משרת אותן במיוחד:
- ארגונים בצמיחה מהירה - שאינם יודעים כמה משתמשים יהיו להם בעוד שנה
- חברות רב-אתריות - עם עובדים בסניפים גיאוגרפיים שונים או עבודה היברידית
- ארגונים ללא צוות IT גדול - שמעדיפים להתמקד ב-Core Business
- גופים עם צורך ב-DR - יכולת התאוששות מאסון מהירה ואוטומטית
- ארגונים עם דרישות אבטחה מחמירות - שרוצים ליהנות מהשקעות אבטחה של ענקיות הענן
איך לבחור פתרון Cloud LMS נכון?
הבחירה בין עשרות פתרונות בשוק דורשת בדיקה מסודרת של קריטריונים מרכזיים:
מיקום פיזי של הנתונים
ודאו שהספק מציע אחסון באזור AWS ישראל או ב-Data Center מקומי מוכר. בקשו הסכם SLA כתוב שמפרט את מיקום האחסון והגיבויים.
יכולות אינטגרציה
מערכת LMS ארגונית חייבת להתחבר ל-SSO קיים (SAML, OIDC), למערכות HR, ל-BI ולכלי תקשורת. בדקו שהפתרון תומך ב-API פתוח ותיעוד מלא.
יכולות AI מובנות
מערכות Cloud LMS מודרניות כוללות שכבת AI שיודעת ליצור מבחנים אוטומטית, לסכם תכני קורסים, לבנות נתיבי למידה אישיים ולנתח ביצועי לומדים. זהו חיסכון עצום בזמן צוות ההדרכה.
איכות התמיכה בעברית
בקשו הדגמה עם משתמש עברי אמיתי. בדקו לא רק את המסך הראשי, אלא גם דוחות, ייצוא, הודעות אימייל אוטומטיות ותפריטי admin.
תמיכה מקומית
ודאו שיש צוות תמיכה דובר עברית בשעות ישראל, ולא רק תמיכה גלובלית באנגלית עם השהיה של שעות.
סיכום
המעבר ל-Cloud LMS אינו רק החלטה טכנולוגית - זו החלטה אסטרטגית שמשפיעה על מהירות ההדרכה, על עלויות תפעול, על יכולת הצמיחה ועל חוויית העובד. עבור רוב הארגונים הישראליים ב-2026, היתרונות עולים משמעותית על החסרונות, במיוחד עם קיומו של אזור AWS ישראל.
אם אתם שוקלים מעבר או הקמה של מערכת חדשה, מומלץ להתייעץ עם מומחים שמבינים גם בטכנולוגיה וגם במציאות הרגולטורית הישראלית. צוות מגדלור מלווה ארגונים ישראליים בהקמת מערכות LMS מתקדמות מזה יותר מ-30 שנה.
מ-SaaS ועד ענן פרטי: מסגרת מסחרית לקבלת החלטה
בחירת Cloud LMS לארגונים בישראל אינה מסתכמת בבחירת ספק ענן. יש לבחון את מודל השירות, חלוקת האחריות והיכולת לשמור על שליטה במידע לאורך כל חיי ההתקשרות. בפתרון SaaS הספק מנהל את סביבת היישום והתשתית, ולכן הוא מתאים לארגונים שמעדיפים תפעול מרוכז ועדכונים מנוהלים. ענן פרטי או סביבה ייעודית עשויים להתאים כאשר נדרשות הפרדה מוגברת, מדיניות רשת ייחודית או שליטה רחבה יותר בתצורה. הבחירה הנכונה תלויה בדרישות הארגון, ולא רק בשם הטכנולוגיה.
שאלות שחייבות להופיע ב-RFP ובהסכם
- זהויות והרשאות: האם קיימת תמיכה ב-SSO באמצעות SAML או OIDC, באימות רב-שלבי ובהקצאת הרשאות לפי תפקיד? חשוב להגדיר גם תהליך הצטרפות, שינוי תפקיד וסיום העסקה.
- ריבונות ומחזור חיי המידע: היכן נשמרים בסיס הנתונים, הקבצים, הלוגים והגיבויים; מי רשאי לגשת אליהם; ומהו תהליך המחיקה בתום ההתקשרות? אין להסיק שמיקום בישראל מבטיח לבדו עמידה בכל דרישה רגולטורית.
- גיבוי והתאוששות: מהן תדירות הגיבוי, תקופת השמירה ויעדי RPO ו-RTO, והאם מבוצעים מבחני שחזור מתועדים? גיבוי קיים אינו חלופה להוכחת יכולת שחזור.
- SLA ותמיכה: כיצד נמדדת זמינות, אילו השבתות מוחרגות, מהן דרגות החומרה וזמני התגובה, ומהו מנגנון ההסלמה בעת אירוע אבטחה או תקלה עסקית?
- נגישות ושימושיות: בקשו הצהרת נגישות ותהליך בדיקה הכולל ניווט מקלדת, קוראי מסך, ניגודיות, כתוביות ותכנים שהארגון עצמו מעלה.
- יצוא וניידות נתונים: הגדירו מראש אילו נתונים ניתנים ליצוא, באילו פורמטים, האם היצוא כולל היסטוריית למידה, השלמות, ציונים וקבצים, ומה נדרש למעבר לספק אחר.
להשוות עלות כוללת, לא רק דמי מנוי
הערכת TCO צריכה לכלול הקמה, התאמות, מיגרציה, אינטגרציות, אחסון, תעבורה, תמיכה, סביבת בדיקות, הכשרת מנהלים, בדיקות אבטחה ונגישות, וכן עלויות יציאה. בעת בחירת מערכת LMS לארגון, מומלץ לבנות תרחישי שימוש לכמה שנים ולבחון כיצד משתנה העלות עם מספר המשתמשים, נפח המדיה ורמת השירות. ארגונים מפוקחים יכולים להיעזר גם בעקרונות הבחינה הייעודיים לענף הפיננסים, ולאחר מכן לעבור לעמוד המחיר או ההשוואה כדי לבחון את החלופות לפי היקף וצרכים.
כלל החלטה מעשי: העדיפו ספק שמוכן לתעד בכתב את גבולות האחריות, מיקום המידע, יעדי השירות ותהליך היציאה. כך ניתן להשוות הצעות על בסיס סיכון, תפעול ועלות כוללת, ולא על בסיס רשימת יכולות בלבד.
מודל פריסה אינו מודל בעלות: כך מגדירים אחריות ארגונית
חשוב להפריד בין שתי החלטות שונות: בחירת Cloud LMS לארגונים בישראל עוסקת באופן שבו המערכת נפרסת, מתארחת ומנוהלת; הבחירה במערכת LMS ארגונית עוסקת בפלטפורמה, ביכולות הלמידה ובמסגרת המסחרית. לכן SaaS, ענן פרטי ואירוח מנוהל אינם חלופות לבעלות המסחרית של המוצר, אלא מודלי הפעלה שאפשר לבחון בהתאם למדיניות הארגון.
| נושא | SaaS | ענן פרטי | אירוח מנוהל |
|---|---|---|---|
| סביבת המערכת | שירות סטנדרטי המנוהל בידי הספק | סביבה ייעודית בהתאם לארכיטקטורה שאושרה | סביבה ייעודית או משותפת, עם תפעול מוסכם |
| שליטה בתצורה | לרוב מוגבלת למסגרת השירות | רחבה יחסית, בכפוף למדיניות אבטחה | נקבעת בהסכם ובמטריצת האחריות |
| עדכונים ותחזוקה | מתוזמנים ומבוצעים בידי הספק | מחייבים תיאום בין הארגון לגורמי התשתית | מבוצעים בידי הספק לפי חלונות שירות |
| התאמה מרכזית | פשטות תפעולית ומהירות שינוי | בידוד ושליטה ארכיטקטונית | איזון בין גמישות לאחריות תפעולית |
מטריצת אחריות לפני חתימה
לפני הבחירה מומלץ להכין מטריצת RACI שמפרטת מי אחראי, מי מאשר ומי מקבל עדכון בכל תרחיש. יש לכלול לפחות ניהול זהויות, תיקוני אבטחה, ניטור, טיפול באירועים, בדיקות שחזור, שדרוגי גרסה, תחזוקת אינטגרציות והפקת נתונים בסיום ההתקשרות. כך נמנעים אזורים אפורים שבהם כל צד מניח שהצד האחר מטפל במשימה.
בדיקת התאמה בתרחיש אמיתי
במקום להסתפק במפרט, כדאי לבצע בדיקת היתכנות מצומצמת: חיבור SSO, סנכרון משתמשים ממערכת משאבי אנוש, העלאת תוכן מייצג, הפקת דוח ובדיקת תהליך תמיכה. בארגונים עתירי רגולציה אפשר לשלב דרישות ייעודיות מתוך עמוד פתרונות הלמידה לענף הפיננסים. לאחר אישור המודל, יש לתרגם את ההחלטה לתוכנית עבודה הכוללת בעלי תפקידים, אבני דרך, סביבת בדיקות וקריטריוני קבלה; פירוט נוסף ניתן למצוא בעמוד המחיר.
תהליך מסודר אינו קובע מראש שמודל אחד עדיף. הוא מאפשר לבחור את חלוקת האחריות המתאימה לרמת הסיכון, ליכולת התפעולית ולמורכבות האינטגרציות של הארגון.
שערי החלטה: מתי התקנה מקומית עדיין מוצדקת?
החלטת פריסה אינה צריכה להתחיל בהנחה שהענן או ההתקנה המקומית עדיפים תמיד. נכון יותר להגדיר אילוצים שאינם נתונים למשא ומתן, לבדוק אם כל חלופה עומדת בהם ורק לאחר מכן להשוות נוחות תפעולית ועלות. גישה זו מסייעת להבחין בין דרישה עסקית ממשית לבין העדפה היסטורית של צוות מסוים.
ארבעה תנאי סף לבחינת החלופות
- קישוריות ורציפות: אם הלמידה חייבת לפעול גם באתרים מבודדים או בעת ניתוק ממושך מהאינטרנט, יש להגדיר אילו פעולות נדרשות בזמן הניתוק וכיצד יסונכרנו הנתונים לאחריו. לעיתים האילוץ מצדיק התקנה מקומית או ארכיטקטורה משולבת, אך לא בהכרח את אירוח המערכת כולה בתוך הארגון.
- תלות במערכות פנימיות: יש למפות חיבורים לשירותי זהויות, מאגרי עובדים, מערכות תפעוליות ומקורות תוכן שאינם חשופים מחוץ לרשת. עבור כל חיבור יש לבדוק אם ניתן להשתמש בתווך מאובטח, בממשק API או ברכיב מקומי, במקום לפסול מראש פריסה בענן.
- שליטה בשינויים: ארגונים המחויבים לחלונות שינוי קשיחים צריכים לברר מי מאשר שדרוגים, כמה זמן נתמכות גרסאות קודמות ומה קורה כאשר תיקון אבטחה דחוף מתנגש במחזור האישור הפנימי. זהו הבדל מהותי בין שירות ענן מתעדכן לבין סביבה מקומית שבשליטת הארגון.
- יכולת תפעול מוכחת: התקנה מקומית דורשת בעלות שוטפת על מערכת ההפעלה, בסיס הנתונים, רכיבי הרשת, הניטור, התעודות והקיבולת. לפני בחירה בה יש לוודא שקיימים בעלי תפקידים, כיסוי בעת היעדרות ותקציב תחזוקה לאורך חיי המערכת.
לקבוע החלטה שניתנת לבחינה מחדש
מומלץ לתעד את ההחלטה במסמך ארכיטקטורה קצר הכולל את האילוצים, החלופות שנבדקו, הסיכונים שנותרו והנחות העבודה. לצד זאת יש לקבוע נקודת בחינה מחודשת, למשל לאחר שינוי רגולטורי, החלפת מערכת זהויות או גידול משמעותי בהיקף השימוש. כך מודל הפריסה אינו הופך לברירת מחדל קבועה לאחר שהנסיבות השתנו.
רק לאחר אישור מודל הפריסה כדאי לעבור לבחינת היכולות הפונקציונליות של מערכת LMS ארגונית. הפרדה זו שומרת את הדיון ממוקד: תחילה קובעים היכן וכיצד המערכת תפעל, ולאחר מכן בוחנים כיצד היא תשרת את תהליכי הלמידה.
תיק ראיות להחלטת פריסה: מה צריך לתעד לפני האישור?
לאחר סינון החלופות לפי דרישות הסף, מומלץ לרכז את ממצאי הבחינה בתיק החלטה אחד. מטרתו אינה להוסיף עוד רשימת יכולות, אלא לאפשר להנהלה, לאבטחת המידע, לרכש ולצוותי התפעול לאשר את מודל הפריסה על בסיס אותן הנחות. התיק צריך לקשור בין כל דרישה עסקית לבין ראיה שנבדקה, גורם מאשר וסיכון שנותר לטיפול.
תרחישים שיש להוכיח מקצה לקצה
במקום לבחון רק מסכי מערכת, הגדירו מספר תרחישים מייצגים: קליטת עובד חדש, שינוי תפקיד והרשאות, הפצת הדרכת חובה, עומס זמני, תקלה באינטגרציה, שחזור מידע וסיום התקשרות. לכל תרחיש יש לתעד מה מתרחש ב-Cloud LMS ומה נשאר באחריות הארגון. כך ניתן לזהות תלות נסתרת בתשתית מקומית, בתהליך ידני או בספק צד שלישי.
ראיות ולא הצהרות כלליות
- ארכיטקטורה מאושרת: תרשים זרימת מידע הכולל משתמשים, ממשקים, רכיבי תווך, סביבות וגיבויים.
- בדיקות קבלה: תוצאות מתועדות לתרחישי זהויות, אינטגרציה, ביצועים, שחזור ונגישות, לצד חריגות ותוכנית טיפול.
- בעלות על סיכונים: לכל סיכון שנותר יש להגדיר בעל תפקיד, פעולה מפחיתה, מועד יעד ותנאי הסלמה.
- הנחות עומס: מספר משתמשים פעילים, אירועי שיא, נפח תוכן וקצב גידול משוער, בלי להסתפק במספר החשבונות הכולל.
- תנאי בחינה מחדש: אירועים שמחייבים לפתוח את ההחלטה, כגון שינוי רגולטורי, רכישה ארגונית, מעבר ספק זהויות או גידול חריג.
ציון החלטה שניתן לביקורת
אפשר להשתמש במטריצת ניקוד, אך יש להימנע מציון כולל שמסתיר תנאי פסילה. תחילה מסמנים אילוצים מחייבים; רק החלופות שעברו אותם מקבלות ניקוד משוקלל בתחומים כגון רציפות, שליטה תפעולית, מורכבות אינטגרציה, אבטחה ויכולת יציאה. יש לשמור לצד כל ציון את המקור שעליו הוא מבוסס ואת זהות המאשר.
לאחר אישור מודל הפריסה, יש לבדוק בנפרד את התאמת היכולות הפונקציונליות של מערכת LMS ארגונית. ההפרדה בין החלטת התשתית לבין בחירת הפלטפורמה מונעת מצב שבו יתרון במודל האירוח מפצה בטעות על פער בתהליכי הלמידה, או להפך.
מטריצת החלטה ל-Cloud LMS מול התקנה מקומית
בהיעדר נתוני GSC ייעודיים לעמוד מאז 28/09, אין בסיס לקבוע כי חל שינוי בביצועים. לכן, במקום להסיק מסקנות תנועה, מומלץ לחזק את העמוד בכלי השוואה מעשי: מטריצה שמתרגמת דרישות ארגוניות להחלטת פריסה מתועדת. את המשקל לכל סעיף יש לקבוע יחד עם אבטחת מידע, IT, רכש, משפטים והדרכה.
| קריטריון | Cloud LMS | התקנה מקומית | מה יש לאמת |
|---|---|---|---|
| אבטחה | בקרות מנוהלות וחלוקת אחריות עם הספק | שליטה ישירה, לצד אחריות פנימית מלאה | תקנים, בדיקות, הצפנה וטיפול באירועים |
| ריבונות מידע | תלויה באזור האירוח, בגיבויים ובקבלני משנה | נקבעת לפי תשתיות הארגון וספקיהן | מיקום כל עותקי המידע ותנאי העברתם |
| SSO | חיבור לשירות הזהויות דרך ממשקים נתמכים | גישה ישירה אפשרית לרכיבים פנימיים | SAML או OIDC, הקצאה, ביטול משתמשים וחשבונות חירום |
| זמינות ו-SLA | מדדים חוזיים התלויים גם בקישוריות | תלויה בארכיטקטורה ובצוותי הארגון | אופן המדידה, החרגות, תמיכה והסלמה |
| עדכונים | מנוהלים לפי מדיניות הספק | נשלטים בידי הארגון, המחויב לתחזקם | חלונות שינוי, סביבת בדיקות ותאימות |
| עלויות | דמי שירות, שימוש, התאמות ואינטגרציות | תשתית, כוח אדם, רישוי, גיבוי והתאוששות | TCO רב-שנתי ותרחישי גידול |
| תלות בספק | גבוהה יותר בתפעול ובמפת הדרכים | תלות גבוהה יותר בידע פנימי ובספקי תשתית | יצוא מלא, סיוע במעבר ומחיקה מאומתת |
שאלות RFP שמחדדות את ההשוואה
- אילו רכיבים, גיבויים ולוגים נשמרים מחוץ לישראל, ומי הם קבלני המשנה?
- כיצד מחושב ה-SLA, ומהם זמני התגובה וההשבה בכל דרגת חומרה?
- כיצד מיוצאים קורסים, משתמשים, ציונים, תיעוד השלמות וקובצי מקור בסיום התקשרות?
- אילו עדכונים מחייבים תיאום, ומהו תהליך הבדיקה של אינטגרציות לפני שדרוג?
- מהי חלוקת האחריות במקרה של אירוע אבטחה, כשל SSO או אובדן קישוריות?
FAQ מסחרי
האם Cloud LMS תמיד זולה יותר?
לא. יש להשוות עלות כוללת לפי היקף, תשתיות, כוח אדם, רמת שירות, אינטגרציות ודרישות יציאה.
האם ניתן להתחיל בענן ולעבור בהמשך?
האפשרות תלויה בארכיטקטורה, ברישוי ובניידות הנתונים. יש לעגן אותה מראש בהסכם ובבדיקת יצוא.
איזה מודל מתאים לארגון רגיש?
אין תשובה אחידה. מומלץ לבחון את יכולות מערכת ה-LMS, את דרישות הענף הביטחוני ואת סוגי מערכות ה-LMS, ולאשר את המודל מול הגורמים המקצועיים בארגון.
שאלות נפוצות
מה ההבדל בין Cloud LMS ל-SaaS LMS?
מדובר כמעט באותו דבר. SaaS (Software as a Service) הוא מודל עסקי של רישוי חודשי, ו-Cloud LMS מתאר את התשתית שעליה המערכת רצה. רוב מערכות ה-Cloud LMS מסופקות במודל SaaS.
האם נתונים של ארגון ישראלי בטוחים בענן?
כן, במיוחד כשהנתונים מאוחסנים באזור AWS ישראל. ספקי הענן משקיעים מיליארדי דולרים באבטחה, ורמת ההגנה גבוהה משמעותית ממה שרוב הארגונים יכולים לספק בכוחות עצמם.
כמה עולה Cloud LMS לארגון של 500 עובדים?
טווח המחירים הוא 3,000-15,000 ש'ח לחודש, תלוי בפיצ'רים, ברמת האינטגרציה ובכמות הנתונים. אין השקעה ראשונית משמעותית.
האם אפשר לעבור מ-On-Premise ל-Cloud LMS בלי לאבד נתונים היסטוריים?
בהחלט. תהליך מיגרציה מקצועי כולל העברת קורסים, משתמשים, ציונים והישגים. מגדלור מבצעת מיגרציות מלאות מ-Moodle On-Premise ומפתרונות אחרים תוך שמירה על כל הדאטה ההיסטורית.
מה קורה אם הספק פושט רגל?
עם ספקים מבוססים, זה סיכון נמוך. יחד עם זאת, מומלץ לוודא בחוזה זכות ייצוא מלאה של הנתונים בפורמט תקני (SCORM, xAPI), כדי שתוכלו לעבור לספק אחר במידת הצורך.