When you migrate from SAP PI/PO to SAP Integration Suite, you do the same five things over and over. You create test cases. You migrate the content. You test everything. You fix what is broken. Then you move it to production, and you do a lot of paperwork around all of it.
That is tedious work, and it is exactly the kind of work that should be automated. In the video below I show an experiment we have been running: Hermes agents on top of Figaf, doing the repetitive parts of a migration.
This is an experiment, and I want to be clear about that. We built it to see how we can improve the process and simplify the migration journey for users. We have no results to share yet, no time savings and no success rates. What we need next is real projects, so we can say something that actually holds up. Treat this as an early look at an idea, not a proven method.
Two worlds: B2B and A2A
Not all interfaces in a migration are the same, and the split matters for how you automate.
- B2B is the structured world. The structure is fixed and the rules are pretty clear. We already have full automation for this in Figaf, including our FAID (Figaf AI-driven) apps.
- A2A is the varied world. Formats and structures differ, and there are many ways to handle exceptions. This is where agents really come into play, and you can easily add your own customizations.
The setup
The setup is simple. The Figaf tool connects to both SAP PI/PO and Integration Suite, so you can see all the content and handle migrations from one place. We then plugged in a Hermes agent, so the agents can talk to Figaf directly: create test cases on the PI/PO side, work with Integration Suite, and handle the rest.
Hermes is just the setup we used, and it can work with all kinds of AI tokens. We have also tried SAP AI Core, if you would rather use your own SAP AI tokens.
One manager, several specialist agents
Instead of one big agent, we split the work into separate activities and gave each one its own agent:
- a manager that orchestrates everything
- an agent for analysis
- an agent for testing
- an agent that builds
- an agent that handles transports
- a naming expert that applies your naming conventions
- an agent for the manual actions and for checking things in Integration Suite
Splitting it up makes each piece easier to manage, and easier to improve.
Teach it like you would teach an employee
This is the part I find most interesting. When something fails, you do not just fix it once. You tell the agent what to do next time.
In one migration, the FTP host name was not filled in on the deployed scenario. So we told the agent: if you find the host name is empty when you deploy, go in, fix the external activity, and carry on. From then on it handled that case itself.
It works a lot like onboarding a new colleague. You see a problem, you explain the fix, and it gets fixed the same way every time. And like with a new colleague, you still need human oversight of the process.
Rolling it out in your own project
This is new, and it will not work perfectly for everything. We are still learning what works, and we want to gather more experience from real projects. If you try it, we would like to hear how it goes. Here is how I would approach it:
- Start from a template and work out how it behaves in your project.
- Migrate a few scenarios and watch where they fail.
- Improve the agents and fine-tune them to your structures and naming rules.
- Scale up. Once it works, migrate in batches of a couple of hundred ICOs at a time.
We can help you set this up, but it is not rocket science. If your team has worked with agents before, you will be able to run it yourself.
What it looks like in practice
In the video I show:
- The migration manager in Hermes. I tell it “migrate this ICO”, and it hands the work to the analysis agent and the naming expert, which applies your naming rules. Test cases are created, and the Integration Suite agent checks the result and fixes the problems that come up.
- A Kanban board in Hermes that shows the problems, who worked on each one last, and which ones need manual approval before import. You can use Jira or another tool instead if you prefer.
- Figaf itself, where the tickets and the transport request were created, and the migration dashboard shows which ICOs have been migrated and which have test cases.
Try it yourself
My recommendation:
- Sign up for Figaf and try the migration on your own environment.
- Connect Hermes, Grok or whichever agent setup you want to experiment with. Running it on your laptop is a good way to start, and it is pretty easy.
- Go through onboarding with Figaf to learn what is really possible.
If you are a consulting company, this is also a way to manage migrations at scale, and something you can offer your customers.
Work with us on real results
We would love to work with customers on this. To get results we can stand behind, we need real migration projects: your landscape, your naming rules, your exceptions. We can help you set up the agents and the process, share what we have learned, and learn from what you find.
If you are planning or running a PI/PO migration and want to try this on a part of it, book a meeting and let’s talk about running it on your project.
