This post is part of a blog series that attempts to cover majority of your migration to SAP Integration Suite as a topic.
To see the index and first post in this series, you can go here.
You can use Figaf for free in your migration projects. Just sign up for the Free Migration Edition of the Figaf DevOps Suite. Then you can easily get started with using the tool. 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 exiting 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 affect the structure of the messages.
Challenges and Considerations
With migration tools like Figaf’s or SAP it is possible to migrate a many integrations fast without changes to the integrations. This reduces the effort for performing the migration.
It is not everything that can be or should be migrated. This is where you architecture and goals comes in.
It does make sense what kind of team you have that can take the project. The more good developers hours you want to be spending on the project the more you can redevelop your integration. If the team and skills is 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 make 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 move from IDOC to Events or SOAP calls.
- That can be simplified using new processes.
- ccBPM or NW BPM that could be move 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 metric 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.