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.
Explanation
Moving from classic SAP BW (on ECC or BW-on-HANA) to BW/4HANA is not a simple upgrade — it is a structural transformation. BW/4HANA removes several classic object types (InfoCubes, standard DataStore Objects in their old form, InfoSets, MultiProviders in the classic sense) and replaces them with a smaller set of simplified objects: Advanced DataStore Objects (ADSO), CompositeProviders, and Open ODS Views. Understanding why this matters is the starting point: fewer object types mean fewer layers of redundant data persistence, simpler transformation chains, and better alignment with HANA's in-memory, columnar processing model. For a consultant, the business driver is usually cost of ownership and performance — customers want faster loads, simpler landscapes, and to retire legacy ECC-based BW systems ahead of SAP's maintenance timelines for older releases. There are two broadly recognized conversion approaches, and the choice has major project implications. In-place conversion takes an existing BW system (already on BW-on-HANA, i.e., BW 7.5 SP-level compatible with BW/4HANA) and converts it directly: the same system ID, same data, same authorizations, transformed step by step using SAP's provided conversion tools. This path preserves history and requires less re-testing of downstream consumption (queries, reports, BPC-type add-ons) because much of the object identity persists, but it demands very careful sequencing since InfoCubes and classic DSOs must be individually converted or replaced, and unsupported objects (like certain InfoSets or specific planning applications) may block the conversion until remediated. Remote conversion (sometimes called shell conversion or new-installation conversion) builds a brand-new BW/4HANA system and then transfers metadata and, selectively, data from the source system. This is attractive when the existing landscape is old, heavily customized, or running on outdated hardware/OS, or when the customer wants to use the migration as an opportunity to redesign the data model rather than carry forward technical debt. The trade-off is significantly more implementation effort: transformations, process chains, and security roles typically need to be rebuilt or adapted for the new simplified objects, and historical data loads must be planned carefully (either reload from source systems or selective data transfer). Regardless of path, the object mapping is central to planning. Classic InfoCubes generally become ADSOs configured to behave like a cube-style provider (with appropriate activation and reporting settings), while standard DataStore Objects map naturally to ADSOs with the corresponding key figure/characteristic layout. MultiProviders are superseded by CompositeProviders, which can union or join ADSOs, InfoObjects, and even HANA views directly — this is one of the most valuable simplifications since it reduces the need for staging layers purely for reporting union logic. InfoSets are discontinued; any InfoSet-based reporting logic must be redesigned, typically using CompositeProviders with join semantics, and this frequently surfaces functional gaps that need workarounds. A readiness assessment is a mandatory early step in any real project. SAP provides tools to analyze the existing BW system and flag objects that are not convertible or need manual remediation before conversion can proceed — things like unsupported planning functions, certain third-party extractor dependencies, or custom ABAP code directly referencing classic object APIs that no longer exist in the same form. Consultants should never assume all objects will convert cleanly; a large legacy BW system commonly has years of accumulated technical debt (unused InfoProviders, deprecated update rules, orphaned process chains) that should be cleaned up before conversion rather than dragged along. Another practical consideration is downtime and business continuity. In-place conversions are typically executed in phases with defined maintenance windows, and rollback planning is essential — teams must decide at what point a system backup or database snapshot is the safe rollback point, since partial conversions can leave a system in an inconsistent state. For remote conversions, parallel running of old and new systems during a transition period is common, with reconciliation of report results being a key acceptance criterion before cutover. Finally, consultants should be clear about scope boundaries: converting the BW data warehouse layer does not automatically upgrade or migrate connected S/4HANA source systems, BPC-type planning applications, or SAP Analytics Cloud connections — those integration points need their own validation. On S/4HANA, embedded analytics (using CDS views and virtual data model queries) is a complementary, not competing, approach, and many transformation projects use the conversion as an opportunity to shift some reporting away from classic BW into embedded analytics where appropriate, reducing the footprint that needs to be converted at all.
Real project scenario
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.
Common mistakes
• Assuming all classic objects convert automatically without remediation, then discovering blocking issues mid-project. • Choosing remote conversion for cost/time reasons without budgeting the much larger rebuild effort for transformations and security roles. • Not running a proper readiness/pre-check analysis early enough to influence project timeline and budget. • Ignoring unused or deprecated objects, dragging technical debt into the new BW/4HANA landscape instead of decommissioning it. • Underestimating the effort to validate InfoSet-to-CompositeProvider replacements, especially where join semantics differ subtly from InfoSet logic. • Failing to plan a clear rollback point (backup/snapshot) before starting an in-place conversion.
Best practices
• Always run a formal readiness/pre-check analysis before committing to a conversion approach or timeline. • Use the conversion project as an opportunity to decommission unused InfoProviders, process chains, and transformations rather than carrying forward technical debt. • Document object-by-object mapping decisions (which InfoCube becomes which ADSO, which MultiProvider becomes which CompositeProvider) for traceability and testing. • Validate report output reconciliation between old and new objects before cutover, especially for finance-critical reports. • Plan and test rollback procedures (backup/snapshot points) before starting an in-place conversion. • Treat security role and authorization object review as a first-class migration task, not an afterthought, since object types and technical names change.
Interview angle
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.