Automate SAP PI/PO Migration
- 1. Webinar 6 September 2019 Automation of SAP PI migration © Figaf 2019
- 2. ● Why you need to migrate ● Challenges with migrations ● Current status ● Our migration tool ● Feedback Agenda
- 3. 7.1x, 7.3x,7.4 support until 2020 7.5 Support until 2024 7.6/8 from 2022 - 2030 SAP PI Roadmap
- 4. If Dual Stack: Upgrade ● Just upgrade Stack split ● Delete ABAP stack Migration ● New Install, copy objects Options for upgrading If Single Stack Upgrade ● Upgrade system (Have good test coverage) Migration ● New Install, Copy objects
- 5. My collection of migration resources Steps for the process https://figaf.com/sap-pi-po-migration/ Including our free tool to give an overview of migration efforts Previous integrations
- 6. • ⅓ of are not on 7.5 yet • Systems should be keep updated • Need to process it in time • Be ready for an S4 upgrade and freeze periods Many organisations need to migrate
- 7. Plan releases of interfaces • Create test data • Move artifacts to new landscape • Configure channels • Test • Transport in landscape Golive Steps for a migration
- 8. ● Manage the process and ensure you have control over all elements ● Speed up the migration and lower the cost ● Understand the current project ● Clean up, do not get unused components moved ● Project Risk and predictability ● New way to develop new things Why an automated tool
- 9. ● Manage the process ● Configuration in on go ● Repository changes ● Handle testing of interfaces ● Understand the landscape Difference between SAP migration tool
- 11. I had hoped that we was able to show a live demo of a migration We have made a lot of progress over last two weeks In the development we learned about some challenges we needed to address Now we have option to get feedback on out ideas. Live demo
- 12. How it will work
- 13. Landscape for migration D1 Q1 P1 D2 Q2 P2 Transport 2 Old system New systemTransport 1
- 14. All migration or development takes places in releases. After adding the ICO/iflow to release it will be added to a ticket. This way it will be possible to ensure a good process for all interfaces Two transport flows 1. From old development to new development 2. From new development to new Production Each interface will have a number of steps Releases
- 17. ● In Preparation (only in migration) ○ Test data collected, ensure it can be run successfully in old landscape ○ Transport to new landscape ● In Development ○ Make changes in development objects ○ Prepare and review transport configuration ○ Prepare and review transport ● In Transport ○ Import to QA ○ Test imported objects on QA ○ Approve import on QA, switch back to development if any issues ○ Import to production ○ Approve on production, switch back to development if any issues ● In Production ○ Health check is successful Phases
- 18. New Transport in Figaf On development 1. Update/synchronize objects 2. Run test cases on dev 3. Create Global Configuration 4. Create transport 5. Do Validation CPILint or PIlint 6. Approve prepared Transport On other systems(QA,Prod) 1. External Import(via CTS+) 2. Import and apply configuration 3. Run test cases 4. Approve Transport a. A Reject you need to start over
- 19. It will be possible select one or more interfaces and start the process to next phase. Or check the status of the interfaces that requires manual configuration. It will then link to the places you need to configure manually like channels, if values cannot be copied. Red marker will show some information + link to edit that function Move to next phase
- 20. ● Export the objects in each release to a file transport one for each SWCV ○ Export only used objects ○ If objects is on new system do not export it ● Import files on new system using file import ● On new system transport using Figaf and File Exports automatic Migration of repository
- 21. ● Channels Copied with Figaf tool ○ Fetch configuration in full landscape, if old release it should be possible to get password ● ICO ○ Can be copied directly, channels migrated ○ Then with the webservice converted to Iflows (Webservice) ● Dual stack (If requested) ○ Copy using SAP migration tool ○ Or create it our self ○ Then converted to Iflow ● Transport via Directory API in Figaf tool Migration of directory
- 22. If there are Seeburger Message Mappings it is possible to upgrade them to B2B Add-on mappings also able to convert the mappings. Conversion of module from Seeburger to B2B Module Should happened on new development system. Can probably be integrated more into the process. One click conversion Seeburger conversion
- 23. This will require more information and customer requirements ● Conversion from Seeburger Adapter(AS2, SFTP) to SAP adapter and other adapters with XSLT transformations ● Conversion from Seeburger 997 to EDI Seperator ● Dual stack migration ● Renaming of objects ● Disable channels in old system once live Only Sender channels with scheduling ● Other custom migrations Extra options
- 24. Only pay for the interfaces you move with the tool Depending on if you have the Figaf license Price
- 25. Beta release in 2 week 1 release: 4 weeks Timeline
- 26. https://figaf.com/IRT Next step Try Figaf IRT on your own Free trial for testing