העברת אתר מ-Magento לביטריקס: היכן אובדים הנתונים
העברת אתר מ-Magento לביטריקס אינה העתקה של בסיס נתונים וקבצים, אלא הרכבה מחדש של הקשרים בין הישויות. ב-Magento המוצר, הווריאציות שלו וערכי המאפיינים יושבים בטבלאות נפרדות המחוברות זו לזו לפי מזהים; בביטריקס אותו מבנה נבנה מאלמנטים של בלוק מידע, מהצעות מסחר וממאפיינים.
כל עוד לא הוגדר מיפוי ברמת הסכימה, העברת החנות האינטרנטית מסתיימת בהצלחה פורמלית — ומתפרקת ברגע שיש תנועה אמיתית.
הראשון שנופל הוא הכתובת. הקטלוג של Magento מציג נתיבים קריאים לבני אדם, פילטרים ועימוד כעמודים נפרדים, ודפי נחיתה ממותגים חיים במדורים אחרים.
בלי מפת הפניות שנבנתה לפני המעבר, כרטיס המוצר מקבל כתובת חדשה והכתובת הישנה מחזירה שגיאה — ואלה בדיוק כתובות העמודים השגויות שאחרי ההעברה: קטגוריות נושרות מהאינדקס, קישורים חיצוניים ומודעות מובילים לשום מקום.
בהמשך מגיעות שגיאות העברת הקטלוג. מאפיינים כמו צבע או מידה עוברים כטקסט חופשי בלי קישור לטבלאות עזר: הפילטרים מפסיקים להיבנות, וההשוואה מציגה שדות ריקים. שיוכים מרובים של מוצר למדורים מתכווצים לשיוך אחד, וחלק מדפי הנחיתה פשוט נעלמים.
בנפרד מתפצלים גם היתרות לפי מחסנים והיסטוריית ההזמנות: פריטים מפנים למוצרים שלא קיימים, והלקוח רואה הזמנה בלי הרכב.
אובדן נתונים בהעברה כמעט תמיד מעיד על כך שההעברה החלה מהמוצרים ולא ממודל הנתונים. להלן איך סוגרים את זה: קודם סכימת המיפוי, אחר כך הקטלוג, ההזמנות והכתובות, ורק לאחר בדיקת התאמה — החלפת הדומיין.
מה מפסיק להישבר לאחר העברת הקטלוג וההזמנות
העברת קטלוג המוצרים נשברת לא בגלל הנפח אלא בגלל הקשרים. המוצר, הצעות המסחר שלו וערכי המאפיינים הם שלוש קבוצות נתונים המחוברות לפי מזהים; בהעברה ישירה "בכוח" ההצעות מאבדות את הקישור למוצר האב, והפילטרים בקטלוג מתחילים להציג ערכים ריקים.
לכן הסדר נוקשה: קודם טבלאות העזר של המאפיינים, אחר כך המוצרים, ואחר כך הצעות המסחר — עם בדיקת תקינות בכל שלב.
שימור היסטוריית ההזמנות הוא נקודת הכשל השנייה. הזמנה שומרת לא רק סטטוס וסכום, אלא גם הרכב עם קישור להצעה מסוימת כפי שהייתה ברגע הרכישה. אם הקשר לא משוחזר, הלקוח רואה באזור האישי שורות ריקות, ואין דרך להרכיב הזמנה חוזרת מתוך ההיסטוריה.
אנחנו מעבירים הזמנות עם הסטטוסים והפריטים, ולמוצרים שירדו מהמדף שומרים רשומות ארכיוניות — כך ההיסטוריה נשארת קריאה.
ייצוא ההזמנות אל מערכת החשבונאות מפסיק להיות ידני. הסנכרון רץ לפי לוח זמנים באמצעות התאמת פריטים לפי מפתחות חיצוניים: ההזמנות נשלחות לחשבונאות, הסטטוסים והיתרות חוזרים בחזרה, ושליחה חוזרת אינה יוצרת כפילויות. בצד 1C-Bitrix זה נעשה בכלי הסנכרון המובנים, בלי מתווכים בהתאמה עצמית שנופלים כבר בעדכון הראשון.
את התוצאה בודקים בקבלה: שיעור הפריטים עם מאפיינים מלאים, מספר ההזמנות שאיבדו את הקשר להרכב, ונפח התיקונים הידניים בשבועות הראשונים. אלה המדדים שקובעים אם העברת הקטלוג וההזמנות הושלמה עד הסוף — ולא "בעיקרון".
דרכים להעברת הקטלוג וההזמנות: השוואת גישות
הקטלוג וההזמנות מועברים עם מחיר שונה לטעות. מוצרים, מאפיינים ושיוך למדורים אפשר להרכיב מחדש, אבל את היסטוריית ההזמנות — לא: סטטוסי התשלום, הרכב הסל והקשר ללקוח משוחזרים רק מתוך הייצוא.
לכן בוחרים את השיטה לפי שני צירים — זמן ההשבתה המותר למכירות, ונפח הפיתוחים המיוחדים שהצטברו בצד Magento.
ארבעה תרחישים שימושיים
| שיטה | מתי מתאימה | מגבלות |
|---|---|---|
| ייצוא מלא של בסיס הנתונים עם השבתה | קטלוג של כמה אלפי פריטים, חלון ההשבתה מתואם עם העסק | האתר סגור לכל משך ההעברה, הזמנות מחלון ההשבתה אובדות, והרצה חוזרת מתחילה מאפס |
| העברה מדורגת לפי מדורים | קטלוג גדול, נדרשת בדיקה של כל מדור לפני העלאה | לוקח יותר זמן בלוח השנה, צריך לתפוס עריכות שממשיכות להיכנס לקטלוג הישן |
| עבודה מקבילה של שני אתרים | אי אפשר לעצור מכירות, יש סנכרון יתרות מול 1C | שני מקורות אמת ליתרות ולמחירים — צריך כללי התאמה, יקר יותר בתחזוקה |
| הרכבה ידנית של הקטלוג מחדש | הקטלוג קטן ומבולגן, נדרשת סקירת מלאי | הזמנות ולקוחות עדיין מועברים בייצוא, ותיאורים וקישורים פנימיים שנצברו לא נשמרים |
בפועל לרוב לוקחים שילוב: הקטלוג עובר לפי מדורים עם בדיקת התאמה ביניים, ההזמנות והלקוחות — בייצוא אחד בחלון קצר, והתנועה מופנית מחדש בכתובות קבע מהכתובות הישנות. להלן מהם השלבים שמרכיבים את זה.
סדר העבודה: מביקורת המבנה ועד העברת ההרשאות
ההעברה בנויה כרצף שבו כל שלב נשען על התוצר של השלב הקודם: אם מדלגים על אחד, הפערים בקשרים צפים רק אחרי ההשקה, כשהקטלוג וההזמנות מתחילים לחיות בנפרד.
אנחנו מתחילים בביקורת של מבנה האתר — מרכיבים מפה של מדורים, סוגי עמודים, מאפייני מוצרים ומאפייני משתמשים, ובנפרד מתעדים פיתוחים לא סטנדרטיים. במקביל מצלמים פרוסה של הפניות אמיתיות לבסיס הנתונים, כדי לחשב עומס לפי המצב בפועל ולא לפי התיאור.
- ספירת מלאי של הנתונים. מייצאים קטלוג, הזמנות, לקוחות, תוכן וקבצים, ומשווים את מספר הרשומות בכל סוג: פער אפילו של כמה פריטים מסמן אובדן בייצוא.
- תכנון סכימת הקשרים. מתארים איזו ישות ביעד מקבילה למקור, איך מועברים שיוכים מרובים, הצעות מסחר וכתובות ישנות. סכימת העברת הנתונים מאושרת לפני תחילת העבודה — תיקון בשלב הזה זול יותר מעבודה מחדש אחרי ההשקה.
- הגדרת ההעברה והסנכרון עם מערכת החשבונאות. מתאימים מפתחות של מוצרים ושל צדדים קשורים, קובעים תדירות וכללי עדיפות, כדי שהיתרות וההזמנות לא יוכפלו בסנכרון.
- בדיקת התאמה אחרי ההעברה. משווים לא רק נפחים, אלא גם סכומי ביקורת לפי פריטים, את שיוך התמונות, ואת תקינות הכתובות וההפניות מחדש מהעמודים הישנים.
- הרצת תרחישים בסביבה סגורה. עוברים על חיפוש, פילטרים, ביצוע הזמנה ואזור אישי, ומתעדים חריגות לפני פתיחת הגישה לציבור.
- העברת הרשאות ותיעוד. מוסרים מפת התאמות, נהלי סנכרון, הוראות ייצוא ורשימת חשבונות עם חלוקת תפקידים — כך שהתמיכה ממשיכה לעבוד בלעדינו.
מה מקבל הלקוח בסיום ההעברה
ההעברה היא לא רק נתונים שעברו למערכת החדשה. אחרי הקבלה נשאר לצוות שלכם סט מלא שלפיו אפשר לפתח ולתחזק את האתר בכוחות עצמכם: מפת הקשרים של הקטלוג, כללי הפניה מחדש, סנכרון מוגדר עם מערכת החשבונאות ונהלי עבודה.
- מפת הקשרים של הקטלוג — התאמה של מדורים, מוצרים, מאפיינים ומדיה בין המבנה הישן לחדש: רואים מאין הגיע כל פריט ומה קרה לו בהעברה.
- כללי הפניה מחדש — טבלה של כתובות ישנות וחדשות עם הפניות קבועות, כולל עמודי קטגוריות ועמודי כרטיסי מוצר, כדי שתנועת החיפוש לא תיפול אחרי החלפת הפלטפורמה.
- סכימת האינטגרציה עם מערכת החשבונאות — אילו טבלאות עזר, מחירים, יתרות וסטטוסי הזמנות מסונכרנים, באיזה כיוון ובאיזו תדירות, ואיפה בודקים את יומן הסנכרון כשמתגלה פער.
- הרשאות גישה למנהלים — תפקידים בחלוקה לפי מדורים בלוח הבקרה: מי עורך את הקטלוג, מי את המחירים, מי את ההזמנות, ולמי יש גישה להגדרות ולייצוא.
- נוהל גיבוי — מה מגבים, באיזו תדירות, כמה זמן נשמר, ובאיזה סדר מבוצע שחזור עם בדיקה בסביבת טסטים.
- מדריך לעורך התוכן — תרחישים צעד אחר צעד: להוסיף מוצר, לסדר תמונות, לפרסם עמוד, לעדכן באנר — בלי לשבור את התבנית.
- תיעוד האתר — הרכב המודולים, ההגדרות המרכזיות, נקודות האינטגרציה ויומן השינויים, כדי שפיתוחים נוספים לא יתחילו מלימוד קוד של מישהו אחר.
אנחנו מוסרים את החבילה לא כ"תיקייה על הדיסק" אלא עם קבלה מסודרת: המהנדס עובר על כל סעיף יחד עם הצוות שלכם, מציג את ההגדרות בממשק ועונה על שאלות. חודש אחרי ההשקה אנחנו משווים את יומני הסנכרון ואת האינדוקס — פערים שנמצא מתקנים במסגרת האחריות.
מקרה בוחן: העברת חנות תוך שמירה על מיקומים בחיפוש
חנות על Magento עם 4,300 פריטים ו-620 מדורי קטלוג עבדה עם ייצוא יתרות בלילה וחלק מהעמודים כפולים. הבעלים רצה העברת חנות בלי לאבד את ההיסטוריה שנצברה בחיפוש — במשך השנים הקטלוג צבר מיקומים על 2,800 שאילתות.
מה עשינו
את העבודה חילקנו לארבעה מעברים: סכימת מדורים ומפת כתובות, אחר כך העברת המבחר, לאחר מכן מאפיינים ומחירים, ולבסוף הזמנות והיסטוריית לקוחות. את הכתובות הישנות יחד עם פרמטרי הפילטרים הזנו לטבלת התאמות עם 3,400 כללים והשווינו אותה לייצוא ממערכת האנליטיקס.
לוח הזמנים להעברת הקטלוג — שלושה שבועות, ועוד שבוע הלך על בדיקת התאמה ותיקון של 118 פערים במאפיינים. הסביבה הישנה עבדה במצב קריאה בלבד עד לאישור ההתאמה, כדי שהחזרה לאחור תיארך שעות.
התוצאה במספרים
מספר העמודים עם שגיאות סימון ירד ל-1.4% לעומת 18% לפני המעבר, והכפילויות נסגרו. עיבוד הזמנה בממשק הניהול התקצר מ-40 ל-9 שניות, ועדכון היתרות רץ כל 15 דקות במקום ריצה לילית.
המעבר בלי ירידה בתנועה אושר: 94% מהכתובות שמרו על מיקום בעשירייה הראשונה, והחנות חזרה לנתונים המקוריים בתוך שבועיים מההחלפה. המבחר הועבר במלואו — בדיקת התאמה לפי ברקודים לא מצאה אובדן באף פריט.
מה עושים אם חלק מהקטלוג כבר הועבר לביטריקס
אם הקטלוג הועבר בחלקים או שחלק מהעמודים נבנו מחדש, הנתונים בשתי המערכות מתפצלים: אותו מוצר קיים גם בבסיס הישן וגם בקטלוג החדש, אבל עם מחירים, תיאורים וכתובת עמוד שונים.
ייצוא חוזר במקרים כאלה לא מעדכן את הפריט אלא יוצר כרטיס שני — כך נוצרות כפילויות מוצרים בקטלוג, כתובות אבודות ותיקון ידני שנפחו גדל עם כל הרצה חדשה. קטלוג שהועבר חלקית מסוכן בדיוק בגלל זה: הוא נראה מוכן עד שמתחילים להוסיף לו תוכן.
קודם כל מקבעים מפתח התאמה. שם המוצר וכתובת העמוד לא מתאימים לכך — אותם משנים בעיצוב מחדש ובניקוי טקסטים. סימן יציב הוא מק"ט יחד עם הקוד החיצוני של הרשומה מהמנוע הישן; אותו שומרים כמאפיין נפרד של הכרטיס, גם אם הוא לא מוצג בשום מקום באתר.
אז השלמת העברת הנתונים רצה במצב עדכון לפי המפתח: פריטים קיימים מתמלאים, חדשים נוספים, וכפילויות לא נוצרות.
מכאן מתחילה העבודה עם המורשת של המנוע הישן. חלק מהפריטים כבר ירדו מהמדף, חלק מהכתובות מובילות למדורים שנמחקו, ונצברו ביקורות וקישורים חיצוניים. לכך בונים מפת התאמות: כתובת ישנה מול חדשה, מוצר שירד מהמדף — עמוד המדור האב או הפניה מחדש. בלי המפה תקופת המעבר מותירה קישורים שבורים ותנועה שנופלת בשאילתות מיתוגיות.
כל עוד שתי החנויות פעילות, הסנכרון בין שני האתרים נעשה חד-כיווני ולפי דלתא. מחירים, יתרות וסטטוסי מלאי מיוצאים מהמערכת הישנה לחדשה לפי לוח זמנים, והשינויים של העורכים נכנסים רק לקטלוג החדש. סנכרון דו-כיווני במצב כזה כמעט תמיד יוצר התנגשויות גרסאות ומוחק את העבודה הידנית של עורכי התוכן.
לפני כיבוי המקור עורכים בדיקת התאמה: מספר הפריטים לפי מדורים, השוואה מדגמית של מחירים ומאפיינים, ודוח על רשומות בלי בן זוג. הסנכרון חייב להיות ניתן לחזרה — הרצה שנייה לא משנה דבר אם הנתונים לא השתנו. אחרי בדיקת ההתאמה נשארת נקודת כניסה אחת: הכתובת הישנה עוברת להפניה מחדש, והקטלוג חי במקום אחד.
ספקות טכניים נפוצים לפני תחילת ההעברה
הספקות לפני העברה נוגעים בדרך כלל לא למעבר עצמו, אלא למה שנשבר אחרי הפעלת האתר החדש: כתובות, כניסת לקוחות וסנכרון עם מערכת החשבונאות.
להלן תשובות הנדסיות לשאלות שעולות לרוב בשלב האמידה: מה מועבר אוטומטית, איפה נדרשת בדיקת התאמה ידנית, ואיך בנויה החזרה לאתר הישן כל עוד הסביבה החדשה לא הוכיחה יציבות.
מה יקרה לכתובות העמודים אחרי ההעברה?
מרכיבים מפת התאמה "כתובת ישנה → חדשה" לכל המדורים, המוצרים והמאמרים, ולא רק ברמה העליונה. בסביבה החדשה מגדירים הפניות קבועות, מפת אתר וניטור שגיאות ביומן: בשבועות הראשונים עוקבים אחרי אילו כתובות עדיין מבוקשות ממקורות חיצוניים ומוסיפים כללים בהתאם. כך התנועה שנצברה עוברת יחד עם הקטלוג ולא הולכת לאיבוד על קישורים שבורים.
איך מועברים נתוני הלקוחות וההזמנות שלהם?
פרופילים, כתובות משלוח, היסטוריית הזמנות ושיוך לקבוצות הנחה מועברים במלואם. סיסמאות נשמרות בצורה חד-כיוונית ואינן ניתנות להעברה בין פלטפורמות — לכן שולחים ללקוחות הודעה על החלפת סיסמה, ולמשך תקופת המעבר משאירים מסלול שחזור גישה נוח. הזמנות וסטטוסים נשמרים עם התאריכים המקוריים, כדי שהדוחות לא יתפצלו.
אפשר להעביר את הקטלוג בחלקים?
כן, ובקטלוגים גדולים זו גם דרך אמינה יותר. מפצלים את ההעברה לפי מדורים או מותגים, וכל בלוק מריצים בנפרד: מאפיינים, מחירים, יתרות, תמונות. כל עוד חלק מהעבודה בעיצומה, האתר הישן ממשיך לשרת את הלקוחות, וההחלפה מתבצעת לפי בלוקים שמוכנים. כך שגיאה במדור אחד לא חוסמת את ההשקה של כל הפרויקט.
מה עושים עם המאפיינים והצעות המסחר?
מפרקים את מבנה המאפיינים מראש: מה יהפוך למאפיין של המוצר ומה להצעה נפרדת עם מחיר ויתרה משלה. ערכים מרובים, יחידות מידה ופילטרים מועברים יחד עם הנתונים, אחרת הפילטר החכם באתר החדש יתחיל להציג תוצאות ריקות. בנפרד בודקים את הצימודים "מוצר — הצעה", כי בדיוק עליהם הקטלוגים נוטים להיפרד.
איך יתנהל הסנכרון עם מערכת החשבונאות אחרי ההעברה?
ב-1C-Bitrix את הסנכרון מגדירים בכלים המובנים: קובעים מהו מקור האמת למחירים, ליתרות ולהזמנות, מציבים לוח זמנים לייצוא ומתעדים פערים ביומן. הרצת בדיקה של הסנכרון נעשית לפני פתיחת האתר — בה רואים אילו קבוצות מוצרים נושרות ואיך מתנהגת מערכת החשבונאות תחת עומס.
נדבר על משימת ההעברה של החנות שלכם
כדי לדון במשימת ההעברה באופן ענייני אנחנו צריכים גישה לתמונה אמיתית של החנות, ולא לתיאור מפי השמועה. העתק של בסיס הנתונים, ייצוא הקטלוג ורשימת ההרחבות אומרים על היקף העבודה יותר מכל תיאור: מיד רואים איפה הלוגיקה נשענת על פיתוחים לא סטנדרטיים ואיפה הכול נפתר בכלים המובנים.
מהלקוח, לצורך האמידה, בדרך כלל מספיק הסט הבא:
- גישות ללוח הבקרה והעתק עדכני של בסיס הנתונים — עליו בודקים את שלמות הקשרים בין מוצרים, הזמנות ולקוחות.
- מבנה הקטלוג: קטגוריות, מאפיינים, וריאציות של מוצרים, כללי מחירים והנחות.
- רשימת האינטגרציות עם המחסן, שירותי סליקה, חברות משלוחים, ניוזלטרים ומערכות חשבונאות.
- רשימת התרחישים הלא סטנדרטיים: אזורים אישיים, מחירוני סיטונאות, תוכניות נאמנות, חישוב משלוח.
- כתובות מוגדרות וכללי הפניה מחדש — כדי שהמיקומים בחיפוש לא ייפלו אחרי ההחלפה.
- נתוני אנליטיקס מכמה חודשים: אילו מדורים ותרחישים נושאים את עיקר העומס.
בתגובה אנחנו שולחים תוכנית עבודה להעברה: שלבים, התאמה בין הישויות של הפלטפורמה הישנה והחדשה, מה עובר אוטומטית ומה דורש בדיקת התאמה ידנית. בנפרד מתעדים סיכונים, סדר החזרה לגרסה הקודמת, ואפשרות לתמיכה באתר אחרי ההעברה — נוהל עדכונים, ניטור זמינות וטיפול בפניות. תארו את המשימה ואשלחו את מה שפירטנו — נחזור עם אמידת לוחות זמנים להעברה ותוכנית ברורה.