Transitioning from BW on HANA to BW/4HANA: Strategic Technical Guide
The transition from BW on HANA to BW/4HANA represents one of the most significant architectural shifts in SAP's data warehousing history. It's not just an upgrade — it's a completeplatform transformation that requires careful planning and execution.
This comprehensive guide will help you navigate the technical complexities of migration, choose the right conversion approach, and understand which legacy objects must be retired or replaced.
Understanding the Paradigm Shift
BW on HANA vs BW/4HANA
| Aspect | BW on HANA | BW/4HANA |
|---|---|---|
| Database | HANA (optional) | HANA only (mandatory) |
| Data Model | InfoCubes, MultiProviders, DSOs | ADSOs, CompositeProviders |
| Modeling | Classic BW modeling | Simplified, HANA-optimized |
| Performance | Fast (in-memory) | Faster (optimized architecture) |
| Code Pushdown | Limited | Native, extensive |
| Footprint | Larger | 30-50% smaller |
Key Architectural Changes
- Unified Data Storage – ADSOs replace DSOs, InfoCubes, and Write-Optimized DSOs
- No Aggregates – HANA handles aggregation in real-time
- Simplified Modeling – Fewer object types, cleaner architecture
- Native HANA Integration – CDS views, Calculation views
- Open ODS Views – Expose external data without loading
Conversion Approaches
Approach 1: In-Place Conversion (Shell Conversion)
What It Is
Convert existing BW on HANA system to BW/4HANA on the same hardware and database. Metadata is converted, but data remains intact.
Process Overview
1. Pre-Conversion Assessment - Run DMO Conversion Check (RDMO_CHECK) - Identify incompatible objects - Check database size and hardware requirements 2. Preparation Phase - Update to BW 7.5 SP12+ (minimum) - Clean up unused objects - Archive historical data - Document customizations 3. Conversion Execution - Use SUM/DMO tool - System converted in-place - Downtime: 8-48 hours (depending on size) 4. Post-Conversion Activities - Migrate InfoCubes to ADSOs - Convert MultiProviders to CompositeProviders - Test all reports and processes - Performance optimization
Advantages
- ✅ Faster implementation (weeks vs months)
- ✅ Lower cost (no new hardware initially)
- ✅ All data preserved
- ✅ Minimal data migration effort
Disadvantages
- ❌ Carries over technical debt
- ❌ Extended downtime during conversion
- ❌ No immediate architecture cleanup
- ❌ Risk of conversion issues
Best For
- Organizations with tight timelines
- Limited budget for parallel systems
- Well-maintained BW landscapes
- Need to preserve all historical data
Approach 2: Remote Conversion (New Install)
What It Is
Install new BW/4HANA system and selectively migrate objects and data from old system.
Process Overview
1. Planning Phase - Identify objects to migrate - Design new architecture - Plan data migration strategy - Set up new hardware/cloud infrastructure 2. Installation - Install fresh BW/4HANA system - Configure system landscape - Set up connections to source systems 3. Selective Migration - Transport metadata objects - Redesign with new object types (ADSOs, CompositeProviders) - Load historical data selectively - Build new data flows 4. Parallel Run & Cutover - Run both systems in parallel - Validate data consistency - Gradual user migration - Final cutover
Advantages
- ✅ Clean slate – no technical debt
- ✅ Optimize architecture from scratch
- ✅ No downtime during migration
- ✅ Opportunity to retire obsolete objects
- ✅ Better performance with redesigned flows
Disadvantages
- ❌ Longer implementation (months)
- ❌ Higher cost (new hardware)
- ❌ More complex data migration
- ❌ Requires significant testing
Best For
- Organizations with significant technical debt
- Need for architectural overhaul
- Can afford parallel systems
- Want to modernize completely
Object Retirement and Migration
Deprecated Objects
| Legacy Object | Status | BW/4HANA Replacement |
|---|---|---|
| InfoCube | Retired | ADSO (Advanced DataStore Object) |
| DSO (DataStore Object) | Retired | ADSO |
| Write-Optimized DSO | Retired | ADSO (Write-optimized) |
| MultiProvider | Retired | CompositeProvider |
| InfoSet | Retired | CompositeProvider |
| PSA (Persistent Staging Area) | Retired | ADSO or direct loading |
| Aggregates | Retired | Not needed (HANA handles) |
| InfoPackage | Retired | Data Transfer Process (DTP) |
Migration Example: InfoCube to ADSO
-- Legacy InfoCube structure
InfoCube: Z_SALES_CUBE
Dimensions: Customer, Product, Time, Unit
Key Figures: Revenue, Quantity, Discount
Partitioning: By fiscal year
Aggregates: Multiple (year, quarter, month)
-- Migrated ADSO structure
ADSO: Z_SALES_ADSO
Type: Standard ADSO
Key Fields: Customer, Product, CalDay, Unit
Data Fields: Revenue, Quantity, Discount
Settings:
- No aggregates needed (HANA optimization)
- Partitioning maintained
- Change log optional
- Reporting enabledMigration Steps
1. Analyze InfoCube - Document structure - Identify transformations - Check data volume 2. Create ADSO - Match key structure - Map characteristics and key figures - Configure settings (reporting, change log) 3. Create Data Flow - Source: Existing DataSource or DSO - Transformation: Port logic from InfoCube updates - DTP: Load data into ADSO 4. Historical Data Migration - Export data from InfoCube - Load into ADSO using DTP - Validate data consistency 5. Update Queries - Redirect BEx queries to ADSO - Test all reports - Optimize query performance
Technical Preparation Checklist
Pre-Conversion Tasks
☐ Run RDMO_CHECK transaction ☐ Execute SAP Note checks (Note 2384470) ☐ Check BW statistics (RSRTREPT) ☐ Identify custom code dependencies ☐ Document all interfaces ☐ Review process chains ☐ Archive unnecessary data ☐ Clean up unused objects (RSA1 → Cleanup) ☐ Update system to minimum release ☐ Backup entire system ☐ Test restoration procedures ☐ Train team on BW/4HANA concepts
System Requirements
| Component | Minimum Requirement | Recommended |
|---|---|---|
| Source System | BW 7.5 SP12 | BW 7.5 SP18+ |
| Database | HANA 2.0 SPS03 | HANA 2.0 SPS06+ |
| RAM | 512 GB | 1 TB+ |
| Storage | Depends on data | SSD with 3x data size |
| Downtime Window | 12-24 hours | Plan for 48 hours |
Common Migration Challenges
Challenge 1: Performance Degradation
Cause: Direct migration without optimization
Solution:
- Remove unnecessary fields from ADSOs - Simplify transformation logic - Use HANA-optimized routines - Leverage SAP HANA calculation views - Remove redundant aggregation layers
Challenge 2: Query Compatibility
Cause: BEx queries designed for old architecture
Solution:
- Redirect queries to new ADSOs - Rebuild complex queries from scratch - Use CompositeProviders for multi-source queries - Leverage HANA Live views where applicable - Test thoroughly with real user scenarios
Challenge 3: Custom ABAP Code
Cause: Hard-coded references to deprecated objects
Solution:
- Scan code for deprecated function modules - Update to use new APIs (RSDRI_*) - Replace PSA logic with ADSO read operations - Use code inspector (transaction SCI) - Document all code changes
Post-Conversion Optimization
Data Model Simplification
Before (BW on HANA): DataSource → PSA → DSO → InfoCube → MultiProvider → Query After (BW/4HANA - Optimized): DataSource → ADSO (with reporting enabled) → Query Result: 60% fewer objects, faster loads, simpler maintenance
Performance Tuning
- Enable HANA-optimized DTP execution
- Use parallel processing for large loads
- Implement Smart Data Integration (SDI)
- Leverage Open ODS Views for external data
- Use CompositeProviders with joins instead of unions
Timeline Estimates
In-Place Conversion
Small System (< 500 GB): Preparation: 4-6 weeks Conversion: 1-2 days Testing: 2-3 weeks Total: 7-11 weeks Medium System (500 GB - 2 TB): Preparation: 8-12 weeks Conversion: 2-4 days Testing: 4-6 weeks Total: 14-22 weeks Large System (> 2 TB): Preparation: 12-16 weeks Conversion: 3-7 days Testing: 6-10 weeks Total: 20-33 weeks
Remote Conversion
Small System: Total: 12-20 weeks Medium System: Total: 24-36 weeks Large System: Total: 36-52 weeks
Decision Matrix
| Factor | In-Place | Remote |
|---|---|---|
| Timeline Pressure | ✅ Best | ❌ Slower |
| Budget Constraint | ✅ Lower cost | ❌ Higher cost |
| Technical Debt | ❌ Carries over | ✅ Clean slate |
| Architecture Quality | ⚠️ Same as before | ✅ Optimized |
| Risk Level | ⚠️ Medium-High | ⚠️ Medium |
| Downtime Tolerance | ❌ Extended | ✅ Minimal |
Best Practices
✅ DO
- Start with thorough system assessment
- Clean up before conversion
- Train team on BW/4HANA concepts
- Test extensively in sandbox first
- Document all customizations
- Plan for rollback scenarios
- Engage SAP support early
❌ AVOID
- Converting without cleanup
- Underestimating testing time
- Ignoring deprecated object warnings
- Skipping performance benchmarks
- Not having rollback plan
Conclusion
The BW to BW/4HANA transition is a strategic investment in your data warehouse future. Whether you choose in-place or remote conversion depends on your specific circumstances, but both paths lead to a more efficient, simplified, and performant platform.
Key takeaways:
- In-place is faster but preserves technical debt
- Remote is slower but delivers clean architecture
- Thorough preparation is critical for success
- Budget 20-40% more time than estimated
- BW/4HANA delivers significant long-term benefits
The migration to BW/4HANA isn't just about technology — it's about positioning your data warehouse for the next decade.
