כלי הערכה של הגירת ענן: מדוע גילוי תשתיות הוא רק חצי מהעבודה

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

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

מהי הערכת הגירה לענן?

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

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

מימד ההערכה	מה זה עונה	כלים עיקריים
תשתית	אילו שרתים, מכונות וירטואליות ושירותים קיימים? מהם פרופילי השימוש שלהם?	Azure Migrate, גילוי יישומים של AWS, מרכז ההגירה של גוגל
קוד יישום	האם הקוד תואם ליעדי ענן? מה צריך להשתנות?	הדגשת CAST, SMART TS XL, CloudPilot, מודרניזציה של אפליקציות GitHub Copilot
נתונים	אילו נפחי נתונים קיימים? היכן נמצאים הנתונים? מהן מורכבות ההעברה ומגבלות התאימות?	שירות הגירת מסדי נתונים של AWS, שירות הגירת מסדי נתונים של Azure, Striim
אבטחה ותאימות	אילו דרישות רגולטוריות חלות? אילו פערי אבטחה קיימים? אילו שינויים נדרשים ב-IAM ובהצפנה?	מרכז האבטחה של AWS, Microsoft Defender for Cloud, Prisma Cloud
עלות ו-TCO	מהי העלות המלאה של ההגירה ומהי עלות הבעלות הכוללת לאחר ההגירה?	מחשבון תמחור AWS, מחשבון TCO של Azure, תשתית, יכולת ענן של Apptio

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

חמשת הממדים של הערכת הגירת ענן

הערכת תשתית

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

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

Azure Migrate הוא הסטנדרט עבור ארגונים שעוברים ל-Azure. הוא מבצע גילוי ללא סוכן של סביבות VMware vSphere, Hyper-V ושרתים פיזיים, ומייצר הערכות מוכנות, המלצות לגודל נכון מבוססות ביצועים והערכות עלויות לפני שעומס עבודה יחיד עובר.

שירות הגירת היישומים של AWS (MGN) ושירות גילוי היישומים של AWS ממלאים את אותה פונקציה עבור יעדי AWS. שירות גילוי אוסף נתוני תצורה וביצועים מקומיים באמצעות איסוף ללא סוכן או סוכן המותקן באופן מקומי.

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

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

הערכת קוד יישום

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

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

חוסמי תאימות , ממשקי API, מסגרות או תכונות זמן ריצה שאינם קיימים או מתנהגים בצורה שונה בסביבת הענן של היעד. יישום Java שנבנה על שרת יישומי Java EE שאינו זמין בשירות PaaS של היעד זקוק לשינויי קוד לפני שניתן יהיה לפרוס אותו. יישום המשתמש במוסכמה ספציפית ל-Windows לגבי נתיב קבצים אינו יכול לפעול על מופע ענן מבוסס לינוקס ללא שינוי.

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

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

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

CAST Highlight מבצע הערכה אוטומטית של קוד יישומים ברמת תיק העבודות, סורק קוד מקור במספר שפות כדי לייצר ציוני מוכנות לענן, זיהוי חוסמים וניתוח סיכונים בקוד פתוח. הוא מופיע ב-Azure Cloud Adoption Framework של מיקרוסופט ככלי מומלץ לעומסי עבודה שאינם .NET ו-Java.

CloudPilot מתמחה בהערכת מוכנות לענן מפורטת עם ניקוד תאימות ויצירת מפת דרכים למעבר בין JavaScript, Python, Node.js ו-Go.

GitHub Copilot App Modernization משלבת את יכולות ההערכה של AppCAT של CAST עם תיקון קוד בסיוע בינה מלאכותית עבור עומסי עבודה של .NET ו-Java באופן ספציפי.

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

הערכת נתונים

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

השאלות המרכזיות שעל הערכת הנתונים לענות עליהן:

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

תאימות סכימה : האם שירות מסד הנתונים של היעד תומך באותן תכונות סכימה, סוגי נתונים ופרוצדורות מאוחסנות כמו המקור? מבני PL/SQL ספציפיים ל-Oracle דורשים המרה לפני המעבר ל-PostgreSQL או לחלופה מקורית לענן.

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

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

שירות הגירת מסדי נתונים של AWS ושירות הגירת מסדי נתונים של Azure תומכים בשכפול רציף עם זמן השבתה מינימלי עבור העברות הומוגניות (Oracle ל-Oracle, SQL Server ל-SQL Server) ובהמרת סכימה עבור העברות הטרוגניות (Oracle ל-PostgreSQL, SQL Server ל-Aurora).

Striim ו- Attunity מספקות הזרמת נתונים בזמן אמת ושכפול עבור תרחישי הגירה בעלי זמינות גבוהה שבהם זמן השבתה של מסד נתונים אינו מקובל.

הערכת אבטחה ותאימות

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

הערכת אבטחת המימדים חייבת לכלול:

ניהול זהויות וגישה (IAM) : יישומים מקומיים משתמשים לעתים קרובות בחשבונות שירות עם הרשאות רחבות ואימות מבוסס סיסמה. סביבות ענן דורשות בקרת גישה מבוססת תפקידים, זהויות שירות בעלות הרשאות נמוכות ביותר ואימות מבוסס אישורים או אסימון. הפער בין ה-IAM הנוכחי לנדרש הוא מאמץ הגירה שאין לו שום קשר למלאי התשתית.

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

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

יישור מסגרת תאימות : לכל תעשייה מוסדרת יש דרישות תאימות ספציפיות המתאימות לתצורות ענן ספציפיות. עומסי עבודה של HIPAA דורשים אפשרויות תצורה ספציפיות באחסון, רישום גישה והצפנה. PCI-DSS דורש פילוח רשת שיש ליישם בצורה שונה ב-VPC בענן מאשר בתשתית רשת פיזית.

Microsoft Defender for Cloud מספק הערכת מצב אבטחה והערכת תאימות מול מדדי CIS, NIST, PCI-DSS ומסגרות אחרות עבור עומסי עבודה של Azure.

Prisma Cloud (Palo Alto Networks) ו- AWS Security Hub מספקים הערכת אבטחה וניטור תאימות מקבילים בעננים מרובים.

הערכת עלות ו-TCO

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

הערכת עלות כוללת (TCO) מלאה כוללת:

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

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

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

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

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

מחשבון תמחור AWS , מחשבון TCO של Azure ומחשבון תמחור Google Cloud עוסקים במימד עלות תשתית הענן. Infracost מספק הערכת עלויות משולבת בצינורות IaC, ומייצר הערכות עלויות כחלק מתהליך CI/CD. Apptio Cloudability וכלים דומים של FinOps מספקים נראות עלויות מתמשכת לאחר ההגירה.

שבע אסטרטגיות ההגירה: כיצד הערכה קובעת איזו מהן רלוונטית

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

אִסטרָטֶגִיָה	מה זה אומר	אות הערכה שמרמז על כך
אירוח מחדש (הרמה והזזה)	מעבר לענן ללא שינויי קוד	מורכבות יישומים נמוכה, ללא חוסמי תאימות, תואם לתשתית
פלטפורמה מחדש	שינויים קלים למינוף שירותי ענן (למשל, מעבר למסד נתונים מנוהל)	צימוד מתון, הזדמנות שדרוג פלטפורמה ספציפית, היקף שינויי קוד מקובל
רפקטור	תכנון מחדש של תבניות ענן מקוריות (microservices, containers)	צימוד מונולית גבוה, דרישות מדרגיות משמעותיות, מוצדקות על ידי צמיחת התעבורה הצפויה
אדריכל מחדש	עיצוב מחדש משמעותי של ארכיטקטורת האפליקציה	אפליקציה אינה תואמת באופן מהותי לענן; הארכיטקטורה החדשה מספקת יתרון עסקי משמעותי
לבנות מחדש	כתיבה מחדש מאפס	היישום אינו דורש תיקון כלכלי; החלפה זולה יותר מתיקון
חלף	הוציאו לגמלאות את האפליקציה המותאמת אישית, אימצו אלטרנטיבה של SaaS	האפליקציה מספקת פונקציונליות בסיסית המוגשת טוב יותר על ידי שירות ענן קיים
לפרוש	הוצאה משימוש, האפליקציה אינה נחוצה עוד	יישום זוהה כמת, מיותר או הוחלף במהלך ההערכה

מלאי התשתיות אינו יכול להבחין בין מועמדים ל-Rehost, Replatform, Refactor ו-Rebuild, כולם נראים זהים בשכבת התשתית. הערכת קוד האפליקציה היא מה שיוצרת את ההבחנה הזו.

הערכת הגירת ענן עבור מערכות מדור קודם ומיינפריים

כלי הערכה סטנדרטיים להעברת ענן מיועדים לתשתיות מודרניות: מכונות וירטואליות, מכולות, מיקרו-שירותים ויישומים מקוריים לענן. הם מתפקדים בצורה גרועה או בכלל לא עבור עומסי עבודה של מיינפריים, תוכניות COBOL הפועלות על IBM z/OS, זרמי משימות JCL המנהלים עיבוד אצווה, יישומי PL/I המטפלים בעסקאות פיננסיות ותוכניות RPG המוטמעות במערכות AS/400.

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

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

השוואה בין כלי הערכה להעברת ענן

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

כלי	שכבת הערכה	יעד ענן	הכי טוב
Azure Migrate	תשתית	תכלת	גילוי מכונות וירטואליות ושרתים, קביעת גודל נכון, הערכת עלויות ב-Azure
שירות גילוי יישומים של AWS	תשתית	AWS	גילוי שרתים מקומיים עבור מיגרציות AWS
מרכז ההגירה של גוגל	תשתית	GCP	מלאי נכסים ועלות כוללת (TCO) עבור העברות GCP
שיא של CAST	קוד יישום	רב ענן	ניקוד מוכנות קוד בקנה מידה של תיק עבודות בשפות שונות
קלאודפיילוט	קוד יישום	רב ענן	ניתוח תאימות מפורט עבור Python, JS, Node.js, Go
SMART TS XL	קוד אפליקציה + מיפוי תלויות	רב ענן	ניתוח תיקי עבודות COBOL, JCL, מיינפריים ורב-לשוני
ניהול מערכות ניהול (DMS) של AWS	נתונים	AWS	הגירת מסד נתונים עם המרת סכימה
שירות הגירת מסדי נתונים של Azure	נתונים	תכלת	העברת SQL Server, MySQL ו-PostgreSQL ל-Azure
סטרים	נתונים	רב ענן	שכפול בזמן אמת להעברת נתונים ללא זמן השבתה
Microsoft Defender for Cloud	אבטחה	Azure / Multi-Cloud	הערכת מצב אבטחה ותאימות
פריזמה ענן	אבטחה	רב ענן	CSPM ותאימות ב-AWS, Azure, GCP
Infracost	עלות	רב ענן	הערכת עלויות משולבת ב-IaC בצינורות CI/CD
Apptio Cloudability	עלות	רב ענן	FinOps וניהול שוטף של עלויות ענן
קורנט SurPaaS	תשתית + אפליקציה	רב ענן	גילוי, הערכה ותזמור הגירה מונעי בינה מלאכותית

איך SMART TS XL ביצוע הערכת קוד אפליקציה עבור הגירת ענן

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

עבור תוכנית הגירה הכוללת תוכניות COBOL, זרמי משימות JCL, שירותי Java, צינורות Python וסכמות SQL, SMART TS XL בונה מודל תלות מאוחד על פני כולם בו זמנית. לפני שצוות ההעברה מחליט מה לאחסן מחדש, מה לעשות שינויים ומה להוציא משימוש, SMART TS XL מספק:

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

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

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

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

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

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

מה צריכה להניב הערכה מלאה של הגירת ענן

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

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

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

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

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

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

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