SAP-Systeme einfach kopieren statt aufwendig migrieren – zu RISE und S/4HANA ohne Zugriff auf das Betriebssystem

Wie lassen sich SAP-Systeme schnell in eine neue Umgebung bringen, ohne Zugriff auf das Betriebssystem (OS), ohne komplexe Abstimmungen zwischen Teams und ohne lange Projektlaufzeiten? Bei SAP RISE-Migrationen, S/4HANA-Transformationen oder System-Refreshes stoßen klassische Ansätze hier schnell an ihre Grenzen.

Die Lösung: der SAP HANA Tenant Copy-Mechanismus. Er ermöglicht, die Datenbankschicht eines SAP-Systems effizient, ausschließlich über SQL und ohne Betriebssystemzugriff auf beiden Seiten zu kopieren. Die Applikationsschicht wird anschließend in den üblichen Nachkopier-Schritten (Post-Copy-Schritten) wieder mit dem kopierten Mandanten (Tenant) verbunden.

Was ist SAP HANA Tenant Copy?

Der HANA Tenant Copy-Mechanismus basiert technisch auf Log-Shipping – ähnlich wie die SAP HANA System Replication, aber deutlich einfacher in der Anwendung.

Im Unterschied zu klassischen Migrationsmethoden arbeitet Tenant Copy vollständig über SQL.
Das bedeutet konkret:

• Kein Zugriff auf das Betriebssystem erforderlich
• Keine identischen System-IDs (SIDs) notwendig
• Keine identischen Instanznummern erforderlich
• Kein zusätzlicher Konfigurationsaufwand wie HDBUSERSTORE-Einträge

Damit eignet sich Tenant Copy besonders für moderne Cloud- und RISE-Szenarien.

Wann ist Tenant Copy die richtige Wahl?

SAP RISE Migration mit S/4HANA-Upgrade

Der prominenteste Anwendungsfall ist die Migration zu SAP RISE (Rise with SAP, S/4HANA Cloud Private Edition). Im RISE-Modell managed SAP die Zielinfrastruktur — Kunden erhalten keinen OS-Zugriff auf den Ziel-HANA-Host. Klassische Migrationsmethoden, die auf Betriebssystem-Backups oder OS-seitige Dateitransfers setzen, sind damit ausgeschlossen.

Tenant Copy passt hier exakt: SAP stellt für das RISE-Zielsystem SQL-Zugangsdaten bereit. Der gesamte Vorgang findet ohne OS-Koordination statt.

Gut zu wissen: Bei einer RISE-Migration kann der S/4HANA-Upgrade entweder vor der Tenant-Kopie oder nach dem Finalize durchgeführt werden. Die SAP-Projektmethodik gibt die Sequenz im Einzelfall vor.

Weitere Szenarien

Homogene Datenbank-Migration — Wechsel zwischen Rechenzentren, Hosts oder Systemlandschaften ohne Neuaufbau auf der Zielseite.

System-Refresh — Regelmäßige Aktualisierung von QS- oder Testsystemen aus der Produktion. Vollständig über SQL, geeignet zur Automatisierung.

Neue Systeme aus bestehenden Instanzen — Schnelle Bereitstellung für Sandbox-Systeme oder Mandanten-Splits.

Gut zu wissen: Quell- und Ziel-SID müssen nicht identisch sein. Die Zieldatenbank kann auf einer anderen Instanznummer und einem anderen Host laufen.

Tenant Copy vs. System Replication

Beide Mechanismen arbeiten mit Log-Shipping, unterscheiden sich aber erheblich in den Voraussetzungen:

Voraussetzungen

Netzwerkkonnektivität: Das Zielsystem muss den SQL-Port der SystemDB erreichen. Standard: 3<Instanznummer>01 bzw. 3<Instanznummer>13. In restriktiven Netzwerken sind Firewall-Freigaben zu beantragen.

Datenbankzugang: SYSTEM-User (oder technischer User mit äquivalenten Rechten) auf beiden Seiten. Betriebssystem-Accounts werden nicht benötigt.

Plugin-Abgleich (empfohlen): Installierte HANA-Plugins müssen auf beiden Systemen übereinstimmen. Prüfung über M_PLUGIN_MANIFESTS.

Prozessablauf

Das Verfahren gliedert sich in drei Phasen: Vorbereitung (Parameter setzen), Replikation (Kopie starten und überwachen) und Übernahme (Finalisierung und Cleanup).

Phase 1 — Parameter konfigurieren

Die Parameter werden via ALTER SYSTEM ALTER CONFIGURATION in der SystemDB beider Systeme gesetzt. SSL-Parameter sind nur in Ausnahmefällen zu deaktivieren — Produktivumgebungen lassen SSL aktiv.

Quellsystem — global.ini (SYSTEM)

Quellsystem — indexserver.ini (SYSTEM)

Das Zielsystem erhält dieselben global.ini-Parameter (ohne indexserver.ini-Einträge).

Phase 2 — Replikation starten

Alle Schritte in der SystemDB des Zielsystems:

• Ziel-Tenant stoppen (ALTER SYSTEM STOP DATABASE) — bei identischer SID: Tenant löschen (DROP DATABASE)
• Credential anlegen (CREATE CREDENTIAL FOR COMPONENT ‚DATABASE_REPLICATION‘) mit Hostname, Port und SYSTEM-Passwort des Quellsystems
• Kopiervorgang starten (CREATE DATABASE … AS REPLICA OF … AT ‚…‘)
• Fortschritt beobachten über SYS_DATABASES.M_DATABASE_REPLICA_STATISTICS — warten bis REPLICATION_STATUS = ACTIVE

Phase 3 — Übernahme und Cleanup

Applikation am Quellsystem herunterfahren, dann:

• Replikation finalisieren (ALTER DATABASE … FINALIZE REPLICA)
• Credential entfernen (DROP CREDENTIAL …)
• Parameter zurücksetzen auf ursprüngliche Werte
• Port anpassen falls erforderlich (ALTER DATABASE … ALTER ‚indexserver‘)

Vorteile im Überblick

• Kein OS-Zugriff erforderlich — Das gesamte Verfahren läuft über SQL. Betriebssystem-Koordination zwischen Teams entfällt.
• Flexible SID- und Instanz-Zuweisung — Quell- und Ziel-SID müssen nicht identisch sein. Unabhängig von vorhandenen Systemlandschaften.
• Kurze Projektlaufzeiten — Einrichtung dauert typischerweise unter einer Stunde. Kopierzeit abhängig von Datenbankvolumen, nicht von manuellen Prozessen.
• Reproduzierbarkeit — Vollständig scriptbar, etwa über Ansible-Playbooks. Wiederkehrende System-Refreshes können damit automatisiert werden.

Häufige Fragen

Ist Tenant Copy für SAP RISE-Migrationen geeignet?

Ja — im RISE-Modell managed SAP die Zielinfrastruktur; Kunden erhalten keinen OS-Zugriff. Tenant Copy benötigt nur SQL-Zugang, den SAP für RISE-Onboardings bereitstellt.

Wann wird der S/4HANA-Upgrade durchgeführt?

Beide Sequenzen sind möglich. Häufig: Tenant Copy zuerst (homogener Stand), dann In-Place-Upgrade in RISE. Die SAP-Projektmethodik gibt die Sequenz im Einzelfall vor.

Muss der Ziel-Tenant vor der Kopie leer sein?

Ja. Ein bestehender Tenant mit identischer SID muss gestoppt oder gelöscht werden, bevor CREATE DATABASE AS REPLICA ausgeführt wird.

Was passiert bei Netzwerkabbruch?

Der Mechanismus nimmt bei Wiederherstellung der Verbindung automatisch wieder auf. Status über M_DATABASE_REPLICA_STATISTICS beobachtbar.

Welche HANA-Versionen werden unterstützt?

Ab HANA 2.0. Parameterunterstützung kann je nach Revision abweichen — Vorabcheck der SPS-Dokumentation empfohlen.

Sind Plugins problematisch?
Installierte HANA-Plugins müssen auf Quell- und Zielsystem identisch sein. Die Prüfung über SELECT * FROM M_PLUGIN_MANIFESTS sollte vor dem Start erfolgen.

Wie lange dauert ein typischer System-Refresh?

Das hängt vom Datenbankvolumen und der Netzwerkleitung zwischen den Systemen ab. Die Einrichtung selbst dauert unter einer Stunde. Ein Refresh eines mittelgroßen HANA-Systems (500 GB–2 TB) benötigt typischerweise zwischen 2 und 8 Stunden reine Replikationszeit.

Fazit

SAP HANA Migration neu denken

Die HANA Tenant Copy macht SAP HANA Migrationen deutlich einfacher, ob als RISE-Migration, als Transition in eine neue Umgebung oder als klassische Systemkopie. Systeme lassen sich schnell, flexibel und ohne OS-Zugriff übertragen.

Insbesondere im Kontext von RISE with SAP und S/4HANA-Projekten ist das ein entscheidender Vorteil – für kürzere Projektlaufzeiten, weniger Komplexität und eine deutlich effizientere Systemlandschaft.