Case Study: Selecting a Conversion Type for SAP BW/4HANA Migration

An SAP BW/4HANA migration is a significant investment for any organization. With several migration options available, selecting the right one will reduce project risk, streamline the timeline and can even eliminate long-standing technical debt. This client case study frames the considerations that led to a successful methodology selection and upgrade. Our client had a mission-critical environment that served an extended service network user base and long-standing technical debt they were looking to resolve.

Before we dive into the client story, let us review the upgrade options SAP provides for a BW/4HANA system conversion:

• In-place conversion: This option will convert all classic objects to the newer HANA-optimized objects. Once converted, then the system upgrade is performed to convert from BW 7.x to BW/4HANA.
• Remote conversion: A remote conversion will set up a new SAP BW/4HANA system as a greenfield (new installation) system. The objects and data flow from the legacy system are selected and transferred to the newly established system, along with the data the legacy objects held.
• Shell conversion: A shell conversion is similar to a remote conversion, but without transferring the data contained in the objects. Only the structures are converted, providing additional flexibility. Typically, data will reload from the source systems in this scenario, but other options are also possible.

While considering an SAP BW/4HANA upgrade scenario, the following influencing factors should be evaluated:

• Source system version and patch level
• Current BW system version and patch level
• Historical data availability in the source systems
• Production downtime business impacts and timing
• Multiple system dual maintenance costs and syncing effort
• Development freeze timelines and the impact on the organization
• Operational Data Provisioning (ODP) requirements
• Current BW objects compatibility (i.e., Infocube or DSO vs ADSO)

Client scenario

Introduction:

Protiviti recently aided a global biopharmaceutical company with an upgrade from BW 7.x to BW/4HANA. The legacy application was BW on HANA 2.0 version 7.5 installed on-premises. The client still had some legacy objects, as well as some technical debt they wished to resolve. Replication into the staging environment required additional development. The prior state environment was prone to performance issues and memory leaks. This company hoped to modernize their analytics landscape by leveraging the latest SAP information management tools and make this system their first move into a hyperscale/cloud environment.

Prior landscape:

• Customer was on BW 7.5 HANA 2.0
• 90% of data models were compatible SAP BW/4HANA objects, meaning they had already been converted from data store objects (DSO) to advanced data store objects (ADSO) and Infocubes had been eliminated
• Multiple source systems were being loaded into this system, both SAP and non-SAP
• Users interacted with the data using both SAP BusinessObjects and a non-SAP reporting tool, Qlik Sense
• The client was using native and hybrid HANA data models for reporting
• All historical data was available from both the SAP and non-SAP source systems
• Multiple high-priority projects could not be put on hold due to the expected monetary impact
• The BW system was designated as mission critical for thousands of global stakeholders
• Establishing two systems (dual maintenance) was preferred to the possibility of extended downtimes or system development freezes

The challenge:

Over time, additional SAP source systems had been added to the landscape through corporate acquisitions, introducing a unique master data source system compounding challenge that caused batch processing errors and emergency escalation for manual corrective maintenance.

This source system classification limitation manifested in all transaction data providers, resulting in limitations during data stewardship and reduced agility for the system to react to changes in the respective source systems. The client required the source system classification to be pushed to all reporting objects and HANA views for maximum flexibility.

Through more than a decade of iteration, the naming convention of objects in the system was not consistent and standardized. Many depreciated legacy and obsolete master and transactional data objects existed in the system and the client wanted to correct or eliminate them.

As all the core master data structures required remediation to include the source system ID as a compounded key field, these changes cascaded into nearly every object in the system. From data sources to the reporting objects, in this client’s scenario, the total number of objects requiring remediation exceeded 1,500.

The solution:

The shell conversion approach was used to reduce downtime for end-users, eliminate the technical debt and supply a streamlined system. The development and enhancement timeline to remediate these many objects took several months, but the core objectives and goals were recognized.

Protiviti worked with the client during scope transfer to identify obsolete data flows and convert only the needed objects into the BW/4 HANA system. Due to the enhancement requirements, additional dual maintenance tracking and remediation emphasis were required in the project plan. In similar scenarios, where the core design of the BW objects needs to be changed or enhanced during shell conversion, we recommend additional project management support for the dual maintenance including a dual-maintenance technical change leader.

As we worked through this complex project, we recognized that more time than was first estimated would be needed to load data from the source systems. However, performing these loads helped us identify bugs and remediate them ahead of other testing scenarios, streamlining that process.

An unforeseen benefit to migrating using a shell conversion was that technical and user testing scenarios were improved by the dual system availability. Developers gained added tools to validate data ahead of end-user testing.

In order to get the most out of a system conversion, it is important to consider which path will work best for each organization’s unique needs. Maximizing an SAP BW4/HANA investment requires thoughtful planning before setting out on the migration journey.

For clients moving to SAP Data Warehouse Cloud (DWC), a new feature, the BW Bridge, enables a Shell conversion migration path between SAP BW (typically, but not necessarily) 7.x and DWC.

To learn more about our SAP capabilities, contact us or visit SAP Consulting Services.