How we can automate the Migrations with Figaf IRT testing tool. Migration is one of the big tasks on any SAP PI/PO project. There is a lot of manual work that needs to be performed to make it happen. That is what we will help automate. Video replay is at https://youtu.be/Q-E6d7hQV2k Blog is at https://figaf.com/automatic-sap-pi-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

10. Lab preview
Current status

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

15. Release UI Concept

16. Configuration of channels

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