מודרניזציה של מערכות ישנות

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

הטעות הקלאסית היא שכתוב מלא: צוות חדש מבלה 18 חודשים בבנייה של המערכת הישנה בסטאק מודרני, העסק ממשיך להשתנות, השכתוב לעולם לא מדביק את הפער ובסוף הוא מבוטל. אנחנו משתמשים בדפוס "עץ החנק" (strangler-fig) במקום זאת — שמים את המערכת הישנה מאחורי שער API מודרני, בונים תכונות חדשות כמיקרו-שירותים עצמאיים לצדה, ומקלפים תכונות ישנות אחת אחת. העסק רואה שיפור רציף מהשבוע הראשון, ואין אף פעם יום מעבר מפחיד.

מה אנחנו מודרניזים הכי הרבה

פרויקטי מודרניזציה טיפוסיים כוללים: עטיפה של ERP עתיק או מערכת חיוב עם API REST/GraphQL נקי כדי שפרונט-אנד מודרני וסוכני AI יוכלו לדבר איתם; החלפת אינטגרציות מבוססות קבצים או FTP בצינורות מבוססי אירועים; הגירה של בסיסי נתונים מקומיים ל-Postgres מנוהל בשכפול ללא השבתה; בנייה מחדש של אפליקציות דסקטופ ישנות כאפליקציות ווב פרוגרסיביות שעובדות בטלפון ובדפדפן; הצגת צינור CI/CD, כיסוי בדיקות וצפייה בקוד שלא היו לו קודם.

איך אנחנו מורידים סיכון בהגירה

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

מיומנויות והעברת בעלות

מערכות מדור קודם חיות לעיתים קרובות על סטאקים שהצוות הנוכחי שלכם לא רוצה ללמוד — .NET ישן, PL/SQL, Delphi, AS/400, C עם Makefiles. אנחנו מגיעים עם אנשים שכן, אבל כל פרויקט מודרניזציה גם כולל תיעוד, דיאגרמות ארכיטקטורה, חוברת הפעלה פנימית ותקופת העברה כך שהצוות שלכם מחזיק בבעלות על הסטאק המודרני בסוף. המטרה אף פעם אינה שתהיו תלויים בנו לנצח; המטרה היא שהמערכת הישנה תהפוך לליבה מתכווצת שהצוות הפנימי שלכם יוכל לתחזק בנוחות.

מודרניזציה של מערכות — שאלות נפוצות

האם אנחנו צריכים לשכתב מאפס או לעשות מודרניזציה הדרגתית?

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

האם תוכלו לשמור את המערכת שלנו רצה בזמן המודרניזציה?

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

מה עושים כשלמערכת הישנה אין תיעוד?

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

איך אתם מטפלים בהגירת בסיס הנתונים?

בשני שלבים. ראשית, מגדירים שכפול לוגי מבסיס הנתונים הישן לבסיס מנוהל מודרני (בדרך כלל Postgres) כדי שהמערכת החדשה תוכל לקרוא נתונים חיים. שנית, ברגע שקוד חדש גם יודע לכתוב נכון, אנחנו מעבירים את נתיב הכתיבה ומוציאים משימוש את בסיס הנתונים הישן. שני השלבים ללא השבתה למשתמשים.

מה לוח זמנים מציאותי למודרניזציה של מערכת ישנה?

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

האם ננעל איתכם אחרי ההגירה?

לא. כל פרויקט כולל תיעוד, דיאגרמות ארכיטקטורה, כיסוי בדיקות והעברה מסודרת. הסטאק המודרני שאנחנו מטמיעים (TypeScript/Python, Postgres, שירותי ענן) מוכר מספיק כדי שכל צוות מוכשר יוכל לקחת עליו בעלות.