Abstract:
This Blogpost discusses the various migration strategies in fundamental Business and Technical sense.
Disclaimer:
In this blog post, the points that I brought are my own experience and thought process. It may vary from place to place. However, this blog post will give some thought processes to the reader before taking a call on the migration strategy.
Migration Opportunity:
The screenshot below shows a comprehensive view of Today’s SAP BW Customers’ environments. It gives a pretty good picture of the number of opportunities for BW4HANA migration projects with possible options.
Summary of Current BW Environment
Migration Strategy Decision Tree:
Based on my experience, I have developed the below decision tree. It gives a quick overview of different conversion practices with possible scenarios.
Decision Tree for Migration Strategy
Analysis of Different Migration Strategies:
In-Place Conversion:
This strategy is suitable for the system already maintained with LSA++ architecture. Otherwise, it would be tedious to bring the system into an optimized model as suggested in the LSA++ architecture, where the virtual model plays a significant role.
Remote Conversion:
Since Meta Data and Business Data migrations happen in the same course of action, we couldn’t control Meta Data collection and Data Migration. The following are my observance of the remote conversion strategy.
◉ As data transfer happens followed by Metadata, the system will scan and collect the Metadata based on the referential integrity of the IOBJs in line with SID. As a result, almost entire Metadata objects are collected from the downstream system.
◉ We need to do the conversion between every pair of upstream ((BW4HANA Cloud Environment)) and downstream systems (Classical BW environment) like Dev- Dev, Quality – Quality, and Prod to Prod. As a result, not possible to begin the environment with a clean slate.
◉ Since the Data Transfer highly influences metadata collection, there is No Space for Model Optimization and bringing the environment into LSA++ architecture during conversion.
◉ Handling the Delta Records and Missing records is a challenging process.
◉ Managing Production Cutover is a burdensome task.
Shell Conversion:
As I understand, shell conversion is the most flexible approach compared to the other two strategies. The reasons are as follows.
◉ Since Data Migration is not part of the strategy, we have complete control of the Metadata Collection and Migration. So, model optimization is possible during Migration.
◉ Just transform the downstream classical model to the advanced model into a sandbox system in the Upstream Environment.
◉ Do further possible model optimization in the upstream Sandbox and move the optimized advanced data model across the upstream landscape starting from Dev, Quality, Assurance, and Production.
◉ Create a historical data flow from the Down Stream (Existing BW Landscape) targets to upstream targets. Perform the historical data load from the lower level to the upper level.
◉ We could follow all possible data migration strategies.
◉ Perform the Historical Full Data Load after the Init W/O data transfer. It helps collect the delta downstream during historical data migration to fill the data gaps.
◉ Split the Historical data migration parallel based on the Key parameters.
◉ Perform the Historical Data Load for Frozen data after they go live.
◉ Total Data Load flows could be done directly in the upstream system.
◉ Delta sync-up from the source system is manageable.
◉ Easy to handle the Production Cutover and make the smooth execution of Go-Live.
BW4HANA Shell Conversion Activities:
Step by Step Activities of Shell Conversion
◉ Migrate the Old Landscape BW7.2 Classical Data Model to BW/4HANA compatible objects through Shell Conversion in the BW/4HANA Sand Box System.
◉ Remodel the newly migrated BW/4HANA data model to LSA++ architecture in the BW/4HANA Sand Box System.
◉ Collect and transfer the new LSA++ Data Models form BW/4HANA Sand Box to the BW/4HANA Project Landscape through standard transports and perform smoke testing.
◉ Perform Unit Testing in BW/4HANA development system.
◉ Migrate the data models from BW/4HANA development system to BW4HANA quality system. Migrate all historical data from existing quality system.
◉ Perform System Integration Testing (SIT) & UAT in Quality BW4HANA system.
◉ Cutover & Deployment in Production BW4HANA system.
◉ Parallel run of old & new BW systems.
Comparison Table with Key Parameters:
Comparison of Key Parameters
General Note:
The proliferation of cloud computing technologies prevailed to move the SAP BW application from an on-premises environment to a cloud platform. Hence, SAP offers a best-guided solution through a service called “Raise with SAP.” It helps speed up Cloud infrastructure hosting through Hybrid Scaler Partners, particularly with the top three Cloud Services Giants AWS, Google, and Microsoft.
No comments:
Post a Comment