Most B2B migrations don’t fail on the technical work. The mappings get converted. The AS2 channels get tested. The first 10 partners work, and you can start moving them to production. The real challenge comes after that.
You need to design a B2B solution that can scale to hundreds or thousands of partners, while still making it possible to add new partners in a consistent way.
Based on conversations with customers and what we have seen in real migration projects, here are 10 things we would strongly recommend you consider as part of the journey.
1. What you actually have and what is still active
Start by getting a complete and up-to-date list of partners, document types, directions and channels from the system itself, not from project documentation created five years ago.
Then check which partners and interfaces have been active during the last 12 months. In most landscapes, a significant number of these are no longer active.
If it is no longer used, do not migrate it.
Every partner or interface you can retire is one less thing to migrate, test and maintain.
2. Whether to use MAGs or message mappings
MIGs and MAGs are the better long-term design, but rebuilding your whole landscape with MAGs can turn a migration into a complete rewrite. Which means rebuilding everything, retesting everything and rediscovering every partner-specific exception along the way.
Reusing your existing message mappings can reduce both the effort and the migration timeline significantly.
Before deciding to rebuild everything, ask yourself one question: How many of your mappings have actually been added or changed during the last three years?
For most landscapes, the answer is surprisingly few.
A complete rebuild could mean redoing hundreds of message mappings that already work and may never need to change, just to make future modifications easier for the handful you will actually touch.
Integration Advisor also supports MIGs based on SAP PI B2B formats, which makes it possible to reuse existing structures instead of rebuilding everything from scratch.
We ran a project last year where we were able to reuse the existing message mappings. At that point, we could migrate one message in roughly four hours. Since then, we have added more automation and support for more use cases.
Choosing message mappings now does not mean you have to stick with them forever.
Message mappings and MAGs can live side by side. Converting a mapping into a MAG is also the kind of task where AI tooling is becoming increasingly useful, so the cost of moving later is more likely to decrease than increase.
A practical approach is to migrate using the mappings you already have, reuse existing structures where they make sense, introduce MAGs for new partners, and document the decision for each document type.
3. How you are going to test it
Decide how you are going to test before you migrate the first interface. Because the baseline needs to be captured while the old system still exists.
The most valuable test is real production traffic, comparing the output from the new solution with the output from the old one.
Use real production messages as your test baseline.
We recommend uploading real production IDoc and EDI messages to a tool such as Figaf and comparing the results automatically. That will reduce the effort required to build test cases and can significantly shorten the delivery timeline.
4. Which governance structure you need
Define your standards before the first partner is built.
Naming conventions. Identifiers. Approved agreement templates. What “done” means. Who can approve exceptions.
When you have 300 partners, quality does not come from relying on individual skills. It comes from making the right way of working the easiest way of working.
Make the right way of working the easy way of working.
A migration is one of the best opportunities you will get to set these standards, because you are already rebuilding the landscape.
This also includes deciding whether you use SAP Trading Partner Management V2, the B2B Integration Factory, or another approach. We still see different setups, but TPM V2 has improved significantly over the last year.
5. How to keep track of every B2B object
You need one central overview that shows what exists, which environment it is in, which version is running, and who changed it last.
These are questions you will be asked all the time:
- How many partners are complete?
- What is in test but not yet in production?
- Which certificates will expire during the project?
A spreadsheet will not scale with your B2B landscape.
A spreadsheet can work with 10 partners. It becomes much harder with 100 or 1,000, especially when the person maintaining the spreadsheet goes on vacation.
6. How transports will work and who controls them
Work this out before the project starts.
- Which objects can actually be transported between environments?
- Which ones have to be recreated manually?
- Which values should deliberately be different between environments, such as endpoints, certificates or control number ranges?
- Who is allowed to import into production?
Then calculate how much manual work is involved. Two hours of manual work multiplied by 200 partners is 400 hours. That is around 10 person-weeks of retyping information. And retyping is where errors happen.
B2B transport is more than moving a few iFlows.
B2B transport is a different setup from simply moving a few iFlows through Cloud Transport Management. There is much more content involved, and you need a clear approach for handling it.
7. What needs to happen on the trading partner’s side
Almost every migrated interface requires something from the trading partner. It could be a firewall change, a certificate exchange, a test cycle, or sometimes even an updated agreement. And these things take time.
Group partners based on how much work they need to do and use that when planning your migration waves.
Start talking to your trading partners earlier than you think you need to.
A technically finished integration can still sit waiting for six weeks because someone in the partner’s IT department has not completed their part.
8. How to structure a migration plan you can steer with
Group partners into waves and start with a few low-risk ones. Use them to prove the complete process end to end: Build. Test. Transport. Activate. Monitor. Only then start scaling.
Use a per-partner status that everyone understands in the same way.
Estimate partners by category instead of averaging a simple partner together with a heavily customized one. And make sure the dependencies you do not control are visible in the plan.
Also reserve capacity for business as usual. Otherwise, your migration project will slowly end up funding all the normal day-to-day work as well.
9. What B2B experience your migration partner has
Outsourcing the migration can be a perfectly good decision. But a consultant who is excellent at SAP integration is not automatically experienced in large B2B migrations.
B2B comes with a different set of problems: partner onboarding, certificates, agreements, testing, dependencies, transport and operating hundreds or thousands of individual partner configurations.
SAP integration experience and B2B experience are not the same thing.
The gap in experience rarely shows up as one obvious failure. It usually shows up as additional work and rework throughout the project.
Understand how your migration partner plans to run the project and how much experience they actually have with large B2B landscapes.
10. What to automate
Automation is one of the most important ways to speed up a B2B migration. It also makes consistency the easy option.
In Figaf, we have automated many of the tasks that would otherwise have to be done manually.
The more manual steps you remove, the easier it becomes to stay consistent and the faster you can move through the migration.
For example:
- Partner creation. Creating one partner manually can mean working through around 17 different screens. In Figaf, the information is entered once, which also makes it much easier to keep the setup consistent.
- Migration of Operation Mappings directly into iFlows linked to agreements.
- Automated testing for each agreement.
- Transport of B2B content, including MIGs, MAGs, iFlows and other objects required to make the complete setup work.
You can see an example of what the migration journey looks like in the video below.
Watch on YouTube SAP PI/PO to Integration Suite: B2B & TPM Migration Made Easy (Demo)
