הסיבה לביצוע העברות תוכנה היא לעתים קרובות התיישנות התוכנה, המורכבות ההיסטורית שגדלה או שהמערכת הקיימת הקיימת אינה מסוגלת עוד לעמוד בדרישות חומרה ותוכנה חדשות, כולל דרישות רגולטוריות עדכניות לניהול IT. יש גם חוסר במומחי IT מתאימים לתוכנות ישנות יותר ותמיכה מספקי תוכנה או פלטפורמות פיתוח רלוונטיות מובטחת רק במידה מוגבלת. בסך הכל, גם עלויות הפיתוח והתחזוקה גדלות ללא שליטה.
דוגמה טיפוסית: מערכת הליבה הקיימת, שפותחה בעצמה, של בנק, חברת ביטוח או KVG/KAG אינה עומדת עוד בדרישות העדכניות מבחינה מקצועית, טכנית ורגולטורית בשל התיישנותה. המשך הפיתוח אינו מובטח עוד עקב היעדר משאבי IT מתאימים. אסטרטגיית ה-IT של הבנק צופה אפוא הכנסת מערכת ליבה חדשה. לשם כך, יש צורך להחליף את כל הדרישות והפונקציות הקיימות וכל החדשות ב-backlog בתוכנה המחליפה.
מניסיוננו, אסטרטגיית ה-IT שואפת לעתים קרובות להחליף מערכת קיימת, בעיקר בפיתוח עצמי, בפתרונות חבילה מקיפים כגון SAP, SimCorp, GuideWire או Avaloq.
במהלך מיזוגים, העברת נתונים טהורה יכולה להתרחש גם אם החוזים ומערך הנתונים של מוסד נרכש מועברים למערכת של המוסד הרוכש בטווח הבינוני.
מנקודת המבט שלנו, הנקודות הבאות חשובות כשמדובר בהגירות:
על מנת לבצע הגירה, יש צורך גם שכל הדרישות והפונקציות יתועדו (ראה גם דרישות פיקוח על פי BaFin כגון MaRisk , BAIT , VAIT ו- KAIT וכן על פי ECB ו- EBA כגון EBA Guidelines on ניהול סיכוני ICT ואבטחה ) ומצד שני, כללי טרנספורמציה מתאימים מוגדרים עבור העברת נתונים, למשל עבור נתוני אב של לקוחות, נתוני עסקאות, נתונים עסקיים וכו'.
הגירה לא נכונה עלולה להוביל לעיתים קרובות לשיבושים בעסקים השוטפים. יכולות להיות לכך השלכות משמעותיות במונחים של מוניטין ויחסי שותפים עסקיים.