What BW/4HANA Is and Why Organizations Migrate to It
An introduction to BW/4HANA's purpose, simplified architecture, and the business drivers pushing organizations to move from classic BW to this HANA-native data warehouse.
Explanation
BW/4HANA is SAP's data warehousing product designed exclusively to run on SAP HANA. Unlike classic BW (7.x) which could run on any database and carried decades of layered architecture (PSA, multiple InfoCube types, InfoSets, MultiProviders, aggregates), BW/4HANA strips this down to a small set of simplified objects, because HANA's in-memory columnar engine removes the need for many performance workarounds that classic BW relied on. Why this matters: classic BW systems accumulated technical debt over years - redundant persistence layers, complex extraction chains, and aggregates built purely to compensate for slow disk-based databases. When HANA arrived, most of that complexity became unnecessary overhead. BW/4HANA formalizes this by only allowing a reduced object model: Advanced DataStore Objects (ADSOs) replace classic DataStore Objects and InfoCubes, Open ODS Views allow virtual access to HANA views or external tables without physical replication, CompositeProviders replace MultiProviders and InfoSets for combining data, and transformations plus Data Transfer Processes (DTPs) remain the core movement mechanisms but with fewer intermediate hops required. Architecturally, an ADSO can be configured with different types (standard for staging and reporting layers combined, write-optimized-like behavior via activation settings, or for direct reporting) which means one object type now serves purposes that used to require three separate classic objects. This reduces the number of moving parts, shortens process chains, and cuts data latency because fewer physical activation and transfer steps are needed between layers. Deployment context matters here. BW/4HANA as a standalone product runs on-premise or in a private cloud edition on SAP HANA, and requires HANA as the primary database - there is no option to run it on another database platform. This is different from classic BW, which could run on HANA (BW-on-HANA) as an option or on other databases like Sybase, Oracle, or SQL Server. In S/4HANA environments, embedded analytics using CDS views and the analytics engine within S/4HANA is a separate concept from BW/4HANA - S/4HANA embedded analytics reports directly against the operational data model using virtual data models, whereas BW/4HANA is typically deployed as a companion enterprise data warehouse when organizations need historical data, complex transformations, harmonization across multiple source systems, or long-term data retention beyond what the operational S/4HANA system is designed to hold. A beginner should understand that migrating to BW/4HANA is not simply an upgrade - it is a conversion project. SAP provides tools to analyze classic BW objects and convert compatible ones (like classic DSOs) into ADSOs, but objects like classic InfoCubes, InfoSets aggregates, and certain older extraction methods are not supported and must be redesigned. This is why migration projects typically start with an inventory and readiness check phase before any technical conversion begins. From a runtime perspective, data still flows from source systems (SAP ECC, S/4HANA, non-SAP systems, flat files) through extraction, staging in ADSOs, transformation logic, and then into reporting-layer ADSOs or CompositeProviders that queries are built against using BEx-like query design tools adapted for the new object model. The underlying HANA push-down for calculations remains a major theme: transformations and queries increasingly delegate computation to the HANA database engine rather than the ABAP application server, which is central to why performance improves after conversion, provided the redesign avoids simply replicating old patterns.
Real project scenario
A retail company running classic BW 7.5 on HANA for five years faces increasing maintenance overhead: numerous InfoCubes with overlapping data, unused aggregates, and long-running process chains. Leadership mandates a move to BW/4HANA to reduce total cost of ownership. The project starts with SAP's readiness check tooling to classify existing InfoProviders as convertible, requiring remodeling, or requiring decommissioning, followed by a phased conversion of finance and sales data marts before extending to less critical areas.
Common mistakes
• Assuming BW/4HANA migration is a technical upgrade only, without budgeting time for object redesign and business validation • Treating classic InfoCubes as directly convertible without checking that only certain DataStore Object types have supported conversion paths • Underestimating the effort to redesign InfoSets and MultiProviders into CompositeProviders, especially where custom ABAP routines were embedded • Ignoring the requirement that BW/4HANA runs only on SAP HANA, leading to unplanned infrastructure and licensing conversations late in the project • Confusing BW/4HANA with S/4HANA embedded analytics and assuming one replaces the other in all scenarios
Best practices
• Run SAP's readiness or transfer toolkit early to classify existing objects before committing to a migration timeline • Treat the migration as an opportunity to decommission unused InfoProviders and simplify data flows, not just a lift-and-shift • Validate that source system connections and extraction methods used in classic BW are still supported before planning conversion • Engage business stakeholders early since some remodeled reporting layers will change query behavior or navigation • Document which classic objects require full redesign versus straightforward conversion to set realistic project phases
Interview angle
Interviewers often ask candidates to explain the difference between classic BW, BW-on-HANA, and BW/4HANA, and to justify why an organization would choose to migrate. Strong answers reference the object model simplification (ADSO replacing multiple classic objects), the mandatory HANA dependency, and the fact that migration is a redesign exercise rather than a simple technical upgrade, along with awareness that not all classic objects have direct conversion paths.