Die Migration zu H4S4 stellt Unternehmen vor technische und organisatorische Herausforderungen. Da die reguläre Wartung klassischer SAP-HCM-Umgebungen ausläuft, wird ein rechtzeitiger Wechsel immer wichtiger. Eine strukturierte Planung hilft dabei, Risiken zu reduzieren und den Umstieg effizient zu gestalten. Entscheidend ist, die einzelnen Projektphasen gezielt vorzubereiten und auch den späteren Betrieb frühzeitig zu berücksichtigen.
Vor dem Projekt: Grundsatzentscheidung und Bestandsaufnahme
Am Anfang steht die Grundsatzentscheidung: Weiter On-Premises betreiben oder in die Private Cloud wechseln? Beides ist möglich, unterscheidet sich aber in Governance, Verantwortlichkeiten und Vertragslogik. Gerade im regulierten Umfeld lohnt eine nüchterne Betrachtung der organisatorischen Folgen der Cloud-Option – inklusive Zeitpuffer für Vertragsprüfung.
H4S4-Upgrade: Ihr Sprung in die SAP-HR-Zukunft
H4S4-Upgrade: Ihr Sprung in die SAP-HR-Zukunft
Wir unterstützen Sie bei Ihrem H4S4-Upgrade.
Danach folgt der Realitätscheck: Eine strukturierte Bestandsaufnahme der Systeme, Schnittstellen und Eigenentwicklungen zeigt, wo Aufräumen Pflicht ist und welche Abhängigkeiten bestehen. Eine Pilotmigration ist besonders wirksam: Sie macht technische und organisatorische Hürden sichtbar, liefert belastbare Laufzeiten und hilft, Test- und Cutover-Pläne zu kalibrieren. Aus diesen Bausteinen entsteht eine Roadmap mit klaren Meilensteinen, Rollen und Kapazitäten.
Während des Projekts: Vorgehen, Aufräumen und Prüfungen
Nach der Planung folgt die Umsetzung: In dieser Phase sorgen ein klares Vorgehensmodell, gezieltes Aufräumen und belastbare Prüfungen für Stabilität.
Ansatz und Umfang: Ziel ist ein verlässliches Brownfield-Vorgehen. Abrechnung und Zeitwirtschaft sollen nach dem Upgrade funktionsgleich laufen; Änderungen werden dort eingeführt, wo Technik es erzwingt oder Altlasten bremsen.
Zeit und Altlasten: Versteckte Referenzen auf „nicht mehr genutzte“ Schemen bzw. Infotypen tauchen oft im Test auf. Konsequentes Aufräumen – insbesondere bei Zeitkollisionen und historischen Regeln – verhindert Überraschungen.
Umgebungseffekte: OS-/DB-Wechsel, Code-Pages, Zeichensätze – Randbedingungen können Output (z. B. Zahlungsdatenträger) beeinflussen. Dress-Rehearsals inklusive Batch-Ketten für Zeit und Payroll sind Pflicht.
Custom Code: Readiness-Checks ersetzen keine ATC-Analyse. Eigenentwicklungen sind gezielt auf HANA-Tauglichkeit, Performance und API-Nutzung zu prüfen.
Identitäten und Geschäftspartner
Mit H4S4 rückt die saubere Führung von Identitäten in den Vordergrund. Der Business User verknüpft SU01-Benutzer und Geschäftspartner; eine einheitliche Regel für die Bildung der IDs verhindert spätere Mapping-Aufwände. Wo möglich, wird auf die Replikation von Geschäftspartnern über Landschaften verzichtet, um Inkonsistenzen zu vermeiden. Ob der Mitarbeiter-Geschäftspartner sofort benötigt wird, hängt vom Prozess ab: Wer Reisekosten ausschließlich über Payroll erstattet, kann die Aktivierung vorbereiten und später nachziehen.
Nach dem Go-Live: Betrieb verstetigen und nachschärfen
Nach der Migration sichern belastbare Betriebsroutinen den Erfolg. Job-Ketten, Monitoring und Benachrichtigungen werden auf Basis der Dress-Rehearsals feinjustiert, während das Betriebshandbuch Zuständigkeiten, Eskalationen und Prüfschritte bündelt. Parallel startet der geplante Abbau von Altlasten, die zugunsten der Stabilität noch nicht angefasst wurden. Dokumentation und Enablement sind kein Anhang, sondern Kern des Projekts: Änderungen und Freigaben werden auditierbar festgehalten, Fach- und IT-Teams gezielt geschult.
Aufwand und Budget: Faktoren statt Fixpreisgefühl
Die Spannweite reicht – abhängig von Landschaft, Eigenentwicklungen, Schnittstellen, Vorprojekten und Testtiefe – von kompakten Aufwänden bis hin zu sechsstelligen Vorhaben. Ausschlaggebend sind neben der Betriebsoption vor allem die Anzahl der Systeme, die Menge an Custom Code, notwendige OS/DB-Wechsel und der angestrebte Testumfang. Wer Pilot und Readiness-Analyse vorschaltet, trifft belastbarere Aussagen und vermeidet Nachsteuerung im kritischen Pfad.
Fazit zu H4S4
H4S4 ist technisch ein Upgrade und organisatorisch ein Migrationsprojekt mit klarer Methode. Wer früh über die Betriebsoption entscheidet, Readiness-Check und Pilotmigration koppelt, Abrechnung und Zeit konservativ hebt, Identitäten sauber führt und Betriebsroutinen von Beginn an mitplant, senkt Risiken spürbar. Nach dem Go-Live sorgen konsequentes Monitoring, dokumentierte Prozesse und der gezielte Abbau von Altlasten für eine stabile Basis – und genau darum geht es im HR-Kernsystem. Der Umstieg sichert also Wartung und Zukunftsfähigkeit, harmonisiert den Betrieb mit dem S/4-Stack und schafft eine stabile Basis für HR-Kernprozesse. Da Wartungsfristen auslaufen (regulär bis Ende 2027, optional bis 2030), lohnt der rechtzeitige Start besonders.
