COBOL-Migrationskosten: Ratgeber UK 2026

„Was kostet der Umstieg von COBOL?“ ist die erste Frage, die jeder Vorstand stellt, und die ehrliche Antwort lautet, dass es von mehr abhängt als von der Größe der Codebasis. Dieser Ratgeber schlüsselt auf, was die COBOL-Migrationskosten in UK tatsächlich treibt, welche Budget- und Zeitrahmen realistisch sind und welche Risiken aus einem gut geplanten Projekt eine Budgetüberschreitung machen.

TL;DR

• Eine mittelgroße UK-COBOL-Migration kostet typischerweise 200.000 bis 800.000 Pfund Sterling und dauert ein bis zwei Jahre; vollständige Mainframe-Stilllegungen gehen in die Millionen und über mehrere Jahre
• Die Kosten werden weit stärker von der Komplexität der Codebasis, undokumentierter Geschäftslogik und dem Neuentwurf des Datenzugriffs getrieben als von der reinen Zeilenzahl
• Die Wahl der Zielsprache und des Migrationsansatzes verändert das Budget spürbar
• Der häufigste Grund für Überschreitungen ist die Unterschätzung des Umfangs, besonders undokumentierter Geschäftsregeln und der Datenzugriffsschicht

Was die COBOL-Migrationskosten wirklich treibt

Die Zeilenzahl ist die Schlagzeile, aber für sich genommen ein schwacher Indikator. Die echten Kostentreiber sind:

Komplexität, nicht nur Größe. Ein System mit 100.000 Zeilen sauberer Batch-Programme lässt sich günstiger migrieren als ein System mit 50.000 Zeilen, das dicht mit EXEC CICS, dynamischen CALLs und verschachtelten REDEFINES durchsetzt ist. Transaktionsverarbeitende Systeme kosten mehr als Batch-Systeme gleicher Größe.

Undokumentierte Geschäftslogik. COBOL-Systeme tragen oft 30 bis 40 Jahre Geschäftsregeln, die ohne externe Dokumentation im Code eingebettet sind. Diese Regeln neu zu entdecken und zu validieren ist häufig der größte und am wenigsten vorhersehbare Einzelposten.

Die Datenzugriffsschicht. EXEC SQL gegen DB2 und die VSAM-Dateiverarbeitung lassen sich selten automatisch konvertieren. Sie müssen auf die Datenzugriffstechnologie der Zielplattform neu entworfen werden, und das ist oft der größte Arbeitsposten nach der Aufdeckung der Geschäftslogik.

Datenformatkonvertierung. Packed Decimal (COMP-3), EBCDIC-Kodierung und Layouts mit fester Feldbreite erfordern alle eine explizite Abbildung und Tests mit echten Daten.

Zielsprache und Ansatz. Diese verschieben das Budget auf vorhersehbare Weise (weiter unten behandelt).

Testen und Umschaltung. Der Aufbau einer Regressions-Testsuite, die Ausgabegleichheit nachweist, und die Durchführung einer sicheren Umschaltung mit Rollback sind echter, nicht-trivialer Aufwand, den unerfahrene Schätzungen weglassen.

Indikative Kosten- und Zeitrahmen (UK)

Diese Bereiche decken Analyse, Migration, Tests und Go-live-Unterstützung ab. Sie schließen laufende Betriebskosten, Schulungen und nachgelagerte Integrationsarbeiten aus, die oft mitten im Projekt auftauchen.

Behandeln Sie diese als Planungsbereiche, nicht als Angebote. Eine belastbare Schätzung erfordert eine Code-Bewertung; die Spanne innerhalb jeder Kategorie wird von den oben genannten Komplexitätsfaktoren bestimmt.

Wie die Zielsprache die Kosten beeinflusst

Die Zielsprache verändert sowohl das Aufwandsprofil als auch die langfristigen Betriebskosten. Grob gesagt:

• Python passt natürlich zum prozeduralen Stil von COBOL und hat den größten Entwicklerpool, was Konvertierungs- und langfristige Wartungskosten tendenziell senkt.
• C# ist effizient für Organisationen, die bereits auf dem .NET- und Azure-Stack aufsetzen, und sein nativer decimal-Typ reduziert den Aufwand, finanzielle Präzision korrekt hinzubekommen.
• Java passt zu JVM-basierten Unternehmen; BigDecimal handhabt Präzision korrekt, fügt aber etwas Weitschweifigkeit hinzu.
• Go lässt sich effizient bauen und bereitstellen, aber das Fehlen eines nativen Decimal-Typs erhöht den Prüfaufwand für Finanzfelder.
• Rust tendiert zum oberen Ende jeder Größenkategorie, weil sein Ownership-Modell im Vorfeld zusätzlichen Entwurfsaufwand verursacht.

Der COBOL-Migrationsüberblick vergleicht alle sechs Zielsprachen nebeneinander, um Ihnen bei der Wahl zu helfen.

Wie der Migrationsansatz die Kosten beeinflusst

• Automatisierte Konvertierung reduziert den mechanischen Übersetzungsaufwand, liefert aber nie ein fertiges System; kalkulieren Sie die manuelle Arbeit ein, die das Tooling markiert (eingebettetes SQL, CICS, dynamische Aufrufe, Decimal-Präzision).
• Parallele Neuentwicklung verdoppelt die Betriebskosten während des Übergangs in etwa, weil zwei Systeme gleichzeitig laufen, minimiert aber das Kontinuitätsrisiko. Sie eignet sich für kleinere, geschäftskritische Systeme.
• Inkrementell (strangler fig ) verteilt die Kosten über die Zeit und reduziert das Big-Bang-Risiko, zum Preis einer längeren Hybridphase. Es ist der häufigste Ansatz für große UK-Unternehmenssysteme.

Die meisten realen Projekte kombinieren automatisierte Konvertierung mit einer inkrementellen Einführung.

Die Risiken, die zu Überschreitungen führen

Migrationen laufen aus vorhersehbaren Gründen über. Die großen fünf:

1. Unterschätzte Aufdeckung der Geschäftslogik. Die Regeln stehen im Code, nicht in einem Dokument. Kalkulieren Sie explizite Zeit für die Aufdeckung ein.
2. Neuentwurf des Datenzugriffs. DB2- und VSAM-Zugriff lässt sich nicht automatisch portieren. Behandeln Sie ihn als eigenen Arbeitsstrom.
3. Unzureichende Regressionstests. Ohne Tests auf Ausgabegleichheit mit echten Daten können Sie nicht nachweisen, dass die Migration korrekt ist. Bauen Sie die Testsuite auf, bevor die Migration beginnt.
4. Fehler bei der Decimal-Präzision. Finanzfelder, die auf Fließkommatypen abgebildet werden, verfälschen Geld stillschweigend. Bilden Sie auf den korrekten Decimal-Typ der Zielsprache ab.
5. Fehlschlag der Umschaltung. Der Wechsel in die Produktion ist der Moment mit dem höchsten Risiko. Ein detaillierter Umschaltplan mit Rollback und Abgleich ist zwingend.

So erhalten Sie eine genaue Schätzung

Eine belastbare Zahl kommt aus einer Code-Bewertung, nicht aus einer Zeilenzahl. Eine gute Bewertung inventarisiert Programme und Copybooks, identifiziert EXEC SQL / EXEC CICS / Hotspots dynamischer Aufrufe, misst die Dichte der Geschäftslogik und kartiert die Datenzugriffsoberfläche. Der Mecanik COBOL-Migrationsservice bietet Bewertungen für UK-Unternehmen und Full-Service-Migration; für Mainframe-Bestände auf IBM z/OS deckt der Legacy-Mainframe-Migrationsservice die Infrastruktur-Stilllegung neben dem Code ab.

Wichtigste Erkenntnisse

• Eine mittelgroße UK-COBOL-Migration kostet typischerweise 200.000 bis 800.000 Pfund Sterling über ein bis zwei Jahre; Mainframe-Stilllegungen gehen in die Millionen.
• Komplexität, undokumentierte Geschäftslogik und der Neuentwurf des Datenzugriffs treiben die Kosten weit stärker als die Zeilenzahl.
• Zielsprache und Migrationsansatz verschieben beide das Budget auf vorhersehbare Weise.
• Überschreitungen kommen von der Unterschätzung von Aufdeckung, Tests und Umschaltung; eine ordentliche Code-Bewertung ist die einzige belastbare Grundlage für ein Angebot.

Häufig gestellte Fragen (FAQ)

Was kostet eine COBOL-Migration in UK? Ein kleines System kostet typischerweise 80.000 bis 200.000 Pfund Sterling, ein mittelgroßes System 200.000 bis 800.000 Pfund Sterling und große Systeme ab 500.000 aufwärts. Vollständige Mainframe-Stilllegungsprogramme reichen von 1.000.000 bis in die zweistelligen Millionen. Komplexität, nicht die Zeilenzahl, bestimmt, wo Sie in der Spanne landen.

Wie lange dauert eine COBOL-Migration? Kleine, gut dokumentierte Systeme dauern drei bis neun Monate. Mittelgroße Unternehmenssysteme laufen zwölf bis vierundzwanzig Monate. Große Mainframe-Programme dauern drei bis fünf Jahre oder mehr für die vollständige Stilllegung.

Warum variieren die COBOL-Migrationskosten so stark? Weil die Komplexität enorm variiert. Undokumentierte Geschäftslogik, eingebettetes SQL und CICS, Datenformatkonvertierung, die Zielsprache und der Migrationsansatz verschieben alle die Kosten. Zwei Systeme gleicher Zeilenzahl können sich um eine Größenordnung unterscheiden.

Reduziert automatisierte Konvertierung die Kosten? Sie reduziert den mechanischen Übersetzungsaufwand, aber kein Tool liefert ein fertiges System. Sie kalkulieren weiterhin die Datenzugriffsschicht, Entscheidungen zur Decimal-Präzision, Tests und Umschaltung ein, die das Tooling für manuelle Arbeit markiert.

Was ist die häufigste Ursache für COBOL-Migrationsüberschreitungen? Die Unterschätzung des Umfangs, besonders undokumentierter Geschäftslogik und des Neuentwurfs des Datenzugriffs. Der Aufbau einer Regressions-Testsuite für Ausgabegleichheit vor Beginn der Migration ist der wirksamste Weg, dieses Risiko zu kontrollieren.