Everyone selling SAP PI/PO migrations argues about the conversion step: how fast can you turn an ICO into an iFlow. That step matters, but it’s not where the project goes. When we break a migration down interface by interface, most of the hours sit around the conversion: working out what you have, testing that the new interface does what the old one did, documenting it, and getting it through QA into production.
That’s where Figaf Migration Edition does its work. Our experience shows a minimum 30% reduction in migration effort but in many cases much more. Here are the five places the time goes.
1. Knowing what you actually have
Before anything moves, somebody has to answer four questions.
- What do we have?
- What is still used?
- Where do we start?
- What will it cost?
The answers are rarely in one place. The only complete record is the running PI system, so teams spend weeks building a spreadsheet by hand and then plan on assumptions.
Figaf reads the landscape directly. You get an automatic inventory of interfaces and their dependencies, insight into the mappings, and an effort and complexity estimate per migration candidate. It also runs a usage analysis that flags interfaces nobody has called in a long time. The cheapest interface to migrate is the one you retire instead. One client told us that the migration assessment report alone saved them days.
2. The migration itself, to the right target pattern
Figaf migrates ICOs, receiver determinations and operation mappings into iFlows that run, and it reports what didn’t convert cleanly so the developer can fix those items. When another of our clients moved their B2B landscape, they described migrating the operation mappings as “almost instantaneous.”
The bigger decision is which pattern you migrate into. Copy a PI design faithfully and you get a PI design running on a new platform. Figaf can generate iFlows for SAP’s Pipeline Concept, with Partner Directory entries and routing XSLT. That’s SAP’s recommended pattern for asynchronous messaging, and its JMS queues give you one consistent way to handle retries across the landscape, so each interface doesn’t need its own improvised error handling.
3. Testing, where the schedule really goes
Industry estimates put testing at 60-65% of migration effort. Some of this can be automated. The cheap test is one message: send it through, see that it runs, call it done. That tests one path. It doesn’t tell you about every partner, every document type or every branch the interface actually sees.
Figaf collects a large set of real messages from the PI system, replays them against the new Integration Suite interface, and shows you the differences. You decide once which differences are acceptable, and that decision is recorded and reused. The result becomes an automated test case you can rerun after every change, not just at cutover. The evidence exports to Excel for the test manager or the auditor. On our per-interface model, testing is the biggest single saving. Sensitive production data stays protected, so outside testers can run the cases without seeing it.
4. Documentation nobody has
Most PI/PO landscapes have very little up-to-date documentation. That’s a big part of why the analysis in step 1 is expensive: nobody documented the interface last time. Figaf generates the documentation from the interface itself, including configuration, dependencies and where it sits in the landscape. Because it comes from the real configuration, you can regenerate it instead of maintaining it by hand.
5. Transport and configuration, the part everyone leaves out of the estimate
“Export the iFlow” sounds like two minutes. The iFlow is the easy part. What travels with it is harder: externalized parameters, per-environment endpoints, credentials, security material, and the script collection you only find out was missing after the import failed and the approval cycle has to start again.
Figaf shows you the dependencies before you transport. It applies the right configuration per environment and lets the approver sign off on the configuration and content, not just “the iFlow looks OK.” It also works on a combined dev and test tenant, which is a sensible setup for many landscapes below about 300 integrations. On our model this saves about four hours per interface on the way from dev through QA to production. Multiply that by your interface count.
What doesn’t get faster
Cutover. Switching traffic, disabling the PI side at the right moment, and coordinating with the business is experience, not tooling. On B2B, the partner’s side of certificates, firewall openings and test rounds runs on the partner’s calendar. We don’t claim to compress either one. What automation does is make sure your team is waiting on the partner, not the other way round.
What it looks like in practice
One client migrated 108 interfaces from SAP PI to SAP Cloud Integration with a two-person team, as part of their S/4HANA project, and finished on time. Another client migrated their B2B integrations in about two months (about 2 interfaces per working day) with no defects reported.
And you keep the tool afterwards. Every migration includes a year of Figaf DevOps after go-live, so the testing, transport and documentation you set up during the project keep working when the project team goes home.
The date that doesn’t move
Mainstream maintenance for SAP PI/PO ends on 31 December 2027. As I write this, that’s about 460 days away. Extended maintenance exists, but you pay it to stand still.
The migration itself usually isn’t what runs late. The decisions before it are: scope, target pattern, how you’ll test, who signs off. A large landscape that hasn’t started counting yet has less runway than it looks.
Where to start
Book a “no-strings-attached” conversation with Daniel. Bring your landscape, your deadline and whatever is worrying you about the migration. You’ll get an honest view of where the effort will be and what a sensible first step looks like, whether or not that step involves Figaf.
