Migration Approach of SAP PI/XI to SAP PO (Hana Enterprise Cloud/On-Premise) or Cloud Platform Integration Apps or API Management
Gartner predicts that through 2018, 90 percent of organizations will lack a postmodern application integration strategy and execution ability, resulting in integration disorder, greater complexity and cost. “Postmodern ERP represents a fundamental shift away from a single vendor megasuite toward a more loosely coupled and federated ERP multi cloud environment,” said Carol Hardcastle, research vice president at Gartner.
“This new environment promises more business agility, but only if the increased integration complexity is recognized and addressed correctly.”
If the digital transformation is your dream drone to next century business model then integration tool is your engine and assessment of the organization integration roadmap whether it is fit for the future is the fuel to fly your plane for landing correctly at the destination i.e success of the organization digital transformation!
The burning question for any organization who want to upgrade their SAP PI systems is whether they have to move to SAP PO on premise or SAP PO HEC or SAP CP Integration Apps.
The fundamental migration challenge for IT Teams is to justify the upgrade project budget will not be money down the drain in future as organizations are embracing asset light cloud model at an unprecedented space.
The next question IT teams may have to answer is it right to build new interfaces in SAP PI or should they procure SAP PO as it is more proven and build integrations in SAP PO than SAP CP Integration Apps ( Do this apps meet all integration requirements that organization has?) to build all cloud integrations on cloud platform in parallel to minimize upgrade costs in future.
It is also not unusual to meet organizations who just want to upgrade their systems without having an appetite on assessing whether the current integration roadmap or tools are fit for the future but we strongly recommend organizations to revisit, re-evaluate middleware tools and upgrade roadmap and and classify existing interfaces using ISA-M style align with their digital cloud roadmap before choosing a particular interface migration path. The blog focuses on SAP Integration portfolio but we can follow same principles for other middleware products.
Middleware upgrade projects should not be seen as “Lift and Shift Infrastructure upgrade projects” but should be seen as a window of oppurtunity to simplify your integration landscape, globalize data models that are built in de-centralized and fragmented way across the organizations for years, evaluate business critical interfaces for embedding and infusing machine process intelligence to drive revenue and build agile integration API patterns i.e fit for future to quickly and seamlessly connect business partners and consumers. Old legacy applications aren’t replaced and still exist in many organizations due to integration complexity and cost required to replace the integrations and hence it is important to set the right strategic vision for your middleware projects.
Align Migration & Cloud Strategy
There is no bullet point answer to the above questions as the approach varies for each organization and largely depends on the strategic objectives, size of the organization and immediate project time lines and budgets, however we recommend to approach the migration in phased model and work closely with current and future IT digital system transformation roadmap to choose the right approach and tools for migrating the integration scenarios.
The following sample usecases may provide you a rough guideline on how to approach migration :
Use Case 1 : 100% of IT systems are moving to cloud in future
This IT digital system transformation roadmap is generally followed by smaller organizations.
Migration Approach: If the organization has cloud and API first roadmap and there will be no on-premise integrations in future then we advise organizations to procure SAP CP apps based on the existing interface integration styles to minimize the costs in future and build integrations to all applications that are moving to cloud using CP Integration Apps and SAP Cloud Connector and build a migration path based on the time line of IT Application cloud roadmap i.e. If application A is moving to cloud then migrate all those interfaces using the same time line into SAP Integration Portfolio from SAP PI based on style and your future integration roadmap.
You can then decomission the SAP PI at the end of IT digital cloud transformation roadmap and go for asset light model that may cut down your OPEX costs drastically.
We assume all the interfaces that are built in SAP PO fall under process invocation integration style and hence they can be moved to SAP CPI tenant but it is a good practice to re-evaluate each interface and classify the interface style ( Ex: Common Interface Data Models that can be API enabled to drive revenue externally and open up to customers to increase intrinsic value and also decrease Opex costs, include machine learning in the orchestration of business critical interfaces to drive revenue by predicting future outcomes) before migrating the interface using the below table to ensure that you pick the right tool for integration.
Cloud On Premise Integration Scenario tools
On Premise to On Premise Integration Tools
(This pattern is used when data is transferred as a message and the interfaces orchestrate processes between two application systems )
|SAP Cloud Platform Integration, SAP Cloud Platform Workflow, SAP Cloud Platform Rules||SAP PO , SAP BPM, SAP BRM, SAP API Management|
(This pattern is used when data is cleansed or validated and distributed in mass from source system to multiple target systems or high volume data needs to be extracted from source systems and merged into analytic systems for reporting or synchronise data for offline reporting or machine learning analytics)
SAP Data Hub, SAP CPI Data Services, SAP HANA Smart Data Access, SAP HANA Smart Data Integration,
SAP Hybris Data Hub,SAP Cloud Remote Data Sync, SAP Cloud Agile Data Preparation
|SAP Data Services,SAP SLT, SAP Master Data Governance, SAP MDM|
(This pattern is used when we have to fetch master or transaction data from passed between user facing web or mobile or cloud applications and backend systems)
|SAP Open Connectors, SAP API Management , SAP CPI OData provisoning, SAP CP OData Provisoning||SAP Gateway, SAP PO|
(This pattern is used when target or source system is a device that needs to be integrated with either on-premise or cloud systems or devices)
|SAP Open Connectors, SAP API Management, Enterprise Messaging, Rabbit MQ, SAP HANA Data Management Suite||Redhat, SAP PO, JMS Systems , MQTT,KAFKA|
Use Case 2 :More than 35% of IT systems are moving to cloud in future
This IT digital system transformation roadmap is generally followed by medium to large organizations.
Migration Approach: In this scenario, we may need a hybrid integration platform i.e SAP PO and SAP Cloud Platform Integration apps have to co-exist as there will be atleast 30% integrations betwen two different on-premise systems. However, you will have to evaluate the Opex costs of Hybrid Integration Platform against how many on-premise to on-premise integrations may remain in the organization in the future i.e if there are handful on-premise integrations then it may not be worth retaining SAP PO due to seperate Opex costs. We advise to approach migration in the same way as first usecase i.e align the phases and timelines of migration with the organization IT digital system transformation roadmap.
Use Case 3 : Less than 35% of IT systems are moving to cloud in future
This IT digital system transformation roadmap is generally followed by organizations who don’t see value of going to cloud either due to security requirements or organizations who don’t have a digital strategic vision.
Migration Approach: In this scenario, we may migrate all the interfaces from SAP PI to SAP PO preferrable on HEC or Cloud to save atleast infrastructure costs using the model documented here. They can choose either a big bang or phased approach for migration based on scale and budget of migration project. However, the side effect of this approach is that we may need to spend money again to do the interface migration if the organization chooses to go on a digital cloud roadmap later.
If the organisations like us to help with setting up integration roadmap,planning and estimation of migration project then they please provide following information and contact us for conducting a workshop to provide a rough estimate .
|Category||Keytree Question||Detailed Question|
|Architecture||What is Organisation Digital/ Cloud Strategy? Can you please attach a reference document?||No.of current on-premise systems?|
|No.of current cloud systems?|
|No.of future on-premise systems?|
|No.of future private or public cloud systems?|
|Do you want migration project to identify oppurtunities to API enable common data canonical models across the enterprise and are happy to budget the costs of re-designing ?|
|Do you like us to assess business critical processes or interfaces to identify any oppurtunity for redesigning to improve it i.e to automate it or use machine learning API(S) to drive revenue? If yes then please provide us the reference document with details on what your pain points are and how you foresee the process should work in future?|
|Architecture||Does Organisation have System Definition Catalogue that describes functionality of each system and helps us to classify systems into Process, Data, User, Thing integration styles and whether it is external or internal and the future transformation roadmap for each IT system i.e will application move to cloud(If yes then please provide timeline)? Can you please attach a reference document ?||No.of bespoke systems I.E developed by Organisation internally?|
|No.of SAP and non-SAP external systems i.e.. outside Organisation network?|
|No. of internal SAP systems i.e. inside Organisation network?|
|No.of internal non-sap systems i.e.. outside Organisation network?|
|Architecture||Does Organisation want to just migrate EDI partners into CPI using EDI Messaging format or would like to take API first approach i.e. re-design EDI interfaces using API(S) to make partner and supplier on-boarding simpler in future?||How many EDI interfaces? How many partners?|
|API Enablement of EDI or EDI Migration|
|What are different types & messaging formats used for EDI communication?|
|Are we using SAP PO B2B Adapter for EDI or do we use any other tool?|
|What are different IDOC(s) types used? How many custom IDOC(S) are developed for SAP EDI?|
|Architecture||Does Organisation have Interface register? Can you please attach a reference document?||No.of high complex interfaces|
|No. of medium complex interfaces?|
|No. of high volume Interfaces?|
|No and list. of business critical interfaces and systems?|
|Architecture||Does Organisation have Interface register? Can you please attach a reference document? Can you also provide batch trigger data if possible?||No. of Synchronous Interfaces|
|No. of Asynchronous Interfaces|
|No. of batch trigger interfaces?|
|No. of real time interfaces?|
|Development||Can we have access to SAP PO system to answer these questions?||Adapter types used|
|No.of Interfaces for each adapter|
|No. of ICO(S)|
|Are ABAP mappings used? If yes, how many interfaces?|
|No. of ccBPM(S) used? If yes, how many interfaces?|
|Any custom adapter modules used? If yes, how many interfaces?|
|Are JAVA mappings used? If yes, how many interfaces?|
|What kind of look up(s) are used?|
|Testing||What are typical testing processes and cycles in Organisation?||Do we have existing sample test data for each interface in each environment?|
|Do we have any unit test and integration regression test scripts available for each interface?|
|Do we have end to end testing scripts available by process for interfaces i.e. testing that covers legacy processes as well?|
|Support||What is current monitoring framework for interfaces? Do you any future roadmap for monitoring framework?||Which tool are we using for monitoring interface failures?|
|What is current process for reprocessing message when interface fails?|
|Are we using alerting for all interfaces or only for business critical interfaces?|
|Do we have separate alerting process for business critical interfaces? If so, please specify.|
|How many error messages are raised per each day in live systems? Can you please provide details of interfaces and information on root cause of those errors i.e. data or interface bugs or environment issues etc.?|
|What types of error occur frequently in production systems that may impact business and errors that you may want to fix in new systems? If so, please provide reference documents|
“The only certainties in life are death, taxes and bugs in code.”
The biggest challenge in any integration project is not building but test preparation and execution. Testing eats up 60% of your project budget and hence I recommend you to evaluate and use the below tool developed by a well reputed mentor Michal Krawczyk and his team.
Useful Links for Migrating from SAP PI to PO
INT4 IFTT SAP PI from dual stack to single stack
This tool is built by a well reputed SAP mentor Daniel Graversen and provides following benefits :
Document development changes
Make testing so easy that it is done properly
Test what has been changed
Reduce the risk with Support Packs
Free time for developers and business from testing and documentation