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

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

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

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

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

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

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

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

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