Ein Arbeitsvorbereitungsplan für SAP ECC Ende der regulären Wartung 2027

Wenn Ihr Batch-Plan auf SAP ECC läuft, nähert sich die darunterliegende Plattform einem kritischen Wartungsablaufdatum. Die meisten Hinweise zur Deadline 2027 behandeln die ERP-Migration als Ganzes – das Datenmodell, den benutzerdefinierten Code, den funktionalen Umfang. Dieser Leitfaden ist enger gefasst und operationeller: Er ist der Plan für das Team, das die Aufträge besitzt. Er führt fünf Schritte durch, um Ihren Planungsstatus von einer nicht dokumentierten ECC-Abhängigkeit zu einer kartierten, rationalisierten, portablen Arbeitslast zu führen, die mit Ihnen mitgeht – egal welches Ziel Sie wählen.

Was die Deadline 2027 verändert

SAP hat feste Termine für das Ende der regulären Wartung von SAP ERP 6.0, dem Kern der SAP Business Suite 7, festgelegt. Für die heute meisten Kunden genutzten Erweiterungspakete (EHP 6 bis 8) endet die reguläre Wartung am 31. Dezember 2027, gefolgt von optionaler erweiterter Wartung bis Ende 2030 zu einem Aufpreis auf der Wartungsbasis. Die älteren EHP 0–5-Versionen erreichten bereits am 31. Dezember 2025 das Ende der regulären Wartung, sodass diese Systeme in kundenspezifische Wartung umgestiegen sind – eine Phase, deren reduzierter Umfang keine rechtlichen und regulatorischen Aktualisierungen mehr umfasst. Berechtigte große Unternehmen, die besonders komplexe Programme auf Cloud-Infrastruktur umstellen, haben eine weitere Option: eine private Edition über RISE, die den ECC-Betrieb für ausgewählte Kunden erweitert, vorbehaltlich SAPs Berechtigungs-, Architektur-, Geschäfts- und Übergangsanforderungen. Welchen Weg Sie wählen, der Planungsnachlass benötigt einen expliziten Plan: Migration zu einem unterstützten Ziel, Neugestaltung für eine neue Schnittstelle oder Einstellung. Diese Arbeit läuft parallel zum funktionalen Projekt – sie hat ihren eigenen kritischen Pfad, und die fünf folgenden Schritte sind dieser Weg.

Schritt 1 – Inventar: Kartiere jeden Auftrag, bevor du ihn verschiebst.

Man kann nicht migrieren, was man nicht kartiert hat, und viele ECC-Estate können keine vollständige Karte auf Abruf erstellen. Jobs, die direkt von den Nutzern in SM36 geplant werden, also die SAP-Transaktion zur Definition von Hintergrundjobs, bleiben in SAP sichtbar, liegen aber außerhalb eines zentralen Katalogs, sodass der tatsächliche Umfang einer Migration fast immer größer ist als der dokumentierte. Der erste Schritt ist, jeden nicht verwalteten Job unter zentrale Verwaltung zu bringen. Job-Extraktion und Spiegelung ziehen benutzerdefinierte SAP-Jobs in einen einzigen verwalteten Katalog, sodass der Umfang, gegen den du planst, real ist und nicht angenommen. Das ist die Grundlage dafür, versteckte Abhängigkeiten aufzudecken, bevor sie zu Cutover-Problemen werden.

Schritt 2 — Rationalisieren: Verkleinen Sie den Nachlass, bevor Sie ihn übernehmen

Ein kleineres System migriert schneller. Jahre angesammelter Hausarbeit, einmaliger Berichte und ersetzter Prozesse erhöhen die Planungskomplexität. Unnötige Anwendungsdaten erhöhen zudem das Verarbeitungsvolumen während der Archivierung, Systemkopie, Sicherung und Migration – was die S/4HANA-Roadmap verzögert, indem sie jeden technischen Schritt auf dem Weg verlängert. Die Reduzierung unnötiger Daten und veralteter Planungslogik kann den Migrationsumfang vereinfachen und den Aufwand reduzieren. Zwei Maßnahmen verkürzen den Bestand:

• Archivieren Sie mit SARA. Datenarchivierung – Schreiben, Löschen und Speicheren über Archivierungsobjekte hinweg – verkleinert die zugrunde liegenden Tabellen, die die Migration verarbeiten muss.
• Beenden Sie die Hausarbeit, die aus Gewohnheit laufen. Der zentrale Katalog aus Schritt 1 ermöglicht Ihnen endlich, den vollständigen Satz der wiederkehrenden technischen und administrativen Arbeitslasten im gesamten Nachlass zu sehen. Diese Transparenz erleichtert die Identifizierung von alten Zeitplänen, doppelten Prozessen, veralteten Berichten, Überwachungsaufgaben und Wartungsarbeiten, die keinen Geschäftswert mehr bieten. Überprüfen Sie jede Arbeitslast gezielt und entfernen Sie das, was nicht mehr benötigt wird, bevor Sie es in die Zielumgebung bringen. Unser Leitfaden zur Hintergrundplanung von Jobs im Unternehmensmaßstab geht durch die typischerweise angesammelten Housekeeping-Arbeitslasten und wie Teams diese unter Governance bringen.

Schritt 3 – Wähle die Zieltopologie

"Migration von ECC" ist kein einzelnes Ziel. Die Planungsimplikationen unterscheiden sich über vier gemeinsame Landezonen, und die Schnittstelle, durch die deine Jobs laufen, ändert sich mit jedem. Bestimmen Sie das Ziel, bevor Sie konvertieren – es bestimmt alles nachgelagert. Die meisten dieser Ziele stellen XBP frei, SAPs zertifizierte externe Schnittstelle für die Hintergrundverarbeitung; das tut man nicht.

Die durchgehende Handlung: Der gleiche SAP-Jobtyp umfasst SAP R/3 und S/4HANA, sodass ein S/4HANA-Wechsel kein neues Plugin benötigt und ein RISE-Wechsel nur eine geringfügige Konfigurationsänderung darstellt. Die einzige bedeutende Verschiebung ist die GROW Public Cloud, wo die Planungsfläche unterschiedlich ist. Unser RISE-, Clean-Core- und GROW-Leitfaden vergleicht die vier Topologien vollständig, einschließlich Agentenplatzierung, Verschlüsselung und des High-Availability-Modells für jede Plattform.

Schritt 4 – Konvertieren statt neu aufbauen

Der Instinkt bei einem Plattformwechsel besteht darin, den Zeitplan in der neuen Umgebung manuell neu zu gestalten. Bei einem Estate jeder Größe ist das langsam, fehleranfällig und wirft die jahrelange Abhängigkeitslogik über Bord – und es ist nicht notwendig. Ein Konvertierungstool importiert bestehende Job-Definitionen direkt – Jobs und Kalender zusammen – und erstellt einen Bewertungsbericht, der das Gefundene aufzählt, basierend auf einer definierten Reihenfolge: das Projekt auswählen, die Daten auswerten, die Konvertierung ausführen, die Ergebnisse validieren und in das Ziel laden. Das Konvertieren statt Neuaufbau bewahrt die systemübergreifende Logik – die Abhängigkeiten, die einen SAP-Job mit der Dateiübertragung, der Bank oder der darauf wartenden Datenplattform verknüpfen – anstatt von einer Person zu verlangen, sie aus dem Gedächtnis zu rekonstruieren. Unser SAP-Batch-Jobs- und ECC-zu-S/4HANA-Migrationsleitfaden behandelt die Umwandlungsmechaniken vollständig.

Schritt 5 – Simulieren und schützen Sie den Wechsel

Das letzte Risiko ist das Cutover-Wochenende selbst, und es gibt zwei Ausfallmodi: einen Batch-Run, der sich auf der neuen Plattform anders verhält, und einen Job, der in SAP schreibt, während die Basis-Arbeit im Zwischenflug ist.

• Simuliere den Durchlauf. Prognostiziere und Was-wäre-wenn-Trockenlauf den Chargenplan gegen die neue Umgebung vor dem Live-Go-Live, damit du die Form des Durchlaufs – und wo er unterbricht – siehst, bevor er echte Daten transportiert.
• Schützen Sie das Fenster. Ein globales Stoppen, Halten und Neustarten über das gesamte Job-Estate stellt sicher, dass während der Upgrade-, Support-Pack- und Enhancement-Arbeiten an einem Umstellungswochenende nichts in SAP eingeladen wird, und gibt den Estate sauber frei, sobald das Fenster geschlossen ist. Upgrade- und Support-Pack-Projekte sind eine bekannte Quelle für Geschäftsprozessstörungen, gerade weil Aufträge immer wieder in ein System einfließen, das dafür nicht bereit ist; ein globaler Hold verringert das Risiko dafür erheblich.

Erstelle deinen Zeitplan

Die Frist ist festgelegt, also planen Sie danach. Die Dauer des S/4HANA-Programms variiert stark je nach Umfang, Landschaftskomplexität, Datenstrategie, benutzerdefiniertem Code, Bereitstellungsmodell und Rollout-Ansatz, also arbeiten Sie rückwärts von der Frist und dem validierten Programmplan Ihrer Organisation aus. Die Mathematik ist straffer, als sie scheint. Stand August 2026 bleiben noch etwa siebzehn Monate, bis die reguläre Wartung für EHP 6–8-Systeme endet. Viele S/4HANA-Programme laufen je nach Umfang zwölf bis vierundzwanzig Monate, was bedeutet, dass das kürzere Ende dieses Zeitraums weiterhin innerhalb des Zeitfensters passt und das längere Ende nicht mehr. Ein Programm, das noch nicht mit dem Scoping begonnen hat, plant in der Praxis bereits um die erweiterte Wartung als Brücke und nicht um das Datum 2027 selbst – und diese Brücke hat einen Aufstieg auf die Wartungsbasis. Für das Planungsteam ist die Abfolge unabhängig vom Ziel gleich:

• Inventar – jeden Auftrag kartieren und zentralisieren
• Rationalisieren — archivieren und in den Ruhestand gehen
• Wählen Sie Topologie – On-Prem, RISE privat, RISE + BTP oder GROW
• Konvertieren und parallel ausführen – importieren, validieren, alte und neue nebeneinander ausführen
• Cutover – simulieren, das Fenster schützen, loslassen

Schritte eins und zwei bringen sofort den Wert zurück – ein kartierter, schlankerer Nachlass ist heute leichter zu führen, Frist hin oder her, was das Argument dafür ist, sie jetzt zu starten, anstatt auf den offiziellen Beginn des Migrationsprojekts zu warten.

Häufig gestellte Fragen

Was passiert mit meinen SAP-Batchjobs, wenn der ECC-Support 2027 endet? Der Wartungsmeilenstein stoppt Ihr SAP-System oder dessen Batch-Jobs nicht automatisch – sie laufen weiter, solange das System läuft. Das Ende ist SAPs Hauptwartung der Plattform unter ihnen am 31. Dezember 2027 für EHP 6–8-Systeme; die ältere EHP 0–5-Frist ist Ende 2025 abgelaufen. Die praktische Arbeit richtet sich nicht auf die Jobs, sondern auf den Nachlass: Inventar aller geplanten Jobs, einschließlich derjenigen, die Nutzer lokal in SM36 erstellt haben; archivieren und zurückziehen, was nicht mehr seinen Platz verdient; dann werden die Definitionen in Ihr gewähltes S/4HANA-Ziel umgewandelt, anstatt sie manuell neu aufzubauen, damit die systemübergreifenden Abhängigkeiten den Umzug überstehen. Diese Arbeit läuft parallel zum funktionalen S/4HANA-Projekt und sollte am besten weit vor der Frist beginnen. Muss ich jeden SAP-Job neu definieren, wenn ich zu S/4HANA wechsle? Nein – mit einer Ausnahme. Der gleiche SAP-Jobtyp umfasst SAP R/3 und S/4HANA, daher benötigt ein S/4HANA-Move kein neues Plugin, und ein Wechsel zu RISE mit SAP ist eine kleine Konfigurationsänderung. Ein Umwandlungstool importiert bestehende Job-Definitionen und Kalender und berichtet, was es gefunden hat, was den manuellen Neuaufbau für Estates jeglicher realer Größe ersetzt. Die Ausnahme ist GROW with SAP, Public Cloud, wo sich die Planungsfläche unterscheidet und der Job-Definitionsansatz entsprechend verschiebt. Nächste Schritte Um zu sehen, wie ein konvertierter Nachlass in der Praxis über SAP- und Nicht-SAP-Systeme läuft, erkunden Sie Control-M für SAP.

Diese Beiträge sind meine eigenen und spiegeln nicht unbedingt die Position, Strategien oder Meinung von BMC wider.