הגירה מ-Magento 1 ל-2: מה נשבר בלי תוכנית העברה
חנות על גרסה מיושנת של Magento מחזיקה מעמד עד הקונפליקט הראשון: תוספים לענף הישן מפסיקים לקבל עדכונים, וחלקם כבר לא תואמים לארכיטקטורה החדשה. חיבור מודול תשלום או משלוח חדש הופך למשימה עם מעקף, ותיקוני אבטחה לליבה לא יוצאים — חולשות נסגרות בתיקונים בקוד זר.
תמיכה בגרסה ישנה נתקלת באנשים ובהיעדר סביבת בדיקה. מהנדסים שזוכרים את המבנה שלה הולכים ומתמעטים, התיעוד להתאמות אישיות לרוב חסר, וכל פיתוח מתבצע בלי קונטור בדיקה שמשכפל את הקטלוג וההגדרות בייצור.
נקודת הכשל השנייה — נתונים. ייצוא ידני של הקטלוג וההזמנות יוצר חוסר סנכרון: חלק מהמוצרים עוברים בלי מאפיינים, חלק מאבדים קישורים לקטגוריות, היסטוריית ההזמנות מועברת חלקית. הקונה רואה כרטיס ריק או הזמנה בלי סטטוס — ועובר למתחרה.
השלישית — כתובות. אם העברת חנות מקוונת מתבצעת בלי מפת הפניות, כתובות ישנות של מוצרים ומדורים מחזירות 404, וקישורים שנצברו ומיקומים במנועי החיפוש מתאפסים בתוך שבועות ספורים. לשחזר אותם אחר כך יקר יותר מלבנות סכימת כתובות מראש.
תוכנית העברה מחברת את החלקים האלה לסדר עבודה אחד: ספירת מלאי של תוספים, העברת נתונים עם בדיקת התאמה, מפת כתובות, קונטור בדיקה על עותק של הקטלוג. נבחן כיצד זה נסגר שלב אחר שלב.
מה נותנת ההעברה לפלטפורמה נתמכת: אפקט במספרים
העברה מ-Magento 1 לענף עדכני משנה לא את המראה החיצוני, אלא את התנהגות המערכת תחת עומס. בסכימה הישנה הקטלוג נבנה מכמה שכבות מטמון, וכל שינוי במאפיין מפעיל אינדוקס מחדש מלא: עמוד קטגוריה עם מסננים מגיב לאט יותר ויותר ככל שמספר המוצרים וערכי המאפיינים גדל.
לאחר ההעברה, את השאילתה משרת שכבה מוכנה מראש, האינדקסים נבנים מחדש בחלקים, וזמן התגובה של הקטלוג ברשימות ובמסננים מתקצר פי כמה — והוא לא מדרדר ככל שהמבחר גדל. שילובי מסננים כבדים מפסיקים להיות צוואר בקבוק.
בנפרד משתנה העמידות בפני פרצי עומס: שיא מתפוצת דיוור או מבצע מכירות היה מפיל חלק מהעמודים והסל, כי קריאה וכתיבה התחרו על אותם משאבים. כעת הקריאה מועברת לצמתים נפרדים, הכתיבה עוברת דרך תורים, והפרץ נמתח על פני זמן ולא הופך לכשל.
גם זמן העלאת השינויים מתקצר: עריכת תבנית, הגדרה או בלוק פרומו, במקום העלאה ידנית לשרת, עוברת לפרודקשן במעבר אחד, וחזרה לגרסה קודמת מחזירה את המצב התקין בלי לפרק קבצים ידנית.
אינדוקס, חימום מטמון ובניית סטטיקה מתבצעים לפי לוח זמנים, ולכן חלק הפעולות הידניות יורד — יחד עם סוג הכשלים שבהם עדכון של מודול צד שלישי דרס את התבנית או שבר את תהליך ביצוע ההזמנה.
אפשרויות הגירה מ-Magento 1 ל-2: השוואת גישות
הבחירה באפשרות ההעברה נקבעת לא לפי גודל הקטלוג, אלא לפי חלון אי-זמינות מותר של החנות ונפח הלוגיקה המותאמת אישית. Magento 1 ו-Magento 2 הם ליבה, מבנה בסיס נתונים ושכבת תבניות שונים, ולכן מודולים ותבניות לא מועברים בהעתקה, אלא בכתיבה מחדש לארכיטקטורה החדשה. מכאן שלושה תרחישי עבודה עם מחיר מעבר שונה.
| אפשרות | מתי מתאימה | חלון זמן השבתה | מגבלות הגישה |
|---|---|---|---|
| העברה בבת אחת | קטלוג קומפקטי, מינימום שינויים, השבתה של כמה שעות מקובלת | מלא, עד יממה | הכל מועבר בהרצה אחת; שגיאות במאפיינים, בקישורים ובכללי מחירים צפות כבר בחנות החיה, וחזרה אחורה משפיעה על כל מערך הנתונים |
| הגירה מדורגת עם חנות מקבילה | קטלוג גדול, הזמנות ותעבורה ממשיכות ברצף | כמעט אפסי, השבתה רק במעבר הסופי | נדרש סנכרון קבוע של הזמנות, לקוחות ומלאי בין המערכות; כפול בדיקות וקשה יותר להתאים כתובות SEO |
| העברת חזית בלבד תוך שמירה על חלק השרת | הלוגיקה והאינטגרציות קשורות לליבה הישנה, שאין לעצור | מינימלי, למעבר החזית | שתי מערכות חיות זמן רב: חלק מהנתונים מגיע מהשכבה החדשה, חלק מהליבה הישנה, וכל שינוי נוגע בשני הצדדים |
המחיר של האצה תמיד עובר למקום אחר. בחנות מקבילה זה עלות הסנכרון והבדיקות הכפולות, ובהעברה בבת אחת — הסיכון לשחזור ממושך בעת תקלה. את הגישה קובעים לאחר ספירת מלאי של מודולים ומדידות עומס על המערכת הנוכחית, אחרת הבחירה נשארת תיאורטית.
שלבי ההעברה: ביקורת, סכימת נתונים, הגדרה, בדיקה
המעבר מ-Magento 1 ל-2 הוא לא התקנה מחדש, אלא העברת נתונים שעליהם תלויה פעילות החנות: קטלוג עם היסטוריית מחירים, הזמנות מכמה שנים, לקוחות עם כתובות והנחות. אין במה לשחזר אותם לאחר אובדן, ולכן העבודות מתבצעות בשלבים, וכל שלב מתחיל לאחר קבלת השלב הקודם.
- ביקורת נתוני החנות. עורכים ספירת מלאי של הקטלוג, ערכות וערכי מאפיינים, קטגוריות, לקוחות, ספרי כתובות, הזמנות, כללי מחירים ועמודים סטטיים: מחשבים נפחים, מוצאים כפילויות, קישורים שבורים לתמונות ונתונים שאין צורך להעביר.
- סכימת התאמה של ישויות. מרכיבים טבלה של «מאפיין-מקור → מאפיין-יעד» עם סוג הערך, חובה וקבוצת המאפיין. בנפרד מתארים סטטוסי הזמנות, קבוצות לקוחות וסוגי כתובות — אי-התאמות כאן יוצרות אובדנים בהעברה.
- הגדרת הסביבה. פורסים את הפלטפורמה ביעד על הענף העדכני: שפה, מסד נתונים, שירות חיפוש, מטמון ותורי הודעות; מגדירים אינדוקס וקונטורים נפרדים לפיתוח ולחזרה על ההעברה.
- הרצת ניסיון על עותק. מעבירים נתונים לעותק מלא של מסד הנתונים וקובצי המדיה, מודדים זמן ומשאבים, תופסים שגיאות סוגים וקידודים. בדרך כלל יש שתי הרצות: אחרי הראשונה סכימת ההתאמה מתחדדת.
- התאמת נתונים לאחר ההעברה. משווים את מספר הרשומות בכל ישות, באופן מדגמי — מחירים, מלאי, היסטוריית הזמנות, שיוך כתובות ותמונות, בודקים הפניות של קישורים ישנים.
- מעבר ותמיכה. מדביקים את תוספת הנתונים, משנים ניתוב, מפעילים ניטור, עוקבים אחר אינדוקס ועבודת הסל; בשלב ראשון משאירים את הגרסה הקודמת זמינה לחזרה לאחור.
ארטיפקטים נמסרים: קונפיגורציות, סכימות נתונים, נהלים
מסירת הגירה מ-Magento 1 ל-2 היא לא רק אתר עובד, אלא גם סט של ארטיפקטים שלפיהם הצוות שלכם ימשיך להוביל את הפרויקט בלעדינו. הכל מועבר למאגר לצד הקוד: קבצים מנוהלים בגרסאות, שינויים עוברים ביקורת, ולא חיים בהתכתבויות ובזיכרון של אנשים בודדים.
- קונפיגורציות של קונטורים — פרמטרים של סביבת בדיקה וסביבת ייצור, משתנים, סדר בנייה: עותק מקומי של הפרויקט עולה לפי הוראות בהרצה אחת.
- מפת העברת נתונים — התאמת «מקור → יעד» עבור מוצרים, קטגוריות, הזמנות, לקוחות וביקורות, כללי המרה והתנהגות בהרצה חוזרת.
- מדיניות גישה והפרדת תפקידים — מטריצת הרשאות בממשק הניהול, מי יכול לשנות את הקטלוג ולייצא נתונים, סדר מתן וביטול גישות.
- כללי טיפול בכתובות — מפת הפניות קבועות מקישורים ישנים, סדרי עדיפויות בקונפליקטים, יומן כתובות שבורות לאחר המעבר.
- נוהל עדכונים — ענפים, חלונות שחרור, סדר החלת עדכוני פלטפורמה ותוספים, נקודות חזרה למצב העבודה הקודם.
- הוראות לצוות — פריסה, היכן לצפות ביומנים, כיצד לבצע חזרה אחורה, מה לעשות בעת תקלה, בתוספת רשימת בדיקה לקבלת שלבים בתרחישי מפתח.
מקרה בוחן של העברה: הקטלוג וההזמנות עברו בלי לאבד מיקומים
חנות עם קטלוג של כ-12 אלף פריטים והיסטוריית הזמנות מכמה שנים עבדה על Magento 1 — היה צריך לסחור בלי עצירה, ולכן העברת הקטלוג, הלקוחות וההזמנות הוכנה מראש, והמעבר של החנות בוצע בחלון קצר של תעבורה נמוכה.
מה שינו
הקטלוג הועבר דרך סכימת התאמה של מאפיינים: ערכות ישנות פוזרו לפי החדשות, וקשרי המוצרים נבנו מחדש לפי מזהים חיצוניים, ולא לפי שמות — אחרת ערכות ומקושרים היו מתפרקים.
היסטוריית ההזמנות הועברה תוך שמירה על הקשר «לקוח — הזמנה — פריטים», סטטוסים והערות מנהלים נשארו קריאים באזור האישי, ולא הפכו לדאמפ ארכיוני.
בנפרד עסקנו בשימור כתובות העמודים: 96% מהכרטיסים והקטגוריות נשארו במתכונתם הקודמת, והשאר נסגרו בהפניה קבועה לפי מפת ההתאמות — סריקת רובוטים של מנועי חיפוש לא נתקלה במבויים, וקישורים חיצוניים שנצברו המשיכו להוביל לאותם מוצרים.
מדדים לפני ואחרי
זמן התגובה של הקטלוג בעומס שיא התקצר משניות לחלקיקי שנייה: תצוגת תוצאות עם מסננים הפסיקה "להיתקע" בעת דפדוף. עדכון המבחר ממחירון הספק היה פעם גוזל שעות של עריכות ידניות לכל קבוצה — כעת זו פעולת ייבוא אחת עם בדיקת אי-התאמות.
ביממה הראשונה לאחר המעבר החנות עבדה עם תעבורה בשיא בלי כשלים בסל ובביצוע ההזמנה, ולא תועדו אי-התאמות בין המלאי להזמנות שהתקבלו.
מה לעשות אם חלק מהנתונים כבר הועברו ידנית?
להתחיל את ההגירה מחדש, אם מחצית מהקטלוג כבר הועברה בכוחות עצמכם, יקר יותר מאשר לאחד שני בסיסי נתונים. תחילה קובעים מקור אמת לכל סוג של ישות: קטלוג ותוכן מנוהלים במערכת החדשה, הזמנות והיסטוריית לקוחות עד לרגע המעבר נשארים בישנה.
כפילויות מחפשים לא לפי מזהים פנימיים — ב-Magento 1 ו-Magento 2 הם אינם קשורים זה לזה — אלא לפי מפתחות טבעיים: מק"ט, מפתח URL, שיוך לספק. לפיהם נבנית מפת התאמה «מזהה ישן — חדש», והיא הופכת לעבודה לכל העמסת הנתונים העתידית.
מסובך יותר עם קשרי מוצרים וקטגוריות. בהעברה ידנית פריט נכנס לקטלוג, אבל מאבד שיוך לערכות מאפיינים, ערכי מפתחים ותמונות: המוצר נמצא בבסיס הנתונים, אבל במסננים ובחנות הוא לא. קשרים אלה משחזרים לפי מפת ההתאמה, ולא במילוי חוזר ידני.
הזמנות מתקופת המעבר — סיכון נפרד. אי אפשר להוסיף אותן כרשימה: נשברת המספור הרציף, היסטוריית הסטטוסים והקישור לחשבונות הקונים. לכן חיתוך נלקח לרגע המעבר ומועבר באופן אינקרמנטלי, עם דה-דופליקציה לפי מספר הזמנה ותאריך ביצוע.
העמסת נתונים נוספת נעשית אידמפוטנטית: הרצה חוזרת לא יוצרת כפילויות ולא מכפילה מלאי. את התוצאה בודקים בהתאמה — מספר הפריטים, שיעור המוצרים בלי קטגוריה, הזמנות שנשארו בלי שיוך ללקוח. אי-התאמות בהעברה חלקית נראות לפני ההרצה, לא אחריה.
תאימות תוספים, אינטגרציות וכתובות עמודים
לפני ההתחלה, הלקוח בדרך כלל חושש לא מהנתונים, אלא משלושה דברים: תוספים שלא עובדים בענף החדש של הפלטפורמה, אינטגרציות עם המחסן והתשלום, וכתובות עמודים שנצברו מתעבורת חיפוש.
סדר העבודות כאן הפוך מהרגיל: תחילה ספירת מלאי של מודולים ומפת כתובות, אחר כך העברת תוכן — אחרת יהיה צורך לעבד מחדש את הקטלוג והמדורים פעמיים.
העברה מ-Magento 1 לענף העדכני של הגרסה השנייה מתבצעת לפי פונקציונליות, ולא לפי שמות מודולים: עבור כל תוסף קובעים איזו משימה הוא פותר, איזה חלק מהתרחישים באמת בשימוש והאם יש תחליף מוכן.
את השאר סוגרים בפיתוח דרך מנגנון ההרחבה התקני או במודול נפרד, כדי שעדכוני הפלטפורמה לא ישברו את הלוגיקה.
לתוסף אין מקבילה בענף החדש — מה אז?
בודקים איזו חלק מהפונקציונליות נחוץ בפועל: לעתים קרובות מתוך המודול משתמשים בתרחיש אחד-שניים מתוך עשרה, והם נסגרים בפיתוח דרך מנגנון יירוט תקני בלי לערוך את הליבה. אם הלוגיקה עמוקה יותר, כותבים מודול משלנו עם כיסוי בבדיקות — הוא מועבר יחד עם הפלטפורמה ולא חוסם עדכונים.
כיצד עוברות אינטגרציות עם המחסן והתשלום?
את החילוף מוציאים לשכבה נפרדת: הפלטפורמה פונה אליה דרך ממשקים תקניים, ומערכות חיצוניות — דרך ממשק תוכנה לחילוף. הזמנות ומלאי מסונכרנים עם הגנה מפני עיבוד חוזר, יומן ושליחות חוזרות, כך שכשל בצד אחד לא יגרום לחיובים כפולים. לפני העברת התעבורה מריצים את שני הצדדים בקונטור בדיקה על עותק נתונים.
האם כתובות העמודים ומבנה המדורים נשמרים?
מורידים מפת כתובות של האתר הישן, משווים אחד לאחד עם המבנה החדש ומוסרים בהפניות קבועות — בלי שרשראות של כמה מעברים. קטגוריות, מסננים, חלוקה לעמודים ומפת האתר מקבלים כללים נפרדים.
לאחר המעבר משווים את הייצוא מפאנל כלי הניהול של מנוע החיפוש: מנוע החיפוש צריך לראות את הכתובות החדשות, ולא שגיאות.
נדון במשימה: ממה מתחילה העברת החנות
הדיון במשימה מתחיל לא בהערכה, אלא בספירת מלאי: כמה מוצרים, מאפיינים ווריאציות יש בחנות, אילו תוספים ותיקונים בליבה מחזיקים את לוגיקת המכירות, וכיצד בנויות האינטגרציות.
בלי נתוני פתיחה אלה, הערכת נפח העבודה הופכת לניחוש, ותוכנית ההעברה נשברת כבר במודול הלא-סטנדרטי הראשון — לכן את השיחה על העברה מ-Magento 1 לענף עדכני מנהלים במישור העובדות.
מה צריך להכין לדיון:
- ייצוא קטלוג: מספר מוצרים, קטגוריות, מאפיינים ווריאציות;
- רשימת תוספים, תבניות ושינויים בליבה — עם ציון מה קריטי למכירות;
- אינטגרציות: מחסן, מערכת חשבונאית, שירותי משלוחים, שערי תשלום, דיוורים;
- מבנה הכתובות והכללים ליצירתן — בסיס למפת ההפניות;
- דוח תעבורה ונקודות כניסה מחיפוש בשנה האחרונה;
- גישות לשרתים, למאגרים ולפאנלים, מגבלות חלון ההעברה;
- תהליכים שאסור לעצור: הזמנות, ייצוא מחירונים, מלאי.
בתום השלב הראשון תקבלו תוכנית העברה עם פירוט לפי עבודות, מפת נתונים וכתובות, רשימת סיכונים וסדר בדיקות. אם חלק מהנתונים אינו זמין, ציינו זאת כבר בהתחלה — נדייק את הרכב נתוני הפתיחה ונחזור עם הערכת נפח העבודה. בהמשך נתאם לוחות זמנים והרכב צוות ונתחיל בהעברת ניסיון לקונטור בדיקה.
