You can try Figaf in your migration projects for free. Just start a free trial and you can get started with the tool right away. Figaf covers all the needs you have for your migration projects.
When it comes to migrating from SAP Process Integration/Process Orchestration (PI/PO) to SAP Integration Suite, a common dilemma that businesses face is whether to adopt a one-to-one migration strategy.
Understanding One-to-One Migration
In a one-to-one migration, the existing integration flows and configurations are moved as-is from SAP PI/PO to the SAP Integration Suite. This approach is quicker and less complex, since it largely involves replicating existing structures in the new environment. Developers can work with familiar content, bypassing the need to redesign or rebuild from scratch. This familiarity and direct transfer can significantly smoothen the migration process.
The reuse of existing mappings and content simplifies the process of migrating. No need to make structural changes to the content. There could be smaller changes like changing File to SFTP, modifying some UDFs or other changes but without majorly affecting the structure of the messages.
Challenges and Considerations
With migration tools like Figaf’s or SAP’s, it is possible to migrate many integrations fast without changes to the integrations. This reduces the effort for performing the migration.
Not everything can or should be migrated. This is where your architecture and goals come in.
It also matters what kind of team you have that can take the project. The more good developer hours you want to be spending on the project the more you can redevelop your integration. If the team and skills are lower it is probably a good idea to migrate 1:1 as much as possible.
A bigger challenge is also for the SAP Integration community if all SAP customers need to reimplement all their integrations before 2027/30 it will take much of the development effort in the community. There will not be time or skills to work on all the other tasks. So for the community automation of migrations makes sense.
What should be redeveloped?
Some of the cases where you should consider redesigning:
- Where the structure of the messages will need to be changed. Like moving from IDOC to Events or SOAP calls.
- That can be simplified using new processes.
- ccBPM or NW BPM that could be moved to a single technical process. You can reuse your mappings from this in some cases. But it will be a manual development
- Places where the architecture does not match
- Where changes in metrics around message volume size come in and the impact on licensing.
My take
I would migrate as much as possible in 1:1 because it would simplify the journey. There is likely going to be a good mixed approach where you will be migrating an ICO and then making modifications to make sure it does work for your upcoming cases. Then I would spend the time focusing on the areas where it would make a difference to build them so they are cloud ready.
