Migration from SAP BW 7.01 to SAP BW/4HANA - a Leap into Virtualisation!
A SAP BW/4HANA migration is certainly not an easy undertaking. However, this gets a special twist when it includes 3.x data flows. In this blog post, we will present the important factors of success for an SAP BW/4HANA migration project. In this context, successful means more than the technical migration of the SAP BW content. It means that a new solution is created under SAP BW/4HANA, taking into account the customer’s requirements, the technological possibilities of SAP BW/4HANA and the systemic restrictions of the target architecture. In our project, we are migrating an SAP BW7.01 system that has grown over decades. This contains a data volume that exceeds that of the SAP BW/4HANA target architecture by a factor of eight.
SAP BW/4HANA Migration
We exclude in-place and remote conversion due to the circumstances explained. We have also found that we cannot transfer all the data from the legacy system to SAP BW/4HANA, but we don’t have to. On closer analysis, it was realised that older data is also not needed in memory. So we agreed on the project to transfer the data from the past three years to SAP BW/4HANA. We also decided on the project to leave all older data in the legacy system, but to connect it to SAP BW/4HANA via SDI as a kind of cold store But that is not the topic of this blog. Rather, it is about how we have used Shell Conversion specifically for our scenario. We also explain which objects we converted, which we did not and why they were not converted.
Step by Step vs. BigBang
In such an evolved system as ours, we not only find a lot of data, but also historically evolved structures. There are many different approaches to solving problems of varying difficulty too. In order not to get bogged down in the complexity of the migration, we decided to approach the whole thing step by step. We didn’t even try to migrate all the content at once or even with data (remote conversion). Initial analyses of the legacy system showed great potential for optimisation in terms of design, performance and virtualisation options (which arise from technological advances under SAP BW/4HANA). For this reason, and because every learning curve, no matter how steep, has its origin at zero, we started with the low-hanging fruits.
Targeted Use of Shell Conversion
Starting with the Conversion Guides, setting up the system landscape (system connections, transport rail, ODP release of the data sources, etc.) and defining the scope for our first iteration, we first migrated all relevant info objects, including all dependent info objects and attributes. This worked without any problems because no conversion was necessary. We have not migrated data flows and InfoProviders of transactional data. We have not migrated data flows and InfoProviders of transactional data. In our opinion, this is where the greatest potential lies to optimise or virtualise with SAP BW/4HANA technology. We believe this is the only way to meet the project requirements in terms of performance, maintainability and data volume. An overview of what we ultimately migrated with the Shell Conversion program, and what we did not, can be seen in the illustrations below.
All images on this page © 2022. BIG.Cube GmbH. All rights reserved.
Explicit mention should be made of the migration of the query objects. This initially caused us problems because the program selected the corresponding multi-provider when we selected the desired query. This needs to be converted into a composite provider. It checks – whether active or inactive – all involved info objects, calculated key figures, variables, InfoCubes, etc. and the objects dependent on them, and in turn the objects dependent on them, etc. Imagine what it means to migrate a query that contains a variable for 0CALYEAR. In our experience, depending on the complexity, it is easier to make a copy of the multi-providers to be migrated, including the query in the legacy system. (Attention: You need at least one InfoCube involved, but not the data flows!)
Virtualisation is Key!
As explained in the previous section, the project does not aim to migrate the data flows and InfoProviders of the transactional data on a 1:1 basis. What do you get when you combine the chassis of a Ferrari with the engine of a VW Golf? We decided to virtualise existing solutions where possible and sensible. The following figure shows a schematic comparison of the problem for the resolution of the “Bill of Material”.
All images on this page © 2022. BIG.Cube GmbH. All rights reserved.
From a technical point of view, the Bill of Material (BOM) is a simple 1:n link between materials and components, which in turn are materials. However, these components can also be sold individually, i.e. only a fraction of the materials are resolved by a BOM. In SAP BW 7.01, the resolution of the BOM was implemented in an ABAP routine with numerous LOOPs due to a lack of options. All of the sales figures, including the data that is not resolved in the BOM, are persisted an additional time. This additional persistence not only results in twice the storage capacity being required, but also in additional maintenance efforts. Because, what happens when the Bill Of Material changes for a material? The persisted data has to be corrected. By completely virtualising this problem, we not only free up storage capacity, we also receive reporting that is always based on the current BOM without having to correct it manually.
Conclusion of a SAP BW/4 HANA Migration
This article highlighted the factors and empirical values of a successful SAP BW/4HANA migration. We made a conscious decision to use Shell Conversion specifically instead of migrating entire data flows including data with Remote Conversion. We want to take into account the technological progress from SAP BW/4HANA to SAP BW 7.01 and redesign the solution approaches of the legacy system. In doing so, we relied above all on the numerous possibilities of virtualisation.
Written by Christian Schultz
Share Post
More Exciting Topics from our Newsroom
Shortcuts for SAP BW in Eclipse
This blog post explains five simple shortcuts to make working...
Read More
Review of the DSAG Annual Congress 2022
These topics were discussed at the DSAG Annual Congress 2022.
Read More
Augmented Analytics Functions in the SAP Analytics Cloud (SAC)
Look into the future with SAC through augmented analytics and...
Read More