Many customers are already taking the first step toward BW/4HANA by migrating their system landscapes to BW7.5 on HANA. In our blog entry BW/4HANA MIGRATION – FAQs, we addressed some recurring questions from discussions with our customers about migrating to BW/4HANA.
However, in our discussions with customers, we often encounter one key question: "How much will migration to BW/4HANA actually cost me?"
We would like to address this question in the following article by discussing approaches to estimating the effort involved. In practice, we often encounter situations where a complete migration is not required. Instead, customers are looking for brownfield or even greenfield approaches.
At the outset, the objectives of the BW/4 implementation should be clarified. This also includes the target architecture. The approach should not be defined by the migration path; rather, the path should be derived from the objective. It often does not make sense to completely migrate established BW systems because this makes it difficult to exploit the potential of a fundamental architectural change. See also: YOUR ROAD TO SAP BW/4HANA.
In this article, we will focus on the cost drivers of a technical migration of BW/4HANA systems. Remote or shell conversion can be used to effectively support brownfield approaches. The process of migrating to BW/4HANA can basically be divided into three phases:
Below, we outline the three phases, although there may be slight differences depending on the migration approach (remote, shell, in-place).
Register now for a free
BW/4HANA Migration Assessment
BW/4HANA Migration Assessment
Planning an SAP BW/4HANA migration? Start correctly – with our fixed-price Migration Assessment.
Mainstream support for SAP BW 7.5 ends in 2027 – therefore, simply 'carrying on as before' is not an option. At the same time, BW/4HANA is far more than a simple upgrade: the data model and architecture undergo fundamental changes. Our Migration Assessment will show you within a few weeks which migration path, effort, and risk are realistic for your company – based on facts, not assumptions.
Utilize our BW/4HANA Migration Assessment as a cost-effective, low-risk entry point into your SAP BW/4HANA transformation.
Phase 1: Preparation
In this phase, the existing BW systems should be made ready for migration to BW/4HANA. This does not mean converting data models or similar, but rather creating the prerequisites for the BW/4 conversion tools in particular. The latter can then be used to analyze which steps can be performed automatically and which cannot. This creates a very important basis for the analysis phase and the detailed analysis of the migration effort.
Our blog articleYOUR ROAD TO SAP BW/4HANA provides a detailed overview of the various options for migrating to BW/4HANA.
Examples of possible work packages
| work package | Description |
|---|---|
| release change |
An important prerequisite for migration is that the BW/4 conversion tools can be installed. These tools include analysis programs that can be used to analyze "migration capability." As a minimum requirement, we recommend updating to Release BW 7.3. However, this release is already quite old. The ideal release would be BW 7.5, as this already includes a few necessary changes that will be required when switching to BW/4HANA anyway. These include, for example, an ABAP field type adjustment. This means that customer-specific programs that use this ABAP field type must be adjusted manually. Another cost driver can be the number of 3.x data flows to be migrated. We therefore recommend only making the change if it is necessary for important reasons. This should be evaluated in particular for in-place migration. Depending on the age of the BW release, it should also be considered that a BW 7.5 update can give you a little breathing space until 2027. |
| Review of the authorization concept |
Starting with the release of SAP BW 7.3, an analysis authorization concept is mandatory. If this is not yet in place, the authorization concept must be converted. There are three possible ways to do this:
1. Freely accessible data: If data content is not restricted, the simplest approach is to include the 0BI_ALL analysis authorization in all authorization roles. This approach requires the least amount of effort. 2. Migration: With the help of a migration report, the existing authorizations can be migrated to the new SAP BW 7.x approach. Although this method is quick, a large number of analysis authorization objects are generated and there is a risk that the system will quickly become messy and confusing. It is also very difficult to take a step back if you want to tidy things up. 3. Fundamental introduction of analysis authorizations: With this approach, the introduction of analysis authorizations is preceded by a concept and a clean-up of the authorization issue. First, the user groups and data areas that are worth protecting are identified. Instead of then creating separate analysis authorizations for each characteristic value, exit variables are used to flexibly control authorizations. These exit variables also allow the values of analysis authorizations to be maintained, for example, via a central maintenance view. The variable exits can also be used to pre-restrict BW queries, which increases user convenience. However, this approach also involves the most effort. |
We also recommend the following tests:
| examination | Description |
|---|---|
| dual stack split | An ABAP stack only is required for the subsequent error-free use of the SAP BW/4HANA conversion tools. If this is not available, a dual stack split must be performed. |
| Checking object simplifications for SAP BW/4HANA | The SAP Simplification List (2421930 - List of Simplifications for SAP BW/4HANA) is useful for checking object simplifications. |
| Checking the system requirements for SAP BW/4HANA |
The system requirements for the new SAP BW/4HANA system and the provision of the necessary tools should be checked. The following SAP Notes may be helpful in this regard:
|
| Audit of SAP source systems |
The SAP source systems must be ODP-ready. Therefore, the following SAP Notes should be observed:
|
| Testing of non-SAP source systems |
Non-SAP source systems are connected via SDA (Smart Data Access) or SDI (Smart Data Integration). The following SAP Note may be helpful here:
|
| Sizing Check |
The BW system should be sized using the SAP Note below. This will give you an idea of how large BW/4HANA should be, although the checks can only be based on the existing BW system. Converting the architecture from LSA to LSA++ can significantly reduce data redundancy, which will reduce storage requirements. However, it is often difficult to estimate the extent of this effect in advance.
|
Finally, the BW/4HANA conversion tools can be deployed on the prepared systems.
Phase 2: Analysis
Once the BW/4 conversion tools have been provided, the determination of the effort required can begin. Below, we list the activities involved in this detailed analysis and identify the effort drivers. Essential for determining the migration effort and a prerequisite for starting the implementation phase is the definition of the data models to be migrated to the BW/4HANA system (scope selection).
Basically, the following cost drivers can be distinguished:
Scope selection and the cleansing of data models
As mentioned at the beginning, it is important to clarify which data models are to be migrated. This has a significant impact on the migration effort.
When performing an in-place migration, it is important to remember that the system must be cleaned up to remove anything that is not to be migrated. With mature systems, this can involve a lot of preparatory work, which must be factored into the project schedule.
Conversion tool costs
These are costs incurred in connection with the use of conversion tools. This refers to activities that are part of the "normal" procedure when using conversion tools. The costs can be roughly estimated in advance based on the number of objects and our experience.
ABAP customizations
The effort required to adapt ABAP coding can be divided into effort incurred before the actual migration (e.g., conversion of variable exits to BAdI implementations) and effort incurred after the actual migration (e.g., HANA optimizations through code pushdown or use of virtual data flows with calculation views).
The RS_B4HANA_CODE_SCAN report identifies problematic ABAP coding, allowing conclusions to be drawn about how many code adjustments are necessary before system migration. The objects to be migrated are then defined, making the effort involved transparent.
ABAP adjustments after system migration represent potential opportunities in the new system environment that can be realized through optimization. An analysis should be conducted to determine in which data model areas optimization would be beneficial. Since the switch to the HANA database already speeds up existing data flows and data queries, we recommend optimizing the data models as needed.
Manual remodeling
Not all objects can be converted automatically. Some objects must be processed manually. In the simplest case, these are 3.x data flows, but certain settings in InfoObjects may also require manual adjustment. An overview of possible restrictions can be found here.
Programs such as ZBW_TRANSFORM_FINDER, which identifies transformations that can already be executed on the HANA database, can be helpful when analyzing manual efforts. The RS_BW/4HANA_CONVERSION_CONTROL program also returns a detailed list of all objects in the BW system that are already BW/4HANA-compatible, can be migrated automatically, or require manual remodeling. To make the effort transparent, this list must then be enriched with information on whether or not the objects are actively used data models. The result is a list of manual activities that can be estimated with a high degree of reliability.
Determination of expenditure
In practice, an Excel list has proven useful for listing all necessary adjustments, in which the necessary work is parameterized and the expected effort is entered by T-shirt size (affected object, necessary work, T-shirt size of the effort). This allows you to estimate the expected effort for performing the migration quite well. The analysis phase provides a very clear picture of the expected effort.
Phase 3: Implementation
The implementation phase involves the estimated costs for carrying out the migration as specified in 2). However, it should also be noted that infrastructure work is also required for system provision. This includes, for example:
Initial setup of BW/4HANA systems
- Initial configuration via transaction STC01 – Task "SAP_BW4_SETUP_SIMPLE"
- Installation of SAP Landscape Transformation (for remote conversion)
- Execution SAP BW Note Analyzer
- Connection of source systems
- Connection of reporting tools
- Creation of RFC connections (including to old BW)
- User and authorization concept
testing effort
During migration, not only data models but also a large amount of content is transferred to the new BW/4 HANA systems. In addition to the actual master and transaction data, this includes a lot of technical information, such as request information. It is therefore important to allow sufficient time for validating the migration. We recommend selecting a representative sample for data validation that is based on the reality of the BW architecture. This is a pragmatic approach that has proven itself in practice.
Summary
We hope that our article has provided you with an overview of the potential cost drivers involved in BW/4 migration and the steps required for estimating the costs. You can roughly expect the total effort to take around 20 days. Depending on your approach to introducing BW/4 HANA, there may also be more compact options available. Feel free to contact us for more information!
Authors: Simone van Munster and Adrian Kaltenhäuser
Christopher Kampmann
Head of Business Unit
Data & Analytics
christopher.kampmann@isr.de
+49 (0) 151 422 05 448
