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

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

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

מדוע הגירות של מיינפריים נכשלות: פער הניתוח

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

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

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

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

פער 2: תלות לא מתועדת. מחשבים מרכזיים מזינים עשרות מערכות באמצעות רשתות מורכבות של תוכנות ביניים כמו WebSphere, CICS Transaction Gateway, Enterprise Service Bus, בנוסף לשירותים משותפים, מתזמנים ותהליכים עסקיים. הטעות היא המתנה ארוכה מדי למיפוי כל הקשרים הללו, במיוחד הזנות נתונים במורד הזרם ודפוסי צריכה.

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

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

שמונה הניתוחים שחייבים להתרחש לפני הגירה

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

1. מלאי מלא של התוכנית

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

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

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

2. מיפוי תלות בכל השפות

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

מפת תלות מלאה מכסה:

• קריאות בין תוכניותקריאות CALL, PERFORMS, LINK, ATTACH, וקריאות דינמיות שנפתרות בזמן ריצה
• קריאות JCL לתוכניתכל משפט EXEC PGM= בכל זרם משימות JCL, כולל קריאות PROC עם החלפת פרמטרים סמליים שנפתרו
• שרשראות הכללת מחברתאילו תוכניות כוללות אילו ספרי עותקים, כולל ספרי עותקים מקוננים הכלולים על ידי ספרי עותקים אחרים
• יחסי יצרן-צרכן של מערך הנתוניםאילו תוכניות כותבות לאילו מערכי נתונים, אילו תוכניות קוראות ממערכי הנתונים הללו, ותלויות שרשרת העבודות הרציפות שזה יוצר
• הפניות לסכימת DB2אילו תוכניות קוראות או כותבות לאילו טבלאות, אילו טבלאות חולקות סכימה עם אילו טבלאות אחרות

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

לפני שנוגעים בכל קוד, נראות עמוקה היא בעלת חשיבות עליונה. הסתמכות על תיעוד מיושן היא פגם חמור; כלים אוטומטיים חייבים למפות את המצב הנוכחי על ידי סריקה אוטומטית של JCL, COBOL ו-PL/I, תוך מיפוי כל היישומים, זרימות הנתונים, התלויות והמשימות הנסתרות.

3. חילוץ ותיעוד של לוגיקה עסקית

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

חילוץ לוגיקה עסקית מייצר תיעוד של: כללי ההחלטה המקודדים במבנים IF/THEN/ELSE ו-EVALUATE; נוסחאות החישוב במשפטי COMPUTE; כללי אימות הנתונים בפסקאות PROCEDURE DIVISION; נתיבי טיפול בשגיאות ומשמעותם העסקית; והלוגיקה התלויה ברצף שבה סדר הפעולות חשוב לנכונות הפלט.

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

4. זיהוי קוד מת

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

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

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

5. סיווג מורכבות וסיכונים

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

מדדי מורכבות עבור סיכון הגירה של COBOL:

גורם המורכבות	מה למדוד	סף סיכון גבוה
מורכבות ציקלומטית	מספר ענפי החלטה לכל תוכנית	מעל 50 לכל תוכנית
ספירת תלות בפנקס העותקים	מספר מחברות החיבור הכלולים	מעל 20 מחברות
ספירת קריאה	מספר התוכניות שקוראות לתוכנית זו	מעל 15 מתקשרים
הפניות למערכי נתונים	מספר מערכי נתונים שנקראו או נכתבו	מעל 30 מערכי נתונים
SQL מוטמע	מספר משפטי SQL	מעל 100 הצהרות
שיחות CICS של מנהלים	צימוד שרת עסקאות	כל תלות ב-CICS
שיחות דינמיות	קריאות שנפתרו בזמן ריצה	כל שיחה דינמית
קריאות אסמבלר	לוגיקה שאינה COBOL מוטמעת	כל קריאה לאסמבלר

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

6. ניתוח תלות בחלון אצווה ותזמון

משימות אצווה של מחשב מרכזי פועלות בחלונות מתוזמנים עם שרשראות תלות מורכבות: משימה B אינה יכולה להתחיל עד שמשימה A תושלם בהצלחה; משימה C פועלת רק ביום העסקים האחרון של החודש; למשימה D יש אילוץ זמן ריצה מקסימלי המשפיע על זמן ההתחלה של משימה E. תלויות תזמון אלו הן חלק מההתנהגות התפעולית של המערכת ויש לשכפל אותן בסביבת היעד.

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

ביעדים מבוססי ענן, זה מתורגם ל: צינור CI/CD או תזמור זרימת עבודה מקבילים; הגדרת טיפול בשגיאות והתראות; תצורת הניטור ו-SLA; ושילוב עם מערכות במורד הזרם המקבלות את פלטי האצווה.

7. הערכת איכות ופורמט נתונים

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

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

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

8. אינטגרציה ומיפוי מערכות חיצוניות

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

מיפוי האינטגרציה מזהה כל מערכת מחוץ למיינפריים שמקבלת ממנו נתונים או שולחת אליו נתונים: יישומים במורד הזרם הצורכים פלטי אצווה באמצעות העברת קבצים; ממשקים בזמן אמת באמצעות קריאות MQ, CICS או API; אינטגרציות שותפים המסתמכות על פורמטים ספציפיים של קבצים ולוחות זמנים של שידור; מערכות דיווח שמבצעות שאילתות ישירות בטבלאות DB2; והזנות של מחסני נתונים הקולטות נתוני מיינפריים שעברו טרנספורמציה.

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

בחירת אסטרטגיית הגירה המבוססת על תוצאות הניתוח

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

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

בניית רצף ההגירה מגרף התלות

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

גישת ריצוף מעשית:

שלב 1: תוכניות שירות ומשימות אצווה עצמאיות. תוכניות ללא קוראים וללא מערכי נתונים משותפים. ניתן להעביר אותן בנפרד ללא דרישות תיאום.

שלב 2: העברת תוכניות בעץ התלות. תוכניות שקוראות לאחרות אך אינן נקראות על ידי רבים. העברת תוכניות אלה מסירה אותן מטווח התלות עבור התוכניות הנותרות.

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

שלב 4: תוכניות שירות משותף. תוכניות עם קוראים רבים, צמתים בעלי רמת ה-fan-in הגבוהה בגרף התלות, הועברו רק לאחר שכל הקוראים אומתו מול המימוש שהועבר.

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

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

איך SMART TS XL מייצר את ניתוח טרום ההגירה

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

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

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

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

הניתוח אינו תקורה, אלא ההגירה

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

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

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