BW/4HANA Transfer Toolset: Conversion Paths and Object Readiness

Explanation

Moving an existing SAP BW system (either on classic databases or already on SAP HANA as 'BW powered by HANA') to BW/4HANA is not a simple upgrade - it is a data model conversion project. BW/4HANA no longer supports several classic object types natively for new development: classic InfoCubes, classic DataStore Objects (write-optimized, standard, direct update), InfoSets, and MultiProviders are superseded by the Advanced DataStore Object (ADSO), CompositeProvider, and Open ODS View. The transfer process therefore has two dimensions: a technical system conversion (moving the software/database stack) and a logical object conversion (remodeling existing InfoProviders and transformations into BW/4HANA-compliant equivalents). Why this matters for a consultant: production BW systems often carry ten to twenty years of accumulated InfoProviders, transformations, process chains, and custom ABAP routines. A naive lift-and-shift is not possible because the underlying object model changed. SAP provides a transfer toolset (delivered as part of the BW/4HANA transition content, sometimes referred to as the BW4HANA Starter or Transfer Cockpit depending on release) that analyzes the source system's object inventory, flags objects that are 'ready', 'convertible', or 'not supported', and generates a conversion worklist. Consultants use this analysis to build a remediation backlog before or during the technical conversion. Design and implementation approach: 1. Run a pre-check analysis against the source BW system to inventory all InfoProviders, transformations, process chains, queries, and custom code. This produces a categorized list: objects that convert automatically (e.g., simple standard DSOs to ADSO), objects requiring manual remodeling (e.g., MultiProviders combining classic cubes need to become CompositeProviders referencing ADSOs), and objects with no direct equivalent that require redesign (e.g., certain planning-specific objects or heavily customized routines). 2. Prioritize objects by business criticality and query dependency - core reporting InfoProviders and their downstream queries should be converted and validated first in a non-production system. 3. For each InfoProvider being converted, decide between in-place conversion (retaining historical data by converting the object structure) versus rebuild-and-reload (dropping the object and reloading from a persistent staging layer or source system). In-place conversion preserves history but takes system downtime; rebuild is cleaner for objects where source data is easily re-extractable. 4. Transformations and routines written in ABAP need review because BW/4HANA still supports ABAP-based transformations, but consultants should evaluate whether logic can be pushed down to HANA (using AMDP-based routines) for performance, especially given BW/4HANA's expectation of HANA-native processing. 5. Process chains referencing converted objects must be validated end-to-end after conversion, since load sequencing, DTP filters, and semantic keys may shift when moving from classic DSO to ADSO (which unifies the write-optimized, standard, and direct-update DSO types into configurable ADSO 'types'). Runtime and integration considerations: after conversion, data flow behavior can change subtly - ADSOs support different activation types (standard, direct update-like write mode) that affect how the change log and active table behave, which impacts delta extraction to downstream systems and Analysis for Office or BEx-based reports relying on specific InfoProvider technical behavior. CompositeProviders replace MultiProviders and InfoSets but use HANA-based union/join logic, so query performance profiles can differ - some queries improve significantly, others need index or join type tuning. Troubleshooting and production support: common issues include queries failing after conversion due to characteristic or navigation attribute changes, process chains breaking because a converted ADSO no longer supports a DTP filter that existed on the old DSO, and semantic key mismatches causing duplicate records during delta activation. Consultants should always validate record counts, delta pointers, and key figures against the pre-conversion baseline before decommissioning the old objects. Deployment differences: on-premise/private cloud BW/4HANA systems allow more granular control over the conversion sequence and downtime windows; SAP has also offered guidance for direct 'remote conversion' or 'in-place conversion' scenarios, but exact tooling names and availability can vary by release, so consultants should verify current guidance rather than assume feature parity across releases.

Code example

-- Example: identifying classic DSO objects for conversion assessment-- (Illustrative RSA1/monitoring style pseudo-query, not a literal SAP report) * Pseudo pseudocode for a conversion readiness checklist entryInfoProvider: ZDSO_SALES_STD (Standard DataStore Object)  -> Target: Advanced DSO (ADSO) type 'Standard'  -> Dependencies: 3 transformations (source: ZDS_SALES_EXTRACT)  -> Downstream: 2 queries, 1 CompositeProvider (ZCP_SALES_REPORTING)  -> Conversion decision: IN-PLACE (preserve 5 years of history)  -> Post-conversion validation: compare record count and key figure sums     between ZDSO_SALES_STD (pre) and new ADSO (post) for last 3 fiscal periods InfoProvider: ZMPRO_SALES_ALL (MultiProvider)  -> Target: CompositeProvider (union of ADSOs)  -> Action: manual remodel required - MultiProvider not supported natively  -> Rebuild CompositeProvider referencing converted ADSOs  -> Re-test all queries built on ZMPRO_SALES_ALL for attribute navigation

Real project scenario

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 eligible for automatic ADSO conversion, but 15 MultiProviders combining sales, inventory, and finance cubes required manual CompositeProvider redesign. The team built a phased plan: converting finance objects first (lower query volume, easier to validate), then sales objects in a dedicated cutover weekend with a rollback plan to restore from a system backup if query validation against a report reconciliation checklist failed. Process chains were re-tested in a sandbox system before being scheduled in production, and a two-week hypercare period was used to monitor delta loads and query runtimes against the ADSO-based objects.

Common mistakes

• Assuming all classic BW objects convert automatically without checking the readiness/conversion category from the pre-check analysis • Converting InfoProviders without first validating downstream query and process chain dependencies • Not distinguishing between in-place conversion and rebuild-and-reload, leading to unnecessary downtime or lost history • Ignoring ABAP routines and custom code that may not perform well or may not be supported as-is on BW/4HANA • Decommissioning classic objects before completing side-by-side validation of record counts and key figures • Underestimating the effort to redesign MultiProviders and InfoSets into CompositeProviders and Open ODS Views

Best practices

• 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 • Validate every converted object against pre-conversion baselines (record counts, key figure totals) before retiring the source object • Test process chains and DTPs end-to-end in a non-production system after each batch of conversions • Evaluate opportunities to push transformation logic to HANA-native routines during conversion rather than preserving inefficient legacy ABAP • Plan a hypercare period post-cutover to monitor load performance and query behavior on converted objects

Interview angle

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.