מעבר מאתר ASP.NET או Umbraco ישן: וורדפרס, סטאק מודרני או שדרוג במקום

למה אתר ה-.NET הישן הפך לבעיה

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

אני מכיר את האתרים האלה מבפנים. בניתי ב-ASP.NET MVC במשך שנים, כולל הגרסה של האתר הזה מ-2018, שבניתי מחדש ב-2020–2021 והעברתי ל-Next.js ב-2026. המעבר הזה לימד אותי את מה שכל אתר של לקוח מלמד: העמודים הם החלק הקל. העבודה היא במה שהאתר עושה מאחוריהם, ובלא לאבד את מה שגוגל כבר יודע עליו.

מה זה ״ישן״ ב-.NET, בתאריכים

לא כל אתר .NET ישן הוא אתר בלי תמיכה, וכדאי לדייק לפני שמישהו מוכר לכם תחושת דחיפות. מיקרוסופט מתייחסת ל-.NET Framework 4.x כרכיב של Windows: גרסה 4.8 ומעלה מקבלות תמיכה לפי מחזור החיים של גרסת Windows שהן מותקנות עליה. אתר על .NET Framework 4.8 שרץ על Windows Server נתמך עדיין מקבל עדכוני אבטחה לסביבה. בקו המודרני המצב אחר: התמיכה ב-.NET 8 וב-.NET 9 מסתיימת שתיהן ב-10 בנובמבר 2026, ו-.NET 10, שיצאה בנובמבר 2025, נתמכת עד 14 בנובמבר 2028.

הבעיה היא להתקדם. מדריך המעבר של מיקרוסופט עצמה נפתח במשפט שעדכון של אפליקציה מ-ASP.NET Framework ל-ASP.NET Core הוא לא פשוט ברוב האפליקציות שכבר רצות באוויר, ומפרט למה: קוד שקשור ל-System.Web, ניהול סשנים והתחברות שעובדים אחרת, וחבילות ישנות שאין להן תחליף מודרני. ב-Umbraco זה אותו סיפור, עם מערכת ניהול תוכן מעל. בתיעוד שלה כתוב שאין דרך שדרוג ישירה מ-Umbraco 8 לגרסה העדכנית, כי התשתית עברה מ-ASP.NET ל-ASP.NET Core, ושאת כל התבניות והקוד המותאם צריך לממש מחדש. את מסד הנתונים של התוכן אפשר להעביר; את האתר עצמו לא.

כלומר באתר על Umbraco 7 או 8, או על קוד ישן של Web Forms או MVC, גם ״פשוט לשדרג״ הוא בנייה מחדש. ברגע שמקבלים את זה, השאלה הופכת ל״איפה בונים מחדש״, וזו החלטה עסקית ולא טכנית.

שלושה יעדים, ולמי מתאים כל אחד

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

• להישאר ב-.NET ולבנות מחדש על Umbraco עדכני או על ASP.NET Core: כשיש לכם מפתחי .NET בבית, כשהאתר קשור למערכות .NET אחרות (ERP, ממשק פנימי, כניסה אחת לכל המערכות), או כשמבנה התוכן ב-Umbraco עובד טוב ורק הקוד התיישן.
• לעבור לוורדפרס: כשהאתר הוא בעיקר תוכן וטופסי לידים, מי שעורך אותו אינו מפתח, ואתם רוצים מאגר גדול של מפתחים ותוספים לבחור מתוכו, כדי לא להיות שוב תלויים באדם אחד.
• לעבור לסטאק מודרני בהתאמה אישית, למשל Next.js עם מערכת ניהול תוכן נפרדת: כשהאתר הוא בעצם אפליקציה, עם התחברות, מחשבונים, לוחות בקרה או הרבה חיבורים למערכות אחרות, ויש לכם קשר עם מפתח שימשיך לאורך זמן. זה נותן הכי הרבה שליטה והכי הרבה מהירות, ודורש הכי הרבה עבודת פיתוח שוטפת.

המיפוי: מה האתר הישן עושה ואתם לא רואים

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

• טפסים, ולאן כל אחד שולח את המידע: למייל, לטבלה במסד הנתונים, ל-CRM, לגיליון.
• חיבורים למערכות אחרות: עמודי תשלום, חיבור ל-CRM או ל-ERP, עדכוני מלאי או מחירים, משימות מתוזמנות שרצות בלילה.
• התחברות: אזור חברים, לקוחות או צוות, ומה מותר לכל סוג משתמש לראות.
• מיילים שהאתר שולח בעצמו: אישורים, תזכורות, איפוס סיסמה, ושרת המייל שהוא משתמש בו.
• כללים שמוסתרים בהגדרות השרת: שכתוב כתובות והפניות ב-web.config או ב-IIS, שקל לשכוח אותם והם קובעים לאן הגולשים מגיעים.
• תוכן ששמור במסד הנתונים: עמודים, חדשות, אנשי צוות, רשימות מוצרים, וקבצים ותמונות שיושבים על הדיסק.

העברת התוכן

החדשות הטובות באתר שמבוסס על מסד נתונים הן שהתוכן מסודר במבנה, ולכן בדרך כלל אפשר להעביר אותו בסקריפט ולא ביד. באתר Umbraco, התיעוד ב-docs.umbraco.com מתאר העברה של מסד הנתונים של התוכן לגרסת Umbraco חדשה יותר; במעבר לפלטפורמה אחרת, מייצאים את התוכן ממסד הנתונים (בדרך כלל SQL Server) לקבצים, מנקים ומייבאים. בוורדפרס הייבוא יכול לעבור דרך תוסף כמו WP All Import, שמייבא קובצי CSV, XML, Excel או Google Sheets לפוסטים ולסוגי תוכן מותאמים, או דרך ה-REST API של וורדפרס, שיוצר פוסט בבקשת POST לכתובת /wp/v2/posts. באתר Next.js אותו ייצוא נכנס למערכת התוכן שהאתר החדש משתמש בה.

שני דברים אף פעם לא קורים לבד. טקסט מעוצב מעורך ישן מגיע עם HTML ישן, עיצובים בתוך השורה וקישורים לכתובות הישנות; צריך לנקות אותו ולשכתב את הקישורים הפנימיים. וזה הרגע למחוק: עמודים שאף אחד לא נכנס אליהם וחדשות מ-2015 לא חייבים לעבור. Search Console ומערכת האנליטיקס מראים אילו עמודים מביאים כניסות; אותם מעבירים בזהירות, ועל השאר מחליטים.

כתובות aspx ישנות וגוגל

לאתרי .NET ישנים יש סוג כתובות משלהם: page.aspx?id=123, תיקיות שמסתיימות ב-default.aspx, נתיבים של Umbraco שנבנים מעץ התוכן. אף אחת מהן לא תתקיים באתר החדש, וכל כתובת שמחזירה ״העמוד לא נמצא״ מוותרת על הדירוג שהיה לה. המדריך של גוגל למעבר אתרים ברור לגבי הפתרון: להשתמש בהפניות קבועות בצד השרת, כמו 301 או 308, להשאיר אותן כמה שיותר זמן, בדרך כלל לפחות שנה, ולצפות לתנודות זמניות בדירוג בזמן שגוגל סורק את האתר מחדש.

• את רשימת הכתובות הישנות בונים ממפת האתר, מלוגים של השרת, מ-Search Console וממערכת האנליטיקס, וכוללים גם כתובות עם פרמטרים אם הן מקבלות כניסות.
• מעתיקים למפה את ההפניות שכבר קיימות ב-web.config או ב-IIS, כדי שהפניות ישנות ימשיכו לעבוד ולא יהפכו לשרשראות.
• מפנים כל כתובת ישנה ישר לכתובת הסופית החדשה. גוגל ממליץ לשמור על שרשראות קצרות, באופן אידאלי לא יותר משלוש הפניות.
• בודקים את כל המפה באתר החדש לפני העלייה לאוויר, ועוקבים אחרי דוח ״לא נמצא״ ב-Search Console במשך שבועות אחרי.

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

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

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

סדר העבודה

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

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

ממה נקבעת העלות

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

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