Skip to main content

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

AspectBW on HANABW/4HANA
DatabaseHANA (optional)HANA only (mandatory)
Data ModelInfoCubes, MultiProviders, DSOsADSOs, CompositeProviders
ModelingClassic BW modelingSimplified, HANA-optimized
PerformanceFast (in-memory)Faster (optimized architecture)
Code PushdownLimitedNative, extensive
FootprintLarger30-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 ObjectStatusBW/4HANA Replacement
InfoCubeRetiredADSO (Advanced DataStore Object)
DSO (DataStore Object)RetiredADSO
Write-Optimized DSORetiredADSO (Write-optimized)
MultiProviderRetiredCompositeProvider
InfoSetRetiredCompositeProvider
PSA (Persistent Staging Area)RetiredADSO or direct loading
AggregatesRetiredNot needed (HANA handles)
InfoPackageRetiredData 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 enabled

Migration 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

ComponentMinimum RequirementRecommended
Source SystemBW 7.5 SP12BW 7.5 SP18+
DatabaseHANA 2.0 SPS03HANA 2.0 SPS06+
RAM512 GB1 TB+
StorageDepends on dataSSD with 3x data size
Downtime Window12-24 hoursPlan 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

FactorIn-PlaceRemote
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.

About the Author: Yogesh Pandey is a passionate developer and consultant specializing in SAP technologies and full-stack development.