Jährliche Mainframe-Kosten in einem belastbaren Budget

Jährliche Mainframe-Kosten sind nicht die Zahl auf einer Hardware-Rechnung. Sie bestehen aus Verträgen, Kapazitätsmessungen, Personalpflichten, Betriebskosten und Risikovorsorge. Jeder Teil reagiert anders, wenn sich die Last ändert. Wer alles zu einem Mischpreis zusammenfasst, baut einen schlechten Migrationsfall: Entweder wirken die Einsparungen wundersam oder der Abschied von der Maschine unmöglich.

Ich habe Kostenanalysen scheitern sehen, weil Finance nach einem einzigen Preis pro MIPS fragte und Engineering einen lieferte. MIPS können die relative Prozessorkapazität beschreiben, doch wichtige Software-Rechnungen ergeben sich nicht einfach aus MIPS mal öffentlichem Tarif. Ein brauchbares Modell beginnt bei jeder Rechnung und jedem Vertrag, bestimmt den Treiber jeder Position und fragt dann, ob die Verlagerung einer einzelnen Anwendung diesen Treiber überhaupt verändert.

Es gibt keinen ehrlichen universellen Mainframe-Tarif

Ein Mainframe-Jahresbudget braucht getrennte Kostenblöcke, weil jeder Block auf ein anderes Ereignis reagiert. Kapazitätsabhängige Software kann einem gemessenen Vier-Stunden-Höchstwert folgen. Die Hardware-Wartung bleibt womöglich unverändert, bis eine Maschine außer Betrieb geht. Personalkosten ändern sich erst, wenn sich Zuständigkeiten und Rufbereitschaft ändern. Eine Rechenzentrumsumlage kann weiter in den Büchern stehen, obwohl die Stellfläche leer ist.

Trennen Sie mindestens diese Blöcke:

• Kapazitätsabhängige Software, einschließlich Produkten, deren Gebühr MSUs oder einer anderen gemessenen Kapazitätsgröße folgt.
• Feste oder gestaffelte Softwarekosten, einschließlich Jahreslizenzen, Support und Produkten mit Preisen nach Maschinenklasse oder Umgebung.
• Hardwarekauf oder Leasing, Wartung, Speicher, Netzwerkgeräte und angeschlossene Systeme.
• Personal, externe Unterstützung, Betrieb, Disaster Recovery, Security Operations und Compliance-Arbeit.

Verteilen Sie nicht alle Kosten mit demselben Nenner auf Anwendungen. CPU-Verbrauch kann für ein Softwareprodukt sinnvoll sein und für Speicher, Fremdsupport oder einen Spezialisten, der überwiegend Releases koordiniert, völlig unpassend. Wählen Sie einen Treiber, der erklärt, warum die Kosten entstehen: Beitrag zum gemessenen Peak, belegter Speicher, bearbeitete Tickets, genutzte Umgebungen oder fest zugeordnete Arbeit. Lassen Sie gemeinsame Kosten unverrechnet, wenn jede Verteilung nur eine nicht vorhandene Genauigkeit vortäuschen würde.

Das erste Arbeitsergebnis sollte ein Vertragsregister sein, keine Gesamtsumme. Erfassen Sie für jede Position Lieferant, Produkt, Vertragslaufzeit, Verlängerungsdatum, Abrechnungsmetrik, Mindestabnahme, aktuelle Stufe, Kündigungsbedingung und Belegquelle. Benennen Sie eine verantwortliche Person, die die Auslegung verteidigen kann. Eine Tabellenzelle mit dem Namen „Mainframe-Software“ sagt nicht, welche Gebühr sinkt, wenn eine Anwendung umzieht.

MIPS schätzen Kapazität, bilden aber selten die Rechnung nach

MIPS bedeutet Millionen Befehle pro Sekunde, ist aber weder eine stabile Einheit für geleistete Geschäftsarbeit noch die allgemeine Rechnungswährung von IBM. Befehlsmischungen unterscheiden sich. Neuere Prozessorgenerationen erledigen bei einer nominalen Kapazitätsstufe mehr brauchbare Arbeit. I/O-lastige Batches, Transaktionsverarbeitung, Komprimierung, Java und Datenbankarbeit belasten die Maschine auf unterschiedliche Weise. Eine MIPS-Zahl ohne Quelle und Messmethode ist ein Etikett, kein Beleg.

Unternehmen nutzen MIPS trotzdem für die Planung, weil die Größe einen vertrauten Maßstab liefert. Manche Lieferanten verwenden außerdem MIPS-Bänder in Verträgen. Das macht die Zahl relevant, aber nicht universell. Fragen Sie bei jedem MIPS-Wert, ob es sich um ein Maschinen-Rating, beobachtete Nutzung, einen Peak, einen Durchschnitt oder ein vertragliches Band des Lieferanten handelt. Diese Werte sind nicht austauschbar.

Die gefährliche Abkürzung sieht so aus:

annual mainframe cost = total MIPS x assumed price per MIPS

Diese Formel verbirgt Mindestabnahmen, Softwarestufen, Specialty Engines, Entwicklungsmaschinen, Speicher und Personal. Sie unterstellt auch, dass der nächste MIPS so viel kostet wie der erste. Verträge widerlegen diese Annahme oft. Eine kleine Kapazitätserhöhung kann eine neue Stufe auslösen; eine moderate Senkung spart womöglich nichts, bis die Mindestabnahme oder das Band sinkt.

Nutzen Sie MIPS stattdessen als Plausibilitätsprüfung. Wenn ein Inventar behauptet, eine Anwendung verbrauche die Hälfte der Umgebung, während aus SMF abgeleitete Berichte einen viel kleineren Anteil der Nutzung allgemeiner Prozessoren zeigen, untersuchen Sie die Abgrenzung. Die Anwendungsschätzung kann Datenbank- und Middleware-Arbeit einschließen, die anderswo verrechnet wird, oder die Messung lässt Batch-Jobs unter einer anderen Kennung aus. Diese Auseinandersetzung ist nützlich, weil sie Zuständigkeiten offenlegt. Einen unsicheren MIPS-Gesamtwert mit einem ebenso unsicheren Preis zu multiplizieren, versieht Unsicherheit nur mit einem Währungssymbol.

MSU-Abrechnung folgt gemessener Kapazität und Vertragsregeln

Eine MSU, eine Million Service Units, ist eine Kapazitätsgröße für die Preisbildung bei IBM-Mainframe-Software. Sie liegt näher an der Abrechnung als MIPS, ist aber noch kein Preis. Die Gebühr hängt von Produkt, Preismodell, berechtigter Maschine, Vertrag, Land, zugesagter Stufe und gemeldeter Nutzung ab. Misstrauen Sie jedem, der einen universellen Geldbetrag pro MSU anbietet.

Bei vielen Sub-Capacity-Modellen beobachten Betreiber den gleitenden Vier-Stunden-Durchschnitt, meist R4HA genannt. Workload Manager zeichnet den Serviceverbrauch auf, und das Sub-Capacity Reporting Tool verarbeitet die maßgeblichen Daten zu Berichten für berechtigte Softwaregebühren. Die SCRT-Dokumentation von IBM verlangt ausdrücklich vollständige, gültige Eingaben für den Berichtszeitraum. Diese Anforderung zählt: Fehlende Intervalle beweisen keine kostenlose Last. Sie sind ein Berichtsfehler, der die Annahme oder Berechnung des Berichts beeinflussen kann.

In der Praxis werden drei verschiedene Werte häufig vermischt:

• Momentane Nachfrage zeigt dem Betrieb, was gerade geschieht.
• Ein gleitender Durchschnitt glättet diese Nachfrage über das festgelegte Fenster.
• Der Rechnungswert wendet Produktberechtigung und Vertragsregeln auf die gemeldete Kapazität an.

Wer sie verwechselt, erzeugt erfundene Einsparungen. Das Entfernen eines Jobs außerhalb des Peak-Fensters kann CPU-Stunden und Strom senken, während die Softwaregebühr unverändert bleibt. Selbst Arbeit im Peak zu entfernen kann nichts sparen, wenn eine andere Last den neuen Höchstwert setzt, eine Mindestmenge gilt oder das Produkt auf derselben Maschine weiter benötigt wird.

Erstellen Sie eine Ansicht der Peak-Beiträge aus den zugrunde liegenden Intervallen. Erfassen Sie für jedes Produkt und jede logische Partition den Zeitpunkt des monatlichen Höchstwerts, die in diesem Fenster aktiven Lasten, die gemeldeten MSUs, die vertragliche Untergrenze oder Stufe und die nächste niedrigere wirtschaftliche Schwelle. Testen Sie danach das Entfernen der Last gegen die gesamte Zeitreihe. Ziehen Sie nicht den durchschnittlichen MSU-Wert einer Anwendung vom gemeldeten Peak ab. Peaks wandern.

Specialty Engines machen die Rechnung ebenfalls komplizierter. Berechtigte Arbeit auf zIIP oder anderer Spezialkapazität kann die Wirtschaftlichkeit ändern, lässt aber die umgebende Software, den Speicher, den Betrieb oder die Rückfallkapazität nicht verschwinden. Dokumentieren Sie, welche Arbeit berechtigt ist, wo sie tatsächlich lief und was bei Engpässen oder Failover geschieht. Kapazitätsberechtigung ist eine technische Eigenschaft; das Rechnungsergebnis ist eine Vertragseigenschaft. Sie brauchen beides.

Auch die Berichtskette braucht eine eigene Abstimmung. Ordnen Sie jeden Central Processor Complex und jede LPAR den Maschinenkennungen im Bericht zu. Ordnen Sie danach jedes berechnete Produkt den Orten zu, an denen es lizenziert und eingesetzt wird. Prüfen Sie, ob Entwicklung, Test, Recovery und Produktion unter der richtigen Preisbehandlung erscheinen. Eine LPAR, die im Anwendungsinventar fehlt, kann trotzdem zu einer Produktrechnung beitragen; eine auf einer LPAR aufgeführte Anwendung muss das Produkt nicht verwenden.

Bewahren Sie die Rohdaten der Intervalle für die modellierten Monate auf. Ein monatliches Maximum ohne die umliegenden Intervalle zeigt nicht, was passiert, wenn ein Job verschoben, früher beendet oder an einem anderen Tag ausgeführt wird. Spielen Sie für eine Kandidatenlast die Berechnung über jedes Intervall erneut durch und entfernen Sie nur den Verbrauch, den Sie ihr zurechnen können. Berechnen Sie den gleitenden Durchschnitt neu und suchen Sie den neuen Höchstwert. Das bleibt eine Schätzung, weil Produktregeln und Verträge über den Kapazitätsdaten liegen, ist aber wesentlich besser als ein Jahresmittel von einem einzelnen Peak abzuziehen.

Die Wiederholung zeigt außerdem Lastverdrängung. Angenommen, ein Abschlussprozess erzeugt den Dienstags-Peak und ein Rechnungslauf liegt am Donnerstag nur knapp darunter. Das Entfernen des Abschlusses spart nicht dessen gesamten Dienstagsbeitrag. Donnerstag wird zum Kapazitätshöchstwert, also kann allenfalls die Differenz zwischen altem und neuem Peak die Messstufe beeinflussen. Bleiben beide Peaks im selben Vertragsband, kann die direkte Rechnungsänderung null sein.

Bitten Sie das Software Asset Management um Berechtigungsnachweis und Rechnung, nicht nur um die Produktliste der Systemprogrammierer. Ein Produkt kann installiert, aber unter einer Vereinbarung kostenlos sein, als Suite berechnet werden, einem Minimum unterliegen oder Teil eines größeren Vertrags sein. Umgekehrt kann eine im Code-Inventar nebensächlich wirkende Komponente eine eigene Support- oder Nutzungsgebühr tragen. Die Beschaffungssprache entscheidet, was gekündigt werden kann; die technische Bestandsaufnahme entscheidet, ob eine Kündigung sicher ist. Kein Team kann die Zeile allein fertigstellen.

Entwicklungs- und Testkapazität braucht gesonderte Aufmerksamkeit. Teams verteilen alle Nichtproduktionskosten oft nach Produktions-CPU, obwohl eine Anwendung mit vielen Releases viel mehr Testzeit verbrauchen kann, als ihr Produktionsanteil vermuten lässt. Erfassen Sie dedizierte Umgebungen, dort zu lizenzierende Produkte, die Haltung von Testdaten und aktive oder Standby-Rechte für Disaster Recovery. Eine Migration kann Produktionslast entfernen und trotzdem ein Test-Image für historische Fehler, Steueranfragen oder einen späteren Downstream-Umzug am Leben halten.

Behandeln Sie Listenpreise nicht als Rechnungsdaten. Öffentliches Material kann die Form einer Metrik erklären, doch ausgehandelte Vereinbarungen, Pakete, Obergrenzen und Mindestmengen bestimmen den echten Geldfluss. Wenn Vertragszugriff beschränkt ist, schützen Sie das Modell genauso, statt es durch eine öffentliche Schätzung zu ersetzen. Eine bereinigte Managementansicht kann Kostenarten und Entfernungsdaten zeigen, während der kontrollierte Anhang Lieferanten- und Preisdetails enthält.

Währung und Abrechnungsperioden können Vergleiche ebenfalls verzerren. Normalisieren Sie Rechnungswährungen nach der von Finance genehmigten Methode, ordnen Sie vorausbezahlten Support dem abgedeckten Zeitraum zu und trennen Sie Steuern vom Lieferantenumsatz, wenn der Business Case sie anders behandelt. Stimmen Sie Gutschriften und einmalige Korrekturen ab, statt still einen günstigen Monat zu wählen. Eine Zwölfmonatsansicht sollte jede wesentliche Differenz zwischen vertraglichem Jahreswert, Rechnungszahlung und Hauptbuch erklären.

Vergeben Sie schließlich Konfidenz pro Aussage, nicht für die gesamte Arbeitsmappe. Eine unterschriebene Kündigungsklausel kann eine Lizenzeinsparung sehr sicher machen. Eine aus unvollständigen Lastkennungen abgeleitete Peak-Senkung bleibt unsicher, bis die Messung besser wird. Ein Hardware-Ausstieg, der von drei späteren Migrationen abhängt, ist bedingt. Stellen Sie fehlende Belege und Verantwortliche neben jede unsichere Zeile. Entscheider können mit Unsicherheit umgehen, wenn sie deren Ursache und die nötige Klärungsarbeit sehen.

Hardwarekosten sind größer als die Bestellung

Hardwarekosten umfassen Kauf- oder Leasingraten, Herstellerwartung, Platten- und Bandsysteme, Netzwerktechnik, Betriebskapazität, Ersatzteile und den zweiten Standort. Manche Unternehmen besitzen den Prozessor und zahlen steigende Wartung. Andere erneuern ihn über Finanzierung. Die buchhalterische Darstellung unterscheidet sich, aber die Zahlungsverpflichtung hat immer eine Laufzeit und eine Ausstiegsbedingung.

Ein Prozessor-Upgrade kann Software außerdem in ein höheres Kapazitätsband ziehen, obwohl sich die Geschäftslast kaum ändert. Umgekehrt kann die Verlagerung von Last keine Ersparnis bringen, solange das Leasing läuft oder eine kleinere Konfiguration die Resilienzanforderungen verletzt. Trennen Sie Abschreibung von vermeidbarem Geldfluss. Abschreibung kann nach der Migrationsentscheidung weiterlaufen; eine Wartungsverlängerung lässt sich womöglich vermeiden.

Für den Betrieb brauchen Sie Messwerte statt Folklore. Nutzen Sie gemessenen Strom, soweit verfügbar, vertragliche Flächen- und Cage-Gebühren, Kühlungsumlagen, Remote-Hands-Kosten und Disaster-Recovery-Aufwand. Beginnen Sie den Business Case trotzdem nicht mit Strom. In vielen Umgebungen bestimmen Software und knappes Personal die Entscheidung. Energie zählt vor allem dann, wenn der Plattformausstieg eine Betriebspflicht wirklich beendet oder deutlich verkleinert.

Erfassen Sie für jede physische Gebühr das früheste Entfernungsdatum. Wenn die Maschine zwölf Systeme trägt und Sie eines migrieren, ändern sich Chassis, Wartung und Recovery-Standort womöglich überhaupt nicht. Deshalb weichen Einsparungen auf Anwendungsebene und echter Geldfluss auf Estate-Ebene oft voneinander ab.

Der teure Spezialist trägt meist mehrere Aufgaben

Mainframe-Personal lässt sich nicht modellieren, indem man COBOL-Entwickler zählt und Gehälter multipliziert. Schwer ersetzbare Menschen decken oft Produktionssteuerung, JCL, Scheduler-Verhalten, RACF-Administration, CICS- oder IMS-Betrieb, Db2-Recovery, Performance-Analyse, Speicher, Releases, Störungsdiagnose und Wissen ab, das nie in ein Runbook gelangte. Ein Name im Organigramm kann fünf Betriebsrollen verbergen.

Zerlegen Sie Personal in Fähigkeiten. Erfassen Sie für jede Fähigkeit Hauptperson, Vertretung, geplante Wochenarbeit, Rufbereitschaft, externe Abhängigkeit und das System, das sie weiter verlangt. Das zeigt Konzentrationsrisiko, ohne einen erfundenen Geldwert für „Stammeswissen“ anzusetzen. Es verhindert auch einen häufigen Fehler: ein ganzes Gehalt als Ersparnis zu buchen, obwohl die Person den Ersatz betreibt, eine andere Mainframe-Last stützt oder bis zur Stilllegung bleibt.

Für Auftragnehmer und Lieferantenpauschalen gilt dasselbe. Ein Retainer kann erst zur Verlängerung kündbar sein. Ein Spezialist kann mehrere Anwendungen betreuen. Ein Outsourcer kann ein Mindestteam oder einen Service Tower berechnen. Lesen Sie Leistungsbeschreibung und Kündigungsfrist, bevor Sie einen Betrag variabel nennen.

Ich halte nichts davon, Ersatzbeschaffungskosten als jährliche Mainframe-Personalkosten anzusetzen. Der Ansatz ist beliebt, weil Ruhestandsrisiken real sind und Recruiter eine große Zahl liefern können. Er ist falsch, weil eine hypothetische Notbesetzung nicht den aktuellen Run Rate darstellt. Führen Sie zwei Spalten: laufender Personalaufwand und bezifferte Übergangs- oder Resilienzgefährdung. Ein Board kann mit beidem entscheiden; es kann eine gemischte Angstprämie nicht prüfen.

Unterstellen Sie nicht, dass eine Migration diese Menschen sofort überflüssig macht. Während Paritätstests und Cutover wird ihr Wissen wichtiger. Danach kann die beste Lösung sein, sie als Domänenverantwortliche zu behalten und nur die Rufbereitschaft für veraltete Infrastruktur abzubauen. Die Ersparnis kann aus vermiedenen Vertragsverlängerungen, weniger Rufbereitschaft oder nicht nachbesetzten Stellen entstehen statt aus Entlassungen.

Jede Zeile einer Workload-Rechnung braucht Belege

Eine belastbare Workload-Rechnung führt jeden zugeordneten Betrag auf eine Quelle zurück und kennzeichnet sein Verhalten. Beginnen Sie mit zwölf Monaten Rechnungen und Nutzungsberichten, damit Jahresabschluss-Batch, saisonaler Peak oder jährliche Supportgebühr nicht verschwinden. Stimmen Sie die Summe mit dem Hauptbuch ab, bevor Sie Anwendungen auch nur einen Cent zuweisen.

Verwenden Sie eine Tabelle mit dieser Form:

cost_id,annual_cash,billing_driver,contract_floor,renewal_date,workload_share,removal_trigger,evidence
SW001,REDACTED,product_peak_msu,REDACTED,YYYY-MM-DD,measured,lower_tier_at_renewal,SCRT_report
HW004,REDACTED,fixed_lease,full_term,YYYY-MM-DD,shared,lease_end,signed_contract
LAB007,REDACTED,dedicated_effort,none,YYYY-MM-DD,time_study,role_reassigned,staffing_plan

Lassen Sie Beträge in Arbeitsbeispielen unkenntlich, verlangen Sie aber echte Zahlen im kontrollierten Modell. Die nützliche Spalte heißt removal_trigger. Sie zwingt den Analysten, das Ereignis zu benennen, das den Geldfluss ändert: eine niedrigere, bei Verlängerung akzeptierte Softwarestufe, eine gekündigte Lizenz, ein beendetes Leasing, eine stillgelegte Maschine, ein verkleinerter Support Tower oder eine unbesetzte Vakanz. „Anwendung migriert“ reicht selten.

Ordnen Sie danach jede Zeile einer von vier Verhaltensarten zu: mit dieser Last vermeidbar, erst nach einer Gruppe von Lasten vermeidbar, bis zu einem Datum fest oder nach Migration beibehalten. Rechnen Sie das Modell zweimal. Die Workload-Sicht zeigt wirtschaftlichen Verbrauch; die Cash-Sicht zeigt Rechnungen und Gehälter, die sich wirklich ändern. Beide sind legitim, doch nur die zweite finanziert einen Business Case.

Eine einfache Rechnung macht den Unterschied sichtbar:

run-rate allocation = annual cash x workload share
year-1 cash saving = annual cash x removable share x active fraction of year
net year-1 effect = year-1 cash saving - migration cash cost - overlap cost
steady-state saving = terminated and resized annual obligations

Schreiben Sie geschätzte Risikosenkung nicht in die Zeile für Geldeinsparungen. Verfolgen Sie geringeres Ausfallrisiko, Prüfaufwand, Recovery-Komplexität und Personalkonzentration als Entscheidungsfaktoren mit Verantwortlichen und Belegen. Wenn Sie sie später monetarisieren, zeigen Sie Wahrscheinlichkeit und Auswirkungsannahmen getrennt.

Vor der Freigabe sollen Finance, Plattformbetrieb, Beschaffung und Anwendungsverantwortliche die Zeilen bestätigen, die sie verstehen. Beschaffung erkennt Verlängerungsfallen. Betrieb erkennt gemeinsame Abhängigkeiten. Der Application Owner findet fehlende Batches und Schnittstellen. Finance verhindert, dass eine Umlage wie entfernter Aufwand aussieht.

Migration entfernt Verträge erst nach gemeinsamen Abhängigkeiten

Eine Migration kann Anwendungslizenzen, Kapazitätsnachfrage, Speicherwachstum, Batch-Fenster, Spezialistenabdeckung und Hardwarepflichten entfernen. Sie entfernt jeden Teil an einem anderen Datum. Eine sichere Prognose nutzt eine Abhängigkeitsleiter statt eines Prozentsatzes für die gesamte Umgebung.

Grenzen Sie zuerst die Last vollständig ab. Erfassen Sie Online-Transaktionen, geplante Jobs, Dateiübertragungen, Druck, Datenbankprozeduren, Security-Regeln, Betriebsskripte, Abstimmung und nachgelagerte Verbraucher. Ein Web-Frontend in einem neuen Service entfernt die Datenbank oder ihren Betrieb nicht, solange das führende System in Db2 bleibt. Ein neu geschriebener Batch, der für drei Abschlussjobs weiter JCL einreicht, entfernt die Scheduler-Abdeckung nicht.

Bestimmen Sie danach für jede gemeinsame Position die Schwelle für gestrandete Kosten. Ein Softwareprodukt kann erst verschwinden, wenn seine letzte abhängige Last eine LPAR verlässt. Bandbetrieb kann wegen Aufbewahrungspflichten bleiben. Die Recovery-Maschine richtet sich womöglich nach dem größten verbleibenden Service. Netzwerkleitungen können andere Systeme versorgen. Deshalb kann eine Portfolioreihenfolge mehr Wert schaffen als Anwendungen nur nach scheinbaren Kosten auszuwählen.

Planen Sie anschließend die Beendigungsarbeit ein. Archivieren Sie Daten nach genehmigter Aufbewahrungsregel, entfernen Sie Identitäten und Scheduler-Einträge, stoppen Sie Feeds, belegen Sie Recovery für den Ersatz, aktualisieren Sie Betriebsverfahren, senden Sie Vertragsmitteilungen und entsorgen Sie Hardware korrekt. Eine Last ohne Traffic kann weiter Geld kosten und bei einer Prüfung durchfallen.

CodeHero schreibt den gesamten Legacy-Codebestand in Go, Rust und TypeScript neu und prüft das Verhalten mit einem Parity Harness gegen aufgezeichneten Produktionsverkehr. Das kann die Umsetzung auf unter 30 Tage verkürzen, doch Vertragsfristen, Aufbewahrungspflichten und gemeinsame Plattform-Ausstiegsdaten bestimmen weiter, wann die Jahreskosten sinken.

Mehrere Kosten bleiben auf der neuen Plattform

Migration verändert die Kostenstruktur, sie schafft Production Engineering nicht ab. Der Ersatz braucht Compute, Datenbanken, Speicher, Observability, Backups, Sicherheitskontrollen, Support, Incident Response, Disaster Recovery und Menschen mit Kenntnis der Geschäftsregeln. Ein Modell, das diese Positionen auf null setzt, ist Fürsprache statt Analyse.

Cloud-Rechnungen brauchen dieselbe Disziplin wie Mainframe-Rechnungen. Trennen Sie Grundkapazität, Lastspitzen, Managed-Database-Gebühren, Netzwerktransfer, Backup-Aufbewahrung, Nichtproduktionsumgebungen und Support. Vergleichen Sie keine voll belastete Mainframe-Zahl mit einer nackten VM-Schätzung. Rechnen Sie Parallelbetrieb während der Prüfung und temporären Speicher für Datenbewegung ein.

Einige Pflichten werden günstiger, weil verbreitete Arbeitsmärkte und Werkzeuge spezialisiertes Plattformwissen ersetzen. Andere ziehen nur um. RACF-Policy kann zu Identity-and-Access-Policy werden. SMF-Monitoring wird womöglich zu Logs, Metriken und Traces. Db2-Backup und Recovery werden zu Postgres-Backup und Recovery. Benennen Sie für jede Kontrolle einen neuen Verantwortlichen, bevor Sie den alten entfernen.

Auch Performance-Spielraum bleibt. Mainframes verarbeiten gemischte Transaktions- und Batchlast mit reifen Workload-Kontrollen. Ein Ersatz muss beobachtete Latenz, Durchsatz, Abschlussfenster und Recovery-Verhalten unter echter Nachfrage erfüllen. Dimensionieren Sie ihn aus Produktions-Traces und Testergebnissen, nicht aus Quellcodezeilen. Architekturmodernisierung kann Verschwendung senken, doch das Budget sollte nur belegte Kapazität ansetzen.

Legen Sie die Baseline fest, bevor Sie Migrationsangebote anfordern. Fixieren Sie die Grenze der Umgebung, den zwölfmonatigen Kostenzeitraum und die Behandlung gemeinsamer Dienste. Listen Sie geplante Prozessorerneuerungen, Vertragsverlängerungen, Rechenzentrumsumzüge oder Personaländerungen auf, die auch ohne Migration kämen. Sonst erhält das Projekt Einsparungen gutgeschrieben, die schon beschlossen waren, oder trägt eine Kostensteigerung, die die heutige Plattform ebenfalls verursacht hätte.

Zeigen Sie mindestens drei Zeitbilder. Die gebundene Sicht enthält Pflichten, die noch nicht veränderbar sind. Die Ausstiegsjahressicht enthält unterjährige Kündigungen und Parallelbetrieb. Die stationäre Sicht beginnt erst, nachdem alte Produktion, Recovery, Aufbewahrung und Support beendet sind. Kennzeichnen Sie das Startdatum jeder Sicht. Eine Jahreszahl ohne Kalender unterstellt still, dass jede Ersparnis am ersten Tag beginnt.

Nutzen Sie Gates für den Ausstieg statt eines hoffnungsvollen Cutover-Datums. Traffic-Cutover ist ein Gate. Der finanzielle Ausstieg kann außerdem einen abgeschlossenen Produktionszyklus, abgestimmte Ergebnisse, einen akzeptierten Recovery-Test, eine abgelaufene Rückfallfrist, archivierte Datensätze, entfernte Zugänge, abgenommene Services und bestätigte Vertragsmitteilungen verlangen. Geben Sie jedem Gate Verantwortliche und Belege. Rutscht eines, muss das Kostenmodell die verbundene Ersparnis automatisch verschieben.

Die Paritätsphase braucht ein eigenes Budget. Beide Plattformen können dieselben aufgezeichneten oder live anfallenden Geschäftsfälle verarbeiten, während Teams Ergebnisse vergleichen, Abweichungen untersuchen und den Betrieb belegen. Berücksichtigen Sie doppelte Compute- und Speicherkosten, Datenextrakte, Testausführung, Fehlerarbeit und die Menschen, die Gleichwertigkeit freigeben. Verbergen Sie diesen vorübergehenden Aufwand nicht in einem pauschalen Risikozuschlag; binden Sie ihn an Prüfplan und erwartete Zyklen.

Definieren Sie eine Regel für Rest-Ausnahmen. Ein Ersatz, der fast allen Traffic verarbeitet, aber seltene Fälle zum Mainframe zurückschickt, erhält genau die Abhängigkeit, die die Stilllegung blockiert. Zählen Sie die Häufigkeit, bestimmen Sie die Geschäftsregel und entscheiden Sie, ob Sie sie implementieren, genehmigt stilllegen oder mit einem begrenzten manuellen Prozess betreiben. Ein undefinierter Rückfallpfad kann eine ganze Lizenz- und Supportkette am Leben halten.

Vergleichen Sie nach dem Cutover über mehrere Rechnungszyklen die Rechnungen mit der Prognose. Bestätigen Sie, dass gemeldete Peaks, Produktstufen, Supportmengen, Speicher, Leitungen und Auftragnehmerkosten wie erwartet wechselten. Schließen Sie Bestellungen und entfernen Sie automatische Verlängerungen, statt anzunehmen, ein ungenutzter Dienst beende seine Abrechnung selbst. Erfassen Sie Prognoseabweichungen je Kostenzeile, damit die nächste Migration beobachtetes Entfernungsverhalten statt einer weiteren Pauschale nutzt.

Die endgültige Freigabe sollte festhalten, wer gestrandete Kosten trägt. Wenn eine Anwendung umzieht, ein gemeinsames Produkt aber bleibt, darf die Ersparnis nicht in ihrem Fall und später erneut im Estate-Fall auftauchen. Führen Sie ein zentrales Register beanspruchter, realisierter und weiterhin gestrandeter Beträge. Das verhindert Doppelzählung und gibt Portfolioplanern einen sachlichen Grund, die nächsten Lasten nach den teuersten verbleibenden Abhängigkeiten zu gruppieren.

Die Entscheidung beruht auf entfernbarem Geld und einem Termin

Die Investitionsvorlage sollte drei Summen zeigen: den heutigen jährlichen Geldabfluss, die stationären Kosten des Ersatzes und das Übergangsgeld für den Weg dazwischen. Daneben steht ein datierter Plan der endenden Verpflichtungen. So werden verzögerte Einsparungen sichtbar, und Überlappung im ersten Jahr verschwindet nicht in einer annualisierten Zahl.

Belasten Sie die Annahmen, die die Entscheidung umkehren können. Testen Sie einen unveränderten Software-Peak, ein nicht vorzeitig kündbares Leasing, ein für eine andere Anwendung verbleibendes Produkt, mehr Ersatzkapazität, längere Datenaufbewahrung und eine zusätzliche Parallelphase. Funktioniert der Fall nur, wenn am Cutover-Tag alle gemeinsamen Kosten verschwinden, funktioniert er nicht.

Die Entscheidung ist nicht nur finanziell. Eine Umgebung kann wegen langer Änderungszeiten, Recovery-Risiko oder Personalkonzentration eine Migration rechtfertigen, selbst wenn die enge Ersparnis im ersten Jahr bescheiden ist. Sagen Sie das offen. Verstecken Sie strategische Gründe nicht in erfundener Kostenvermeidung.

Beginnen Sie die Freigabeunterlage mit Vertragsregister, SCRT-gestützter Peak-Sicht, Fähigkeitskarte, Workload-Grenze und Removal-Trigger-Tabelle. Diese fünf Artefakte geben Technik und Finance etwas, das sie prüfen können. Sobald jede behauptete Ersparnis Verantwortliche, Auslöser und Datum hat, endet die Debatte über MIPS-Folklore und es entsteht ein Plan, den das Unternehmen umsetzen kann.