Migrating a Heterogeneous SAP Landscape With a Tight Cutover Window
A retail customer is migrating an SAP landscape consisting of SAP Business Suite on AnyDB, a standalone SAP NetWeaver Java stack, and a 12 TB SAP Business Warehouse to Azure. The cutover window is a single weekend of 36 hours. The source systems run on physical hardware with 1 Gbps links to the internet, and the measured change rate on the BW system is 400 GB per day during load peaks. The customer plans to use Azure Migrate appliance-based replication for all systems and to test the cutover only in production. The BW system has a 900 GB table that the Basis team says can be reorganized offline to reduce size before migration.
1. Assess whether a single 36-hour cutover using Azure Migrate replication is realistic for this landscape, and identify the risks.
Read the worked answer
It is not realistic as described, and the risks are concentrated in the BW system.
First, the change rate. A 400 GB per day change rate on a 12 TB system means the final delta synchronization is large. Over a 1 Gbps link, theoretical throughput is about 125 MB/s, but real-world replication over the internet to Azure is typically far lower once latency and TCP windowing are accounted for. Even at an optimistic 80 MB/s, 400 GB of delta requires roughly 90 minutes of pure transfer with no contention, and the delta continues to grow while you transfer it. The cutover must include time to stop the source, transfer the final delta, and validate, and the final delta is the part that is hardest to predict.
Second, the 36-hour window must cover far more than data movement: application server configuration, SAP kernel and profile adjustments, transport of any pending changes, interface and batch reconnection, business validation, and rollback decision points. A single weekend leaves no margin.
Third, testing only in production is unacceptable for a landscape of this size. A rehearsal cutover against a scaled-down or full copy is the only way to validate timings and the rollback path.
Recommendation: use an offline seed with Azure Data Box or a physical shipment for the 12 TB BW system, then apply incremental deltas, and schedule at least one full rehearsal cutover before the production event.
2. The Basis team proposes reorganizing the 900 GB table offline to shrink the BW system before migration. Evaluate this and describe how it affects the migration plan.
Read the worked answer
Reorganizing the table can be worthwhile, but it must be evaluated as a change to the source system with its own risk, not as a free reduction in migration size.
Benefits: a smaller database reduces the seed size, shortens the final delta, and reduces storage cost in Azure. For a BW system, a large table is often a fact table or a change log, and a reorganization that removes fragmentation or archives old partitions can meaningfully reduce both size and the ongoing change rate, which is the more valuable effect.
Risks: an offline reorganization of a 900 GB table requires substantial downtime and log space on the source, and it changes the source system shortly before a migration, which introduces a new variable into a plan that already has little margin. If the reorganization is done close to cutover and something goes wrong, the migration is delayed with no fallback.
Recommended sequencing:
- Perform the reorganization well before the migration, with its own test and rollback plan, and measure the resulting size and change rate.
- Re-baseline the migration plan against the new numbers rather than the original 12 TB and 400 GB per day.
- If the reorganization cannot be completed with adequate lead time, do not attempt it as part of the migration; migrate the system as-is and optimize after cutover.
The decision should be driven by measured post-reorganization change rate, because that is what determines whether the cutover window is achievable.