SAP-Cloud-Migration
S/4 HANA Cloud-Konvertierung
Management Zusammenfassung
- smartShift-Technologien ist ein führender Anbieter von Automatisierungslösungen zur Beschleunigung der digitalen Transformation.
- Wir haben einem Kunden geholfen, seine bestehende SAP-System zum Wolke und gleichzeitig ein Upgrade auf die neueste Version von SAP S/4HANA.
- Amazon Webdienste die Cloud-Infrastruktur für die Umwandlung vor der aktualisiertes SAP-System wurde migriert nach SAPs HANA Enterprise Cloud.
Bis heute, smartShift hat mehr als ein Dutzend Umstellungen von ECC 6-Systemen auf S/4HANA. Bei einer kürzlich erfolgten Umstellung ging es um eine ganz besondere Anforderung in Bezug auf die Infrastruktur, und wir dachten uns, dass dies eine gute Geschichte abgeben würde.
Umstellung von ECC 6 auf S/4HANA auf HEC
Zum Hintergrund: Der Kunde hatte ECC 6 vor Ort im Einsatz, entschied sich aber für die Einführung von SAPs HANA Enterprise Cloud ("HEC") als seine S/4HANA-Hosting-Lösung. Es entstand sofort eine Herausforderung im Zusammenhang mit den Einschränkungen SAP gilt in HEC für den Zugang auf Betriebssystem- und Datenbankebene. Diese Einschränkungen bedeuten, dass, wenn SUM/DMO (siehe unten) vom ECC 6-System des Kunden auf SAP HANA Unternehmenswolke während unserer technische UmsetzungDer Erfolg war jedoch unwahrscheinlich, da die erforderlichen Anpassungen auf Betriebssystem- und Datenbankebene nicht vorgenommen werden konnten. Was ist zu tun?
Kurz gesagt, wir wurden kreativ. Warum arbeiten Sie nicht mit einer Cloud-Anbieter wo wir kann die Kontrolle über die Betriebssystem- und Datenbankebene haben, um die eine exakte Nachbildung des Ziels S/4HANA-System die in SAP HANA Unternehmenswolke. Wenn wir dies tun könnten, könnten wir die Kunden S/4HANA-System außerhalb von SAP HANA Unternehmenswolke und migrieren sie in SAP HEC am Ende unseres technischen Umstellungsprozesses. Auf dem Papier sah das alles möglich aus, aber würde es auch in der Realität funktionieren?
Der erste Schritt war die Ausarbeitung unseres technischen Ansatzes, einer Begründung und eines detaillierten Plans. Außerdem haben wir in erheblichem Umfang Anforderungen gesammelt, um sicherzustellen, dass die Interim-Cloud und die endgültige SAP HANA Unternehmenswolke Die Umgebungen waren bis hin zu den Versionsnummern der Komponenten und den Support-Package-Stacks identisch. Dies wurde den verschiedenen Abteilungen des Kunden vorgestellt und mit ihnen diskutiert. SAP-Fachleutedie gemeinsam mit uns der Meinung waren, dass dies - auf dem Papier - tatsächlich ein gangbarer Weg sei. Der Kunde stimmte schließlich zu, und unsere Reise auf diesem unbekannten Weg zu S/4HANA im Wolke war offiziell im Gange.
Amazon Web Services als Cloud-Anbieter
Der nächste Schritt bestand darin, dass der Kunde sich für eine Cloud-Anbieter um das System zu beherbergen, das von ECC 6 auf S/4HANA und wanderte anschließend nach SAP HANA Unternehmenswolke. Der Kunde wählte Amazon Web Services ("AWS") und beschafften ihre Infrastruktur direkt, da Datenschutzbelange besser über eine direkte vertragliche Beziehung zwischen AWS und dem Kunden zu regeln waren.
Nach der Beschaffung muss der Kunde AWS-Umgebung wurde eingerichtet von smartShift-interne technische Experten. Wussten Sie, dass wir konfiguriert haben Cloud-Umgebungen für viele SAP-Kunden und betreiben sogar eine Cloud Managed Services Geschäft als Teil unseres globalen Serviceportfolios? Sobald SAP on AWS vollständig konfiguriert und verifiziert war, begannen unsere Transformationsaktivitäten.
Transformation mit smartShift und SAP-Werkzeugen
Zunächst erstellten wir eine Kopie der bestehenden ECC 6-Produktivumgebung des Kunden in seiner On-Premise-Infrastruktur, um eine Projektumgebung für unsere technischen Umstellungsaktivitäten zu haben. Anschließend führten wir SAP Software Upgrade Manager / Option Datenmigration ("SUM/DMO") auf diese Projektumgebung und richtete sie auf die SAP-Umgebung auf AWS, die unser hauseigenes Cloud-Team eingerichtet hatte. So konnten wir das ECC 6-System des Kunden vor Ort auf S/4HANA 1709 aktualisieren, das zu diesem Zeitpunkt die aktuellste Version war. S/4HANA Release-Stand verfügbar.
Mit dem S/4HANA 1709 System die in AWS sitzen, haben wir smartShift's intelligente Automatisierungsplattform, um die kundenspezifische Kodierung für den Kunden zu korrigieren S/4HANA. HANA-Performance, HANA-Compliance und S/4-Compliance-Anpassungen wurden vorgenommen, um sicherzustellen, dass die benutzerdefinierte Kodierung optimal in einem Cloud-basiert S/4HANA-Umgebung.
Da der Kunde die Menge der in sein S/4HANA-System migrierten Transaktionsdaten begrenzen wollte, unternahmen wir als Nächstes einen besonderen Schritt bei der technischen Umstellung. Wir erstellten eine sekundäre Instanz des S/4HANA 1709 AWS-Systems und führten eine Mandantenkopie durch, um einen zweiten Mandanten innerhalb dieser sekundären Instanz zu erstellen. Wichtig ist jedoch, dass wir bei dieser Mandantenkopie eine Option gewählt haben, die keine Daten in den zweiten Mandanten bringt, sondern nur die Konfiguration. Dies führte zu einer Zweiter vollständig für S/4HANA konfigurierter Client aber ohne jegliche Altdaten. Der erste Mandant wurde dann bereinigt, so dass nur der zweite "leere" Mandant in der sekundären Instanz übrig blieb. Der Kunde würde zu einem späteren Zeitpunkt eine Datenmigration durchführen, um seine Daten zu ergänzen. S/4HANA-Datenbank mit den begrenzten alten Transaktionsdaten, die sie wünschten.
Projektergebnisse und gewonnene Erkenntnisse
Voilà! Zu diesem Zeitpunkt hatten wir eine erfolgreiche Umsetzung des ECC 6-Vor-Ort-Systems des Kunden auf SAP S/4HANA 1709 gehostet auf AWS ohne veraltete Transaktionsdaten. Es blieb jedoch noch ein letzter und entscheidender Schritt: der Umzug des Systems von AWS in die SAP HANA Enterprise Cloud. Zu diesem Zweck erstellten wir ein HANA-Datenbank-Backup des "leeren" S/4-Systems in AWS und stellten SAP eine über 100 GB große Backup-Datei zur Verfügung, die in die SAP Enterprise Cloud des Kunden importiert wurde. SAP HANA Enterprise Cloud Umgebung. Denn SAP Um das in HEC laufende System des Kunden zu zertifizieren, war es erforderlich, dass SAP den Restore-Schritt dieser Systemmigration durchführt.
Und siehe da, zur Freude des Kunden hat es tatsächlich wunderbar funktioniert. Der technische Plan, den alle auf dem Papier für möglich hielten, funktionierte in der Realität! Ein paar wichtige Erkenntnisse aus diesem Projekt:
- Für Kunden, die Folgendes verwenden möchten SAP HANA Unternehmenswolke als ihre S/4HANA Hosting-Lösung gibt es einen bewährten Ansatz, der es Spezialisten wie smartShift Ihre technische Umstellungsaktivität zu leiten, ohne gegen die SAP HEC Zugangsbeschränkungen auf Betriebssystem- und Datenbankebene. Wenn, wie es bei diesem Kunden der Fall war, die Infrastruktur vor Ort nicht für die Anforderungen Ihrer Übergangsumgebung zur Vervollständigung von SUM/DMO bereitgestellt werden kann, Cloud-Lösungen wie AWS und andere bieten praktikable Alternativen.
- Sicherstellen, dass die Versionsangaben für jedes Stück Hardware und Software bekannt sind. Zu Beginn des Projekts stellten wir fest, dass die SAP HANA Enterprise Cloud Umgebung lief eine veraltete Betriebssystemversion, die nicht in AWS installiert werden konnte. Auch wenn wir nicht sicher sein können, dass dies später im Projekt zu Problemen geführt hätte, hielten wir es für wichtig, solche Risiken zu minimieren, indem wir sicherstellten, dass alle Hardware- und Softwareversionen zwischen AWS und AWS identisch waren. SAP HANA Unternehmenswolke. Wir vermuten, dass diese Liebe zum Detail zu unserem Erfolg bei diesem Projekt beigetragen hat. technische Umsetzung.
Wir hoffen, dass Ihnen dieser Artikel gefallen hat und freuen uns über Ihre Fragen, Kommentare und natürlich über Ihr Interesse an einer Zusammenarbeit mit smartShift-Technologien um Ihre Übernahme der neuesten digitalen Innovationen zu beschleunigen.
EN