Our team is planning a DMO conversion to S/4HANA 1809 for a 12TB database. Initial estimates show 72+ hours of downtime, which is beyond our business window. I’m looking for proven strategies to reduce this timeframe.
We’ve done basic SUM configuration, but I know there’s significant room for optimization in R3load parallelization and table splitting. The UPGANA.XML file from our test run shows several large tables (BSEG, CDPOS, DBTABLOG) dominating the migration time. We haven’t attempted manual table splitting yet.
What approaches have you found most effective? I’m particularly interested in iterative optimization techniques and benchmark testing methodologies that helped you identify the right parallelization settings.
Pre-Upgrade Checks Before Touching Parallelization
Before adjusting any R3load parameters, validate these or your optimization efforts will be misdirected:
SUM version: confirm you’re running the latest patch for your source release (verify in your version — DMO behavior changed significantly in SUM 2.0 SP-series)
Run SWPM prerequisite checks and clear all PREP_CHECK errors
Confirm OS-level I/O scheduler is set to deadline or noop (not cfq) on the DB host
Validate HANA target is sized with sufficient memory — undersized HANA will bottleneck regardless of R3load tuning; for 12TB source, expect significant data reduction post-migration but provision conservatively
Pull UPGANA.XML from your test run and sort by DURATION descending — your BSEG/CDPOS/DBTABLOG identification is exactly the right starting point
Check DBACOCKPIT on source for current index fragmentation; heavily fragmented tables inflate export times
Table splitting via MIGMON: For BSEG, define split criteria in the MIGRATIONMONITORjco.properties. BSEG splits well on BUKRS + GJAHR. CDPOS splits on OBJECTCLAS. Avoid splitting DBTABLOG by content — split by row range instead using R3load’s WHERE clause mechanism.
R3load parallelization: Edit RSLDR.PAR — set maxjobs to roughly 2× your physical CPU core count on the migration host (not the HANA host). Start conservative, then increment by 25% per test iteration. Watch for I/O saturation before CPU saturation on large tables.
Package size tuning: In MIGMON, set packageSize per-table. For BSEG at 12TB scale, test values between 50,000–200,000 rows. Smaller packages reduce restart overhead; larger packages reduce overhead per batch. Benchmark iteratively — there’s no universal value.
Parallel export/import overlap: Configure DMO to run import into HANA while export is still in progress (SUM “online” phases). Confirm your network bandwidth between export host and HANA target can sustain this without becoming the bottleneck.
HANA-side bulk load settings: Set import_num_threads in global.ini under [import_export] to match your HANA host vCPU count (verify in your version — parameter naming varies).
Iterative benchmarking methodology: Run timed sub-migrations of your top-5 tables in isolation. Record duration, I/O throughput (iostat), and CPU wait. Adjust one variable per iteration. Three benchmark passes per configuration change minimum before drawing conclusions.
Suppress unnecessary secondary indexes: Drop non-critical custom indexes pre-migration and rebuild post-cutover — this alone can reduce import time by 15–30% on large custom-index-heavy systems.
Rollback Procedure
Rollback from DMO is only clean before phase MAIN_NEWBAS/END — after this point, ABAP stack has been modified.
Stop SUM via ABORT in MIGMON UI
Execute SUM’s built-in shadow revert — this drops the shadow repository
Restore HANA target from pre-migration snapshot (do not attempt in-place rollback on HANA)
Validate source ECC system integrity via R3trans -d before bringing users back
Document the exact phase checkpoint from SUM/abap/log/UPGANA.XML — critical for root-cause analysis before retry
For a 12TB system targeting sub-72-hour downtime, table splitting on BSEG alone typically yields the largest single improvement. Prioritize that before touching global parallelization settings.
This draft is based on general SAP S/4HANA knowledge. It has not been verified against your specific version and environment. Practitioners: verify the steps and share your experience below.
UPGANA.XML analysis is your starting point. Look for tables with TABTIME values over 2 hours - those are your splitting candidates. We reduced our 80-hour window to 38 hours primarily through aggressive table splitting. BSEG alone took 14 hours initially. After splitting into 8 chunks, it completed in 2.5 hours. The key is finding the right split criteria - usually fiscal year or company code work well for financial tables.
R3load parallel tuning requires careful benchmarking. Don’t just max out parallelization - we found diminishing returns above 40 parallel processes for our hardware setup. Run multiple test migrations with different configurations: start with 20 processes, then 30, 40, 50. Monitor CPU, I/O wait, and memory saturation. Our sweet spot was 35 parallel R3load processes with 3 table splitting workers. Going higher actually increased time due to resource contention.
Manual table splitting is tedious but worth it for large tables. Create SPLITTER.XML file defining split criteria for your top 20 tables by size. For BSEG, we used fiscal year ranges. For CDPOS, document change number ranges. The trick is ensuring even distribution - analyze your data first. One split with 80% of records defeats the purpose. Aim for splits within 20% size variance.
We ran four test migrations. First was baseline with default settings (72 hours). Second with basic table splitting on top 10 tables (51 hours). Third added R3load tuning to 40 parallel processes (42 hours). Fourth refined splits and reduced to 35 parallel after seeing resource contention (38 hours). Each iteration taught us something. Don’t skip the testing phase - production surprises are costly.
Don’t overlook database-side optimization. Ensure your target database has proper sizing - undersized temp tablespaces killed our first attempt. Also, disable database logging during migration if your DR strategy allows. We gained 15% time reduction just from that. Pre-create indexes on the target system rather than letting R3load create them - parallel index creation is much faster than sequential.
Let me synthesize the most effective strategies we’ve collectively learned:
1. UPGANA.XML Analysis - Your Roadmap
After your first test run, analyze UPGANA.XML systematically. Focus on tables where TABTIME exceeds 5% of total runtime. Export the analysis to spreadsheet, sort by duration, and identify your top 30 tables. These represent 80% of your optimization opportunity. Don’t waste time optimizing small tables.
2. Manual Table Splitting - Strategic Approach
For your top 20 tables, implement manual splits:
Financial tables (BSEG, BKPF): Split by fiscal year and company code
Change documents (CDPOS, CDHDR): Split by OBJECTCLAS and date ranges
Application logs (DBTABLOG): Split by timestamp ranges
Create SPLITTER.XML with 6-10 splits per large table. Validate split distribution with SQL queries first - uneven splits waste parallelization. Target: each split under 2 hours processing time.
Monitor during each test: CPU utilization should be 70-85%, I/O wait under 20%, memory not swapping. If CPU hits 95%+ or I/O wait exceeds 30%, you’ve over-parallelized. Our optimal was typically 30-40 processes for systems with 32+ cores.
4. Benchmark Testing Methodology
Run abbreviated tests to save time:
Use database subset (30-40% of production) for initial tuning
Test full migration twice: once with optimized settings, once for validation
Don’t skip test migrations - each iteration reveals critical insights
More parallelization isn’t always better - find your hardware sweet spot
Manual table splitting is labor-intensive but yields highest ROI
UPGANA.XML is your best diagnostic tool - master its analysis
Document everything for future migrations and troubleshooting
The iterative approach is essential. Each test run costs time but saves multiples in production. Budget for 4-5 test migrations minimum before your production cutover.