לפני ש-n8n 3.0 מגיעה: מריצים את ה-Migration Report על התהליכים

לא מעט עסקים קטנים מריצים את קליטת הלידים, תזכורות החידוש והדוחות השבועיים על מערכת n8n שמישהו הקים פעם אחת ומאז אף אחד לא פתח. ב-27 באוקטובר 2026 פרסמה n8n את הבטא של גרסה 3.0, עם שינויים שוברים, גרסה יציבה שמתוכננת לתחילת דצמבר וסוף התמיכה בגרסה 1.x ב-31 בדצמבר. החודשיים הקרובים יקבעו אם השדרוג יהיה אחר צהריים שקט או שבוע של תהליכים שבורים.

מה השתנה

לפי ההודעה של n8n, גרסה 3.0 לא מביאה יכולות חדשות בולטות: היא מסירה רכיבים ישנים ומחמירה את ברירות המחדל של האבטחה. התאריכים: בטא ב-27 באוקטובר, גרסה יציבה בתחילת דצמבר, גרסה 2.x ממשיכה לקבל תיקוני אבטחה ותיקונים קריטיים במשך 12 חודשים אחרי הגרסה היציבה, והתמיכה ב-1.x מסתיימת ב-31 בדצמבר 2026. אין מעבר ישיר מ-1.x ל-3.x, והמעבר ל-3.x הוא חד כיווני: אין דרך לחזור ל-2.x.

השינויים שהכי סביר שייגעו בעסק קטן, לפי עמוד השינויים השוברים של 3.0:

• צמתים שהוסרו. Function, Function Item, Item Lists, Cron, Interval, Read PDF, צומת OpenAI הישן, גרסה 1 של צומת AI Agent ועוד. תהליך מפורסם שמשתמש באחד מהם לא מופעל כש-3.0 עולה, כך שהטריגר שלו פשוט מפסיק לפעול.
• Gmail Trigger בגרסה שמתחת ל-1.4 מדלג עכשיו על טיוטות אם לא מפעילים אותן, ובודק כברירת מחדל עד 10 מיילים בכל סבב.
• Slack Trigger: תהליכים מפסיקים לקבל אירועים עד שמוסיפים לחיבור של Slack את ה-signing secret (מפתח האימות של האפליקציה).
• n8n בהתקנה עצמית חייבת לרוץ על Docker. התקנות שרצות עם npm או npx כבר לא נתמכות.

החלק השימושי הוא Migration Report (דוח ההגירה), בנתיב Settings > Migration Report בכל מערכת מגרסה 2.39 ומעלה. התיעוד של כלי ההגירה מתאר אותו: פס התקדמות של תהליכים תואמים, רמת השפעה לכל בעיה (מ-"Upgrade blocked" ועד "Capability removed"), מספר ההרצות ותאריך ההרצה האחרונה של כל תהליך, וכפתור Migrate שמשכתב חלק מהצמתים בעצמו, למשל Cron ל-Schedule Trigger. הגרסה המפורסמת ממשיכה לרוץ עד שמפרסמים את הגרסה החדשה אחרי ההגירה.

מה זה אומר לעסק שרץ על n8n

נניח סוכנות ביטוח של 15 עובדים, שפרילנסר הקים לה n8n בהתקנה עצמית לפני שנתיים. כ-20 תהליכים רצים עליה: לידים מהאתר נכנסים ל-CRM, תזכורות חידוש שמופעלות מ-Gmail Trigger, דוח של יום שני על צומת Cron והתראות ל-Slack. הפרילנסר כבר עבר לפרויקטים אחרים, והמערכת עדיין רצה על גרסה 1.x.

לסוכנות הזאת יש שני מועדים. עד 31 בדצמבר היא צריכה להיות על 2.x, כי 1.x מפסיקה לקבל תיקונים. אחר כך, מתישהו בשנה הקרובה, היא עוברת ל-3.x. הסיכון האמיתי הוא תקלה שקטה: דוח יום שני נעצר כי Cron הוסר, תזכורות חידוש מדלגות על חלק מהמיילים כי הטריגר קורא עכשיו 10 בכל סבב, ואף אחד לא שם לב במשך שבועיים.

ה-Migration Report מראה אילו מתוך 20 התהליכים מושפעים, ממוינים לפי תדירות ההרצה, בלי לקרוא את כל רשימת השינויים. לכל תהליך מסומן יש כפתור Migrate, או שמישהו צריך לבנות בו צומת מחדש ביד. בקבוצה השנייה שווה להשקיע את הזמן של מי שבנה את המערכת במקור, או עזרה מבחוץ.

איך עושים את זה

1. בודקים איזו גרסה רצה. ב-n8n Cloud היא מופיעה באזור Updates של Instance settings בקונסולת הענן. בהתקנה עצמית בודקים את תגית ה-Docker image או את מסך About בעורך.
2. מי שעל 1.x עובר קודם ל-2.x, לפני 31 בדצמבר. קוראים את השינויים השוברים בגרסה 2.0 ומגבים את כל מסד הנתונים לפני שמתחילים.
3. מעדכנים לגרסת 2.x האחרונה ופותחים את Settings > Migration Report.
4. ממיינים לפי מספר ההרצות. מתקנים קודם את התהליכים העמוסים. תהליכים שלא רצו 12 חודשים מסמנים כ-"Won't fix".
5. מטפלים קודם בבעיות "Upgrade blocked" ו-"Executions will fail". לוחצים Migrate כשהכפתור מופיע, קוראים את רשימת הצמתים שהשתנו, מריצים את הגרסה החדשה עם נתוני בדיקה ורק אז מפרסמים. את ה-signing secret של Slack ואת ההגדרות של Gmail Trigger בודקים ביד.
6. בהתקנה עצמית על npm או npx: עוברים ל-Docker כשעדיין על 2.x, מוודאים שהכול רץ, ורק אז מתכננים את 3.0.
7. אחרי הגרסה היציבה בדצמבר, משדרגים קודם עותק בדיקה. מריצים עליו את שלושת התהליכים העמוסים ביותר, ואז משדרגים את מערכת הייצור. ב-Cloud נשארים במסלול השחרורים Stable וקובעים חלון תחזוקה, כמו שמתואר ב-Update your version.

עלויות, מגבלות וסיכונים

השדרוג לא עולה כסף ברישוי: לפי ההודעה, 3.0 חלה על גרסת Community החינמית בהתקנה עצמית, על Cloud ועל התוכניות בתשלום. העלות היא זמן. כהערכה, נניח 15 עד 30 דקות לכל תהליך שהדוח מסמן כניתן להגירה, כולל הרצת בדיקה, ושעה או שעתיים לכל תהליך שצריך לבנות מחדש. בסוכנות שתיארנו, בהנחה של 5 תהליכים מסומנים שמתוכם 1 צריך בנייה מחדש, מדובר בערך ב-2 עד 4 שעות, ועוד הגיבוי ועותק הבדיקה.

הסיכונים שכדאי לשים אליהם לב:

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

האם לעשות את זה עכשיו

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

עם 3.0 עצמה אפשר לחכות אם הכול כבר מסומן כתואם. גרסה 2.x ממשיכה לקבל תיקונים במשך שנה אחרי הגרסה היציבה. מוותרים על כל זה רק אם כבר לא משתמשים ב-n8n, ואז מכבים את המערכת.