This blog I would like to share my experience how we can safely move our SAP PI (dual stack) system to SAP PO (Single stack). This SAP PI Migration step by step guide will help to smoothly transition from dual to single stack.
If you would like to read what is SAP PO (Process Orchestration) then refer to this blog.
The first step for any migration is to have a strategy in mind about how we are going to migrate and sustain with the running projects. This plan should help to visualize the step by step process of build new temporary systems, transport path, code retrofitting, Testing phase, Cut-over and demise plan.
This blog I would like to cover very high-level SAP PI migration strategy plan.
End of this blog, I will touch base some of the key technical challenges you might face during the migration and need to plan for it.
Assumptions for this strategy:
- We have DEV, QA & PROD system in our landscape.
- All systems are on SAP PI Dual Stack.
- Transport path is established between these systems. (Two-way)
- One SLD for DEV, QA & PROD.
Here is the summary of SAP PI Migration Strategy Steps:
- Create NEW sandbox for retrofitting the interface code.
- Establish transport path from PROD to SANDBOX.
- Copy ESR objects directly from PROD to SANDBOX.
- Code Retrofitting from PROD to SANDBOX.
- Build 3 new instances for PI Single Stack – DEV, QA & PROD.
- Establish transport path from SANDBOX -> DEV -> QA -> PROD
- Go-live faster with hardware first and few interfaces.
- Stop new Development in PI Dual Stack and continue in PO Single Stack.
- Finish all the code retrofitting from Dual Stack to Single Stack
- Demise the Dual Stack Landscape.
System Naming Convention:
- Dual Stack – SAP PI 7.3
- PID – DEV
- PIQ – Quality
- PIP – PROD
- Single Stack – SAP PO 7.5
- POS – Sandbox –
- POD – DEV
- POQ – Quality
- POP – PROD
SAP PI Migration Steps:
Let’s move to the actual steps for migrating interfaces from SAP PI dual stack to PO single stack.
Step 1: Create NEW sandbox instance for retrofitting the interface code
First we need to build a new SANDBOX instance with SAP PO Single stack with the required components like AEX, BPM, BRM, B2B Add-on Components and REST. Include the required 3rd party components and get it installed in the SANDBOX system.
Get the SANDBOX components equal to PROD Dual Stack system components and plus the new components available in SAP PO.
Step 2: Establish transport path from PROD to SANDBOX
Once the SANDBOX Single Stack is created and installed with required components. Next step is to establish the transport path from PIP to POS (See the naming convention above)
This path will allow to transport code from PIP to POS using the SAP Directory migration tool.
Read more about PI Directory migration tool from here.
Step 3: Copy ESR objects directly from PROD to SANDBOX.
The good thing about this migration is that we can directly transport the ESR objects from Dual stack to Single stack. Obviously, the ccBPM will not copied as it is not supported by SAP PO Single stack.
We need to recreate the ccBPM to NW BPM using the NWDS Process Components and configure it.
For now, the Service Interface, Mappings, External Definitions and rest of the component of Software component will be copied from Dual Stack to Single Stack. This is awesome! Save tons of effort.
Step 4: Code Retrofitting from PROD to SANDBOX.
By this time we have:
- POS (Single Stack) with required components
- Transport path linked between PIP & POS
- ESR objects in POS
It’s now time to have the real fun of migration. With the POS system ready with Single stack we can start migrating the interface from PIP to POS using the Directory content migration tool.
We need to recreate the NW BPM from scratch and reconfigure it in POS.
The best approach is to recreate everything from scratch in POS and keep it clean in the new environment.
Remember, we just need to pick the limited interface first and migrate it till PROD. Agile method deployment!
Step 5: Build 3 new instances for PI Single Stack – DEV, QA & PROD.
Step 6: Establish transport path from SANDBOX -> DEV -> QA -> PROD
Step 7: Go-live faster with hardware first and few interfaces.
I have grouped all the 3 steps into one which make sense as the next steps is to build 3 new environments as we build the SANDBOX. Then linkup the 3 systems transport path and move the developed interface from Sanbox to PROD.
Testing: Well we might need to retest entire interface just to make sure no compatibility issue during the migration. So it is best practise to perform end to end testing including the user and partner.
Agile Methodology: Using this agile approach, we will define the few interfaces that cover most of the components in SAP PO and then deploy it faster in PROD environment. It is better to have dual landscape for some period of time during the migration which can help to rollback the code if it does not work in new environment.
Step 8: Stop new Development in PI Dual Stack and continue in PO Single Stack
Once the complete PO environment is live with some interfaces. It is the time to stop the new development in PID, so that the code retrofitting can be completed within the defined time.
All the new development should be happening in POD hereafter.
Step 9: Finish all the code retrofitting from Dual Stack to Single Stack
Once all the code migration is completed we need to stop the linkage between the POS and PIP. This is a very critical time where no new code is migrated and new code is developed.
During this cut-over, all the interface is synced between the PIP and POP and exact the same. You can define the time when this cut-over will happen so that the PIP system can be stopped.
Step 10: Demise the Dual Stack Landscape
Final step is to demise the POS, PID, PIQ and PIP. The cutover plan should cover which interface channel should be stopped and started in new PI instance. The connection with internal & external system has to be taken care too.
This step the PI migration is completed and new landscape is ready!
- ccBPM has to be redeveloped in NW BPM.
- Seeburger EDI structure is not same as B2B Add-on EDI structure.
- All configuration must be ICO based.
- Redesign the Directory scenario.
- Java 1.6 vs Java 1.8 code compatibility for custom code.
- IDOC and HTTP adapter move to IDOC_AAE and HTTP_AAE
- Alerts has to be redefined.
There are still other topics like gateway, firewall, internal connections which is beyond the scope of this strategy, but this SAP PI migration guide can help you visualise the migration.
Hope you will find it useful for your next migration project. Drop me line if you like to continue the discussion on this topic.