SAP BW Transformation to SAP Datasphere & BW/4HANA

[dgeraghty06]

As everyone is aware, the support maintenance for SAP BW will end on the 31st December 2027.

Over the past number of years, SeaPark have been assisting customers with their migration from SAP BW to either SAP BW/4HANA or SAP Datasphere (previously DWC).

In this blog I’ll provide some insights into the migration projects that SeaPark have worked on, the tools SeaPark have developed to optimise the migration process and the BW migration decision tree that SeaPark have built.

When starting out in 2018, the first migration questions a SAP BW customer would ask SeaPark was how long a migration from BW will take, how many resources are required and how much will it cost!

Before starting on your SAP BW transformation program, it’s important to understand what is used and not used on your current SAP BW solution. Some BW solutions could have 20plus years of development on their BW production landscape and over time several of the reporting solutions either become obsolete or not used.

There are several BW rapid discovery tools on the market which highlight what is used and not used on a BW solution, we used our own tool.

Using a BW rapid discovery tool - SeaPark have generated insights for over 60 BW customers, on average up to 50% of the objects in a BW solution are not being used. The following is an example of some insights provided by a recent assessment of a BW solution for one of the largest wholesalers of steel in the Nordics:
 

Object type	Total number of objects in system	Number of objects not used/loaded in last 2 years	Not used in %
3.x objects	3.000	2.996	99,9%
7.x datasources	494	160	32,4%
Infocubes	169	99	58,6%
DSOs	268	138	51,5%
Infosets	26	24	92,3%
Multiproviders	42	28	66,7%
Composite Providers	450	46	10,2%
APD's	24	20	83,3%
Queries	7.871	no executions = 3.492	44,4%
< 100 executions = 6.168	78,4%

Once BW customers could see potential savings through decommissioning unused BW objects, they would task SeaPark with decommissioning these unused objects from their BW solution – this was our next challenge!

Determining which objects can be decommissioned and not be decommissioned is a manual and complex process which was prone to mistakes. After several manual decommissioning projects, it was decided within SeaPark that we’d use a dedicated BW decommissioning tool rather than determining which objects that could be decommissioned manually.

BW Decommissioning tools will require several BW metadata tables from the SAP BW system along with a list of multiproviders and/or composite providers that are required to be decommissioned (based on the BW Rapid discovery tool insights).

BW decommissioning tools will have two main terms:

• Keepers – the term “Keepers” is a BW dataflow object that cannot be decommissioned. The BW decommissioning engine knows that once it hits a “Keeper”, no objects below this “keeper” object should be decommissioned.

• Floater – the term “Floater” is a BW dataflow object that is not mapped to a multiproviders or composite provider.

Once the BW decommissioning engine is built from the metadata tables and the multiproviders and/or composite providers have been confirmed for decommissioning with the customer along with the keepers list, the decommissioning engine will generate a list of BW objects that can be decommissioned broken down by object type (over 32 different object types). We also include an additional file of BW Objects that are not linked to a composite or multiprovider – we call this file the “floater file”!

The final analysis done is the query usage for the past two years. The classifications are no usage (0 executions); low usage (<10); medium usage (between 10 and 100) and high usage (> 100). The analysis also compares the BW queries in development compared to BW production and how out of sync they are. On average only 20% of BW queries in a BW production solution have more than 100 executions.

If a BW customer (BW 7.5 on HANA) is unsure of whether to migrate to SAP BW/4HANA or Datasphere, SeaPark recommends that the customer makes their BW backend BW/4HANA enabled. A point to note is, that there is no additional SAP license cost by enabling your BW backend to be BW/4HANA compatible (installation of the BW/4HANA starter add-on is free😊).

The next challenge was the overhead of BW to BW/4HANA migration testing. Every customer will have a different testing strategy from executing a BW/4HANA migration task and doing a “sanity check” up to doing a full-blown testing taking pre and post snapshots of the impacted metadata and data. Doing detailed testing for BW/4HANA migration is a very time-consuming process. They are several BW automated testing tools on the market to overcome this challenge and reduce the overall migration cost.

The automated testing tools take pre and post migration snapshots of metadata tables to ensure no negative impact to the existing BW objects.

The Testing Process document contains:

• Metadata snapshots

• Data snapshots (manual)

• Summary Tab highlighting any anomalies of metadata and/or data.

If the testing strategy is to do a detailed level testing (pre & post on data and metadata) then automated testing tools could save from 20 to 30% of the overall migration cost.

Automated testing tools are seen by customers not only as testing documents but also as an auditable document, that can be reviewed in the future to determine what was migrated and what was the impact of this migration to the impacted metadata and data.

The most recent challenge is the technical limitations of a BW migration (Shell or remote) to SAP BW Bridge in SAP Datasphere

Before starting the BW migration to SAP BW Bridge in SAP Datasphere, it’s important to understand the list of objects per object type that needs to be migrated to the SAP BW Bridge.

There are several ways to do this from running individual migration tasks to running a dedicated Datasphere migration tool to determine this list of objects and which object types are and are not supported on SAP BW Bridge. By running this process/tool will provide a more accurate estimate of the migration from BW to SAP BW Bridge.

Most of the SAP BW customers that engage with SeaPark have completed their S/4HANA migration journey or will be in the coming months. Our recommendation for them is to review the possibility of utilising S/4HANA embedded analytics to replace their current operational reporting on their SAP BW solution which will reduce the scope & effort for their BW migration journey. This is where our last challenge lies!

Thanks, SAP, for creating so many S/4HANA embedded applications 😊. The issue for any SAP BW developer is to know which S/4HANA embedded applications are relevant for each of their BW application areas. If you ever had the pleasure of opening the SAP Fiori App Library (link below) – there are over 15k applications and over 3k ODATA services!

https://fioriappslibrary.hana.ondemand.com/sap/fix/externalViewer/

On a recent trip to Walldorf, we had the opportunity to speak with the product management and development teams. One of the items we had on our “wish list” was to implement a filter/mapping on the SAP Fiori App Library for all operational BW business content datasources to relevant S/4HANA embedded applications.

I appreciate that this is not a clear one to one mapping, but it would be extremely useful to SAP BW Architects who have little or no knowledge of S/4HANA embedded applications and have been asked to review them! Good luck going through 15k embedded applications one by one!

Although I can understand why SAP BW customers are adopting a sit and wait strategy, I believe that there are several activities (decommissioning, enabling BW backend to BW/4HANA compatible objects & reviewing S/4HANA embedded analytics) which can be completed before deciding on whether to migrate to BW/4HANA or Datasphere. It is worth pointing out that a SAP BW migration project could take anywhere from 6 months to 5 years depending on the speed of the migration project along with the size of the current BW solution.

I hope you find this blog informative and feel free to leave a comment if you have any BW migration stories to share or have any questions on the BW migration process or tools.