Advanced BW/4HANA: Architecture, Integration and Production Design (Part 7)

At senior and architect level, BW/4HANA should be understood as an end-to-end design problem rather than a list of isolated features.

Core design map
Why BW/4HANA Exists and How It Differs from Classic BW: An introduction to BW/4HANA's purpose, its simplified architecture compared to classic BW, and the core objects consultants encounter on day one.

Modeling with ADSOs, CompositeProviders, and Open ODS Views in BW/4HANA: A practical look at how to design a BW/4HANA data model using ADSOs for staging and storage, CompositeProviders for reporting-time combination, and Open ODS Views for virtual access, including transformation and DTP considerations.

Planning a BW/4HANA Conversion: In-Place vs Remote Conversion and Object Simplification: Understand the two primary conversion approaches to BW/4HANA, how classic BW objects map to simplified BW/4HANA objects, and the practical steps and risks involved in planning a conversion project.

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.

Modeling with ADSOs, Open ODS Views and CompositeProviders in BW/4HANA: A practical look at how to design data models in BW/4HANA using Advanced DataStore Objects, Open ODS Views, and CompositeProviders, including layer design and conversion considerations from classic BW.

BW/4HANA Transfer Toolset: Conversion Paths and Object Readiness: How the BW4HANA Transfer Toolset (also called BW4HANA Starter/Transfer Cockpit in SAP guidance) assesses, converts, and migrates classic BW objects to BW/4HANA-compatible equivalents, and what a consultant must plan before running conversion.

Architecture and production criteria

• Always run a formal readiness/pre-check analysis before committing to a conversion approach or timeline.
• Always run the SAP-provided pre-check/readiness analysis before scoping a BW/4HANA migration project
• Build a prioritized conversion backlog based on business criticality and object complexity
• Clarify early in a project whether the target is standalone BW/4HANA, embedded BW in S/4HANA, or a hybrid, since this changes scope and tooling.
• Configure ADSO settings deliberately based on the object's role (staging vs corporate memory vs reporting), not by default.
• Confirm with the client which reporting tools (BEx, embedded analytics, third-party BI) will consume BW/4HANA data, since this affects provider design choices.
• Document object-by-object mapping decisions (which InfoCube becomes which ADSO, which MultiProvider becomes which CompositeProvider) for traceability and testing.
• Document which classic objects require full redesign versus straightforward conversion to set realistic project phases
• Engage business stakeholders early since some remodeled reporting layers will change query behavior or navigation
• Evaluate opportunities to push transformation logic to HANA-native routines during conversion rather than preserving inefficient legacy ABAP
• Learn the ADSO type options (standard, write-optimized, etc. conceptually) before assuming any classic object maps one-to-one.
• Maintain a mapping document from legacy objects to new BW/4HANA objects for audit and support handover purposes
• Map every classic InfoSet join type and MultiProvider selection rule explicitly before building the corresponding CompositeProvider
• Periodically review the data flow for unnecessary layers as the model evolves, since scope creep can reintroduce classic BW-style complexity.
• Plan a hypercare period post-cutover to monitor load performance and query behavior on converted objects
• Plan and test rollback procedures (backup/snapshot points) before starting an in-place conversion.
• Prefer formula and rule-type transformation logic over ABAP routines when performance-sensitive HANA pushdown is desired.
• Prefer HANA-optimized transformation logic (AMDP) over ABAP routines for high-volume or computation-heavy transformations
• Re-test all BEx queries against converted objects with representative data volumes, not just sample records
• Reserve Open ODS Views for exploration or lightweight virtual access, not as a substitute for governed, historized staging.
• Run SAP's readiness or transfer toolkit early to classify existing objects before committing to a migration timeline
• Test process chains and DTPs end-to-end in a non-production system after each batch of conversions
• Treat security role and authorization object review as a first-class migration task, not an afterthought, since object types and technical names change.
• Treat the migration as an opportunity to decommission unused InfoProviders and simplify data flows, not just a lift-and-shift
• Use CompositeProviders as the primary reporting-facing object, keeping ADSOs as clean storage layers underneath.
• Use Open ODS Views selectively for genuinely volatile or low-latency-required source data, not as a default replacement for physical staging
• Use the conversion project as an opportunity to decommission unused InfoProviders, process chains, and transformations rather than carrying forward technical debt.
• Use the conversion/migration planning phase to also rationalize redundant legacy layers rather than mechanically converting everything as-is.
• Validate every converted object against pre-conversion baselines (record counts, key figure totals) before retiring the source object
• Validate report output reconciliation between old and new objects before cutover, especially for finance-critical reports.
• Validate that source system connections and extraction methods used in classic BW are still supported before planning conversion

Failure analysis and operational risk

• Assuming ADSO activation settings from a converted classic DSO are automatically optimal rather than reviewing them against actual reporting requirements
• Assuming all classic BW objects convert automatically without checking the readiness/conversion category from the pre-check analysis
• Assuming all classic objects convert automatically without remediation, then discovering blocking issues mid-project.
• Assuming BW/4HANA is simply classic BW installed on a faster database, without recognizing the object model is fundamentally reduced.
• Assuming BW/4HANA migration is a technical upgrade only, without budgeting time for object redesign and business validation
• Building CompositeProviders with unnecessary joins across large ADSOs without checking the performance impact on query runtime.
• Choosing remote conversion for cost/time reasons without budgeting the much larger rebuild effort for transformations and security roles.
• Confusing BW/4HANA with S/4HANA embedded analytics and assuming one replaces the other in all scenarios
• Confusing standalone BW/4HANA with embedded BW capabilities inside S/4HANA and assuming feature parity between them.
• Converting InfoProviders without first validating downstream query and process chain dependencies
• Creating excessive ADSO layers 'just in case', recreating the redundancy problem BW/4HANA modeling is meant to avoid.
• Decommissioning classic objects before completing side-by-side validation of record counts and key figures
• Defaulting to inner joins in CompositeProviders without validating against the original InfoSet or MultiProvider logic
• Failing to plan a clear rollback point (backup/snapshot) before starting an in-place conversion.
• Ignoring ABAP routines and custom code that may not perform well or may not be supported as-is on BW/4HANA
• Ignoring that process chains and transformations, while conceptually familiar, may require rule adjustments when targets become ADSOs.
• Ignoring the requirement that BW/4HANA runs only on SAP HANA, leading to unplanned infrastructure and licensing conversations late in the project
• Ignoring unused or deprecated objects, dragging technical debt into the new BW/4HANA landscape instead of decommissioning it.
• Misconfiguring ADSO table settings (e.g., omitting the change log) and then discovering delta extraction to downstream layers is not possible.
• Not distinguishing between in-place conversion and rebuild-and-reload, leading to unnecessary downtime or lost history
• Not revalidating navigational attributes and hierarchies after converting classic InfoProviders to ADSOs
• Not running a proper readiness/pre-check analysis early enough to influence project timeline and budget.
• Overusing Open ODS Views for high-volume, frequently-queried data without considering the performance impact of repeated virtual access versus physical staging
• Recreating ABAP routine-heavy transformations unchanged instead of evaluating AMDP-based alternatives for performance-critical loads
• Relying on Open ODS Views for scenarios that actually require historized, auditable staged data.
• Treating classic InfoCubes as directly convertible without checking that only certain DataStore Object types have supported conversion paths
• Trying to create classic InfoCubes or classic DSOs directly in a BW/4HANA system, which is not supported; only ADSO-based equivalents exist.
• Underestimating the effort to redesign InfoSets and MultiProviders into CompositeProviders, especially where custom ABAP routines were embedded
• Underestimating the effort to redesign MultiProviders and InfoSets into CompositeProviders and Open ODS Views
• Underestimating the effort to validate InfoSet-to-CompositeProvider replacements, especially where join semantics differ subtly from InfoSet logic.
• Underestimating the redesign effort by assuming a like-for-like object conversion is always possible without any remodeling.
• Using ABAP routines for simple field mappings that could be formulas, losing HANA pushdown performance benefits.

A strong production design connects functional or analytical semantics to integration boundaries, security, performance, transport/change control, observability, recovery and ownership. Trade-offs should be justified with evidence such as volume, latency, data quality, user behavior, operational SLA and downstream dependencies. Avoid treating a technically successful configuration or interface as complete until the business result is reconciled end to end.

A retail company running classic BW-on-HANA for ten years has accumulated dozens of InfoCubes and classic DSOs feeding overlapping MultiProviders for sales reporting. Management mandates a BW/4HANA conversion project. In the kickoff workshop, the lead consultant explains to the client's reporting team that InfoCubes will become ADSOs configured for reporting, MultiProviders will become CompositeProviders, and that some previously redundant layers (created historically to work around InfoCube limitations) can likely be eliminated because ADSOs handle both transactional and master-data-heavy scenarios more flexibly, reducing the overall object count during the redesign phase.

A manufacturing client needs a BW/4HANA model to report on production orders sourced from an S/4HANA system. The team designs an acquisition ADSO to stage raw order data with a change log for auditability, a harmonization ADSO to apply plant-specific business rules and conform material master attributes, and a reporting-layer ADSO exposed through a CompositeProvider that joins it with a separate cost-center master-data ADSO. During UAT, users report slow dashboard response; the consultant traces the issue to a transformation routine on the harmonization layer written as ABAP logic that could have been expressed as a formula, preventing HANA pushdown, and reworks it to restore expected performance.

A retail customer running classic BW 7.3 on ECC-based Oracle database needed to modernize before extended maintenance ended. The team performed a technical upgrade first to bring the system onto BW-on-HANA at a release compatible with BW/4HANA, then executed an in-place conversion. During the readiness check, roughly 15% of InfoCubes were flagged because they still used update rules referencing obsolete routines; these were redesigned as transformations before conversion could proceed. Two InfoSets used for ad hoc finance reporting had no direct equivalent and were rebuilt as CompositeProviders with join logic, which required re-validating report totals with the finance team before go-live.

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.

During a migration project, a classic InfoSet joining a sales DSO with a customer master DSO is converted into a CompositeProvider. The original InfoSet used a left outer join to always show sales records even without matching customer master data. The migration team initially recreates it as an inner join by default, causing sales figures in test reports to drop compared to the legacy system. Root cause analysis traces the discrepancy to the join type mismatch, and the fix involves explicitly configuring the CompositeProvider join as left outer and re-validating totals against the legacy BEx query output.

A retail company running BW 7.5 powered by HANA planned a conversion to BW/4HANA ahead of maintenance end-of-support for their classic BW toolset. The project team ran the transfer toolset's pre-check and discovered 40% of InfoProviders were classic DSOs elig

• Assuming ADSO activation settings from a converted classic DSO are automatically optimal rather than reviewing them against actual reporting requirements
• Assuming all classic BW objects convert automatically without checking the readiness/conversion category from the pre-check analysis
• Assuming all classic objects convert automatically without remediation, then discovering blocking issues mid-project.
• Assuming BW/4HANA is simply classic BW installed on a faster database, without recognizing the object model is fundamentally reduced.
• Assuming BW/4HANA migration is a technical upgrade only, without budgeting time for object redesign and business validation
• Building CompositeProviders with unnecessary joins across large ADSOs without checking the performance impact on query runtime.
• Choosing remote conversion for cost/time reasons without budgeting the much larger rebuild effort for transformations and security roles.
• Confusing BW/4HANA with S/4HANA embedded analytics and assuming one replaces the other in all scenarios
• Confusing standalone BW/4HANA with embedded BW capabilities inside S/4HANA and assuming feature parity between them.
• Converting InfoProviders without first validating downstream query and process chain dependencies
• Creating excessive ADSO layers 'just in case', recreating the redundancy problem BW/4HANA modeling is meant to avoid.
• Decommissioning classic objects before completing side-by-side validation of record counts and key figures
• Defaulting to inner joins in CompositeProviders without validating against the original InfoSet or MultiProvider logic
• Failing to plan a clear rollback point (backup/snapshot) before starting an in-place conversion.
• Ignoring ABAP routines and custom code that may not perform well or may not be supported as-is on BW/4HANA
• Ignoring that process chains and transformations, while conceptually familiar, may require rule adjustments when targets become ADSOs.
• Ignoring the requirement that BW/4HANA runs only on SAP HANA, leading to unplanned infrastructure and licensing conversations late in the project
• Ignoring unused or deprecated objects, dragging technical debt into the new BW/4HANA landscape instead of decommissioning it.
• Misconfiguring ADSO table settings (e.g., omitting the change log) and then discovering delta extraction to downstream layers is not possible.
• Not distinguishing between in-place conversion and rebuild-and-reload, leading to unnecessary downtime or lost history
• Not revalidating navigational attributes and hierarchies after converting classic InfoProviders to ADSOs
• Not running a proper readiness/pre-check analysis early enough to influence project timeline and budget.
• Overusing Open ODS Views for high-volume, frequently-queried data without considering the performance impact of repeated virtual access versus physical staging
• Recreating ABAP routine-heavy transformations unchanged instead of evaluating AMDP-based alternatives for performance-critical loads
• Relying on Open ODS Views for scenarios that actually require historized, auditable staged data.
• Treating classic InfoCubes as directly convertible without checking that only certain DataStore Object types have supported conversion paths
• Trying to create classic InfoCubes or classic DSOs directly in a BW/4HANA system, which is not supported; only ADSO-based equivalents exist.
• Underestimating the effort to redesign InfoSets and MultiProviders into CompositeProviders, especially where custom ABAP routines were embedded
• Underestimating the effort to redesign MultiProviders and InfoSets into CompositeProviders and Open ODS Views
• Underestimating the effort to validate InfoSet-to-CompositeProvider replacements, especially where join semantics differ subtly from InfoSet logic.
• Underestimating the redesign effort by assuming a like-for-like object conversion is always possible without any remodeling.
• Using ABAP routines for simple field mappings that could be formulas, losing HANA pushdown performance benefits.

• Always run a formal readiness/pre-check analysis before committing to a conversion approach or timeline.
• Always run the SAP-provided pre-check/readiness analysis before scoping a BW/4HANA migration project
• Build a prioritized conversion backlog based on business criticality and object complexity
• Clarify early in a project whether the target is standalone BW/4HANA, embedded BW in S/4HANA, or a hybrid, since this changes scope and tooling.
• Configure ADSO settings deliberately based on the object's role (staging vs corporate memory vs reporting), not by default.
• Confirm with the client which reporting tools (BEx, embedded analytics, third-party BI) will consume BW/4HANA data, since this affects provider design choices.
• Document object-by-object mapping decisions (which InfoCube becomes which ADSO, which MultiProvider becomes which CompositeProvider) for traceability and testing.
• Document which classic objects require full redesign versus straightforward conversion to set realistic project phases
• Engage business stakeholders early since some remodeled reporting layers will change query behavior or navigation
• Evaluate opportunities to push transformation logic to HANA-native routines during conversion rather than preserving inefficient legacy ABAP
• Learn the ADSO type options (standard, write-optimized, etc. conceptually) before assuming any classic object maps one-to-one.
• Maintain a mapping document from legacy objects to new BW/4HANA objects for audit and support handover purposes
• Map every classic InfoSet join type and MultiProvider selection rule explicitly before building the corresponding CompositeProvider
• Periodically review the data flow for unnecessary layers as the model evolves, since scope creep can reintroduce classic BW-style complexity.
• Plan a hypercare period post-cutover to monitor load performance and query behavior on converted objects
• Plan and test rollback procedures (backup/snapshot points) before starting an in-place conversion.
• Prefer formula and rule-type transformation logic over ABAP routines when performance-sensitive HANA pushdown is desired.
• Prefer HANA-optimized transformation logic (AMDP) over ABAP routines for high-volume or computation-heavy transformations
• Re-test all BEx queries against converted objects with representative data volumes, not just sample records
• Reserve Open ODS Views for exploration or lightweight virtual access, not as a substitute for governed, historized staging.
• Run SAP's readiness or transfer toolkit early to classify existing objects before committing to a migration timeline
• Test process chains and DTPs end-to-end in a non-production system after each batch of conversions
• Treat security role and authorization object review as a first-class migration task, not an afterthought, since object types and technical names change.
• Treat the migration as an opportunity to decommission unused InfoProviders and simplify data flows, not just a lift-and-shift
• Use CompositeProviders as the primary reporting-facing object, keeping ADSOs as clean storage layers underneath.
• Use Open ODS Views selectively for genuinely volatile or low-latency-required source data, not as a default replacement for physical staging
• Use the conversion project as an opportunity to decommission unused InfoProviders, process chains, and transformations rather than carrying forward technical debt.
• Use the conversion/migration planning phase to also rationalize redundant legacy layers rather than mechanically converting everything as-is.
• Validate every converted object against pre-conversion baselines (record counts, key figure totals) before retiring the source object
• Validate report output reconciliation between old and new objects before cutover, especially for finance-critical reports.
• Validate that source system connections and extraction methods used in classic BW are still supported before planning conversion

Senior interviews should test whether the candidate can connect the individual lesson areas, diagnose cross-layer failures, explain trade-offs and design a supportable production operating model.

Interviewers commonly ask candidates to explain the architectural difference between classic BW, BW-on-HANA, and BW/4HANA, and to name the core simplified objects (ADSO, CompositeProvider, Open ODS View). A strong answer distinguishes 'same database, same model' (BW-on-HANA) from 'new database-native model' (BW/4HANA), and acknowledges that migration is a remodeling exercise, not a lift-and-shift.

Interviewers often probe whether a candidate can explain when to use a union-based CompositeProvider versus a join-based one, and how ADSO type settings (active table only vs including change log) affect delta capability and reporting performance. Being able to describe a concrete layered design (acquisition, harmonization, reporting) rather than a generic answer signals real project experience.

Interviewers assess whether a candidate understands that BW/4HANA conversion is a structural redesign, not a version upgrade, and can articulate the trade-offs between in-place and remote/shell conversion. Strong answers reference object simplification (InfoCube/DSO to ADSO, MultiProvider to CompositeProvider, InfoSet retirement), the necessity of a readiness assessment, and awareness that downstream consumers (queries, planning, BPC-type apps, SAC connections) require separate validation. Being able to describe a real remediation example (like InfoSet replacement) signals hands-on project experience rather than textbook knowledge.

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.

Interviewers frequently probe whether a candidate understands the practical difference between a CompositeProvider join and union, and why InfoSet-to-CompositeProvider migration is considered higher risk than simple DSO-to-ADSO conversion. Being able to describe a real join cardinality issue and how it was diagnosed demonstrates hands-on modeling competence rather than only textbook knowledge.

Interviewers assess whether a candidate understands that BW/4HANA migration is an object model conversion, not a simple upgrade. Be ready to explain the difference between technical system conversion and logical object conversion, name the objects that have no direct 1:1 equivalent (InfoSets, MultiProviders, classic DSOs), and describe a realistic validation approach (record count and key figure reconciliation) used to certify a converted object before cutover. Candidates who can discuss in-place versus rebuild trade-offs demonstrate practical migration project experience.