Copy SAP Systems Easily Instead of Complex Migrations – To RISE and S/4HANA Without Operating System Access

How can SAP systems be moved quickly into a new environment without operating system (OS) access, without complex coordination between teams, and without lengthy project timelines? In SAP RISE migrations, S/4HANA transformations, or system refreshes, traditional approaches quickly reach their limits.

The solution: the SAP HANA Tenant Copy mechanism. It enables the database layer of an SAP system to be copied efficiently, purely via SQL and without OS access on either side. The application layer is then reconnected to the copied tenant in the usual post-copy steps.

What is SAP HANA Tenant Copy?

The HANA Tenant Copy mechanism is technically based on log shipping, similar to SAP HANA System Replication, but significantly easier to use. 
 
Unlike traditional migration methods, Tenant Copy works entirely through SQL. 
Benefits: 
• No operating system access required 
• No identical system IDs (SIDs) required 
• No identical instance numbers required 
• No additional configuration effort such as HDBUSERSTORE entries 
 
This makes Tenant Copy particularly suitable for modern cloud and RISE scenarios. 

When is Tenant Copy the right choice?

SAP RISE Migration with S/4HANA Upgrade

The most prominent use case is migration to SAP RISE (RISE with SAP, S/4HANA Cloud Private Edition). In the RISE model, SAP manages the target infrastructure and customers do not receive OS access to the target HANA host. Traditional migration methods relying on OS-level backups or file transfers are therefore not possible.  

Tenant Copy fits perfectly because SAP provides SQL credentials for the target system and the entire process is performed without OS coordination.

Good to know: During a RISE migration, the S/4HANA upgrade can be performed either before the tenant copy or after finalization. SAP project methodology determines the sequence.

Additional Scenarios

Homogeneous database migration between data centers, hosts, or landscapes without rebuilding the target.

System refreshes for QS- or test systems from production, fully SQL-based and suitable for automation.

New Systems from existing instances – Rapid provisioning of sandbox systems or tenant splits from existing systems.

Good to know: Source and target SIDs do not need to be identical. The target database can run on a different instance number and host.

Tenant Copy vs. System Replication

Both mechanisms use log shipping, but differ significantly in their requirements:

Prerequisites

Network connectivity: The target system must be able to access the SQL port of the SystemDB. Default: 3<instance number>01 or 3<instance number>13. In restrictive networks, firewall exceptions must be requested.

Database access: SYSTEM user (or technical user with equivalent rights) on both sides. Operating system accounts are not required.

Plugin synchronization (recommended): Installed HANA plugins must match on both systems. Verify via M_PLUGIN_MANIFESTS.

Process Overview

The parameters are set in the SystemDB of both systems using `ALTER SYSTEM ALTER CONFIGURATION`. SSL parameters should only be disabled in exceptional cases—production environments keep SSL enabled.

Source system — global.ini (SYSTEM) 

Source system — indexserver.ini (SYSTEM)

The target system receives the same global.ini parameters (excluding indexserver.ini entries). 

Phase 2 — Start Replication

• Stop the target tenant (ALTER SYSTEM STOP DATABASE) — if the SID is identical:deletethe tenant (DROP DATABASE) 
• Create a credential (CREATE CREDENTIAL FOR COMPONENT ‘DATABASE_REPLICATION’) with the hostname, port, and SYSTEM password of the source system
• Start the copy process (CREATE DATABASE … AS REPLICA OF … AT ‘…’)
• Monitor progress via SYS_DATABASES.M_DATABASE_REPLICA_STATISTICS — wait until REPLICATION_STATUS = ACTIVE

Phase 3 — Takeover and cleanup

Shut down the application on the source system, then:

• Finalizereplication (ALTER DATABASE … FINALIZE REPLICA) 
• Remove credentials (DROPCREDENTIAL …)
• Reset parameters to their original values
• Adjust the port if necessary (ALTER DATABASE … ALTER ‘indexserver’)

Benefits at a glance

1.  NoOS accessrequired — The entire process runs via SQL. No need for operating system coordination between teams. 

2.  FlexibleSID and instance assignment —The source and target SIDs do not have to be identical. Independent of existing system landscapes. 

3.  Shortproject durations —Setup typically takes less than an hour. Copy time depends on database volume, not on manual processes. 

4.  Reproducibility—Fully scriptable, for example using Ansible playbooks. Recurring system refreshes can thus be automated.

Frequently asked questions

Is Tenant Copy suitable for SAP RISE migrations? 

Yes. In the RISE model, SAP manages the target infrastructure; customers do not have OS access. Tenant Copy requires only SQL access, which SAP provides for RISE onboarding. 

When is the S/4HANA upgrade performed? 

Both sequences are possible. Commonly: Tenant Copy first (homogeneous state), then an in-place upgrade in RISE. The SAP project methodology specifies the sequence on a case-by-case basis. 

Does the target tenant have to be empty before the copy is made? 

Yes. An existing tenant with an identical SID must be stopped or deleted before executing `CREATE DATABASE AS REPLICA`.

What happens if the network connection is lost? 

The process automatically resumes when the connection is restored. Status can be monitored via `M_DATABASE_REPLICA_STATISTICS`. 

Which HANA versions are supported? 

Starting with HANA 2.0. Parameter support may vary depending on the revision—it is recommended to check the SPS documentation in advance. 

Are plugins an issue? 

Installed HANA plugins must be identical on both the source and target systems. A check using SELECT * FROM M_PLUGIN_MANIFESTS should be performed before starting. 

How long does a typical system refresh take? 

That depends on the database volume and the network connection between the systems. The setup itself takes less than an hour. A refresh of a medium-sized HANA system (500 GB–2 TB) typically requires between 2 and 8 hours of pure replication time.

Conclusion