HANA System Replication for Migration

Why use HSR for migration?

🏗️ Raj checks the clock. “We have a six-hour maintenance window. DMO for our 2 TB database takes 8-12 hours. Classical backup and restore over ExpressRoute could also push past six hours. How do we fit this into our window?”

☁️ Mei draws two boxes on the whiteboard. “HANA System Replication. We set up a secondary HANA instance on Azure and let it replicate from your on-premises primary for days or weeks before the migration. When cutover day arrives, we just flip the roles. The actual downtime is minutes, not hours.”

HSR architecture: Primary and secondary

HANA System Replication uses a primary/secondary architecture:

• Primary — The active HANA instance serving the SAP application. All read/write operations go here.
• Secondary — The replica instance receiving redo logs from the primary. It can replay logs in real time or on demand.

For migration:

• Your on-premises HANA instance is the primary
• An Azure VM running HANA is the secondary
• After initial full data copy and continuous log shipping, the secondary is in sync
• At cutover, you execute a takeover — the secondary becomes the new primary

Question

In an HSR-based migration, what is the role of the Azure HANA instance?

Click or press Enter to reveal answer

Answer

The Azure HANA instance is the secondary (replica). It receives and replays redo logs from the on-premises primary. During cutover, a takeover operation promotes the Azure secondary to become the new primary. This architecture allows bulk data transfer to happen in the background over days or weeks, minimizing actual cutover downtime to minutes.

Click to flip back

Replication modes: Sync, syncmem, and async

HSR supports three replication modes. Each makes a different trade-off between data protection and performance.

HSR replication modes

Mode	How it works	Data loss risk	Performance impact	Best use case
SYNC (synchronous)	Primary waits for the secondary to write redo logs to disk before acknowledging the transaction to the application	Zero data loss — every committed transaction exists on both systems	Highest — every transaction has added latency for the secondary disk write	High availability within the same Azure region where network latency is sub-millisecond
SYNCMEM (synchronous in-memory)	Primary waits for the secondary to receive redo logs in memory (not written to disk) before acknowledging	Near-zero data loss — only in-flight logs in secondary memory could be lost if the secondary crashes	Medium — less latency than SYNC because no secondary disk write wait	Cross-region replication or migration scenarios where some latency tolerance exists
ASYNC (asynchronous)	Primary sends redo logs to the secondary but does not wait for acknowledgment before committing	Potential data loss — transactions committed on primary may not yet be replicated to secondary	Lowest — no additional latency on primary transactions	Long-distance replication (on-premises to Azure) where network latency is significant

Which mode for migration?

☁️ Mei explains the trade-off. “For on-premises to Azure migration, asynchronous mode is almost always the right choice. The network latency between your datacenter and Azure is too high for synchronous replication — it would cripple your production system performance. Async mode keeps your production running at full speed while replication happens in the background.”

🏗️ Raj looks concerned. “But async means we could lose data during cutover?”

☁️ Mei reassures him. “The risk window is tiny. During cutover, you stop the application on the primary, wait for the last redo logs to replicate (usually seconds), then perform the takeover. If the network is stable, you lose zero transactions. The data loss risk in async mode is only during an unplanned failure — not during a planned migration cutover.”

Question

Why is asynchronous (ASYNC) mode typically used for HSR-based migration from on-premises to Azure?

Click or press Enter to reveal answer

Answer

ASYNC is used because the network latency between on-premises and Azure is too high for synchronous modes. SYNC and SYNCMEM would add significant latency to every transaction on the production primary. With ASYNC, production performance is unaffected. During a planned cutover, you stop the application first and wait for final log shipping, so data loss risk is effectively zero for planned migrations.

Click to flip back

💡 Exam tip: Mode selection by scenario

When an exam question asks about HSR mode: if the primary and secondary are in the same Azure region, SYNC or SYNCMEM are appropriate. If they are cross-region or on-premises to Azure, ASYNC is the answer. The key factor is network latency — synchronous modes add latency to every transaction commit.

Memory preload on the secondary

HANA allows you to control how much data the secondary system preloads into memory. This is an important cost and performance decision.

Preload enabled (default for HA scenarios):

• The secondary loads table data into memory as redo logs are replayed
• Takeover is fast because data is already in memory — the secondary can serve queries immediately
• Requires the secondary VM to have the same memory as the primary
• Higher cost because you are paying for a fully loaded memory-optimized VM

Preload disabled (common for DR and migration scenarios):

• The secondary replays redo logs but does not load data into memory
• Takeover is slower because the secondary needs to load data from disk into memory on demand
• Allows a smaller secondary VM (less memory), reducing cost
• Acceptable for migration because after takeover, the system has time to warm up before peak load

🏗️ Raj calculates costs. “So for our migration secondary on Azure, we could use a smaller VM with preload disabled since we only need it to be a replica until cutover?”

☁️ Mei confirms. “Exactly. During the migration window, the secondary just needs to keep up with log replay. After takeover, you can resize the VM to production specifications. This saves money during the weeks of pre-migration replication.”

Question

What is the impact of disabling memory preload on an HSR secondary system?

Click or press Enter to reveal answer

Answer

With preload disabled, the secondary does not load table data into memory during log replay. This allows a smaller (cheaper) VM for the secondary. The trade-off is that takeover is slower because data must be loaded from disk into memory on demand after promotion. This is acceptable for migration and DR scenarios where immediate full-speed performance is not required.

Click to flip back

The HSR migration workflow

Here is the end-to-end workflow for migrating SAP HANA from on-premises to Azure using HSR:

Weeks before cutover:

1. Deploy the target Azure VM — Correct VM size, OS, HANA installation, storage configuration (ANF or managed disks for data volumes, Ultra Disk or Premium SSD for log volumes)
2. Establish network connectivity — ExpressRoute or VPN between on-premises and Azure. HSR needs low-latency, reliable connectivity for log shipping.
3. Register the Azure HANA as HSR secondary — Configure the secondary to replicate from the on-premises primary using ASYNC mode
4. Initial data sync — HSR automatically performs a full data copy from primary to secondary. For a 2 TB database, this could take hours to days depending on bandwidth.
5. Monitor replication — Use HANA Studio or HANA cockpit to verify the secondary is in sync. Monitor the replication lag (seconds behind primary).

Cutover day:

6. Stop the SAP application on the on-premises primary
7. Wait for replication to catch up — Monitor until the secondary has replayed all remaining redo logs (typically seconds to minutes)
8. Perform HSR takeover — Promote the Azure secondary to primary. The on-premises system is deregistered.
9. Reconfigure SAP — Update SAP profiles, connection strings, and host name resolution to point to the Azure VM
10. Start the SAP application on Azure and validate
11. Update DNS and network routing — Ensure users and integrations reach the Azure system

💡 Exam tip: HSR cutover sequence

The cutover sequence is: stop application → wait for log replay to complete → takeover (promote secondary) → reconfigure SAP → start application → validate. Never perform the takeover while the application is still writing to the primary — you need a clean stop to ensure all transactions are replicated.

Network requirements for HSR migration

HSR log shipping is sensitive to network quality. For a reliable migration:

• Bandwidth — Sufficient to handle the initial full copy plus ongoing log shipping without falling behind. For a busy system generating 100 GB/hour of redo logs, you need at least that bandwidth sustained.
• Latency — Lower is better but not critical for ASYNC mode. High latency increases replication lag but does not affect primary performance.
• Reliability — Network interruptions cause HSR to disconnect. Short interruptions trigger automatic reconnection and delta sync. Long interruptions may require a full resync.
• ExpressRoute recommended — Provides dedicated, reliable bandwidth between on-premises and Azure. VPN over internet is possible but less predictable.
• Port requirements — HSR uses a set of TCP ports based on the HANA instance number. These ports must be open in firewalls and NSGs.

Question

What are the key network requirements for HSR-based migration from on-premises to Azure?

Click or press Enter to reveal answer

Answer

1) Sufficient bandwidth for initial full copy and ongoing log shipping. 2) Low latency preferred but not critical for ASYNC mode. 3) Reliable connection — interruptions cause HSR disconnection. 4) ExpressRoute recommended over VPN for dedicated bandwidth. 5) HSR-specific TCP ports must be open in firewalls and NSGs (port range based on HANA instance number).

Click to flip back

Knowledge check

Knowledge Check

PrecisionSteel has a six-hour maintenance window and a 2 TB HANA database. Raj wants to minimize cutover downtime. Which migration approach should he use?

ADMO with SUM in a single six-hour windowBClassical backup and restore over ExpressRouteCHSR with ASYNC replication, pre-synced for weeks, with takeover during the windowDHeterogeneous system copy using SWPM export/import

Check Answer

Knowledge Check

Raj is setting up HSR replication from PrecisionSteel's on-premises HANA primary to an Azure secondary. Which replication mode is typically recommended?

ASYNC because it guarantees zero data lossBSYNCMEM because it balances protection and performanceCASYNC because network latency between on-premises and Azure is too high for synchronous modesDLOGREPLAY because it is the default for all HSR configurations

Check Answer

Knowledge Check

Raj wants to reduce the cost of the Azure HANA secondary VM during the weeks of pre-migration HSR replication. What setting allows a smaller secondary VM?

AEnable HSR compression to reduce log volumeBDisable memory preload on the secondary so data is not loaded into RAM during replicationCUse ASYNC mode instead of SYNC to reduce CPU requirementsDConfigure the secondary in standby mode with HANA stopped

Check Answer

Summary

HANA System Replication is the go-to technique for near-zero-downtime SAP migration to Azure. By pre-syncing a secondary HANA instance on Azure weeks before cutover, the actual downtime shrinks to minutes. ASYNC mode is standard for on-premises to Azure due to network latency. Memory preload settings let you optimize cost during the replication period. The cutover sequence — stop application, wait for log replay, takeover, reconfigure, start — is clean and predictable.

Next and finally, we cover post-migration validation and the special case of migrating from HANA Large Instances to Azure VMs.

🎬 Video coming soon