Lesson 6 of 6
Migrating partners from legacy EDI
9 min
Listen to this lesson
Moving EDI is different from moving an internal interface. You control both ends of an S/4HANA-to-warehouse interface; with EDI the other end belongs to a customer or supplier who has their own release calendar, their own certificates and very little interest in your platform project. A migration plan is mostly a partner plan.
Contoso's starting point
Contoso's Process Orchestration system XP1 runs 64 integrated configurations. Its Migration Assessment found 31 ready to migrate, 21 needing adjustment, 12 needing evaluation, and 7 with no traffic in 12 months. The 11 EDI interfaces for six partners are a subset Theo treats as one workstream, because they share the B2B add-on objects (AS2 adapter, EDI separator, X12 converter modules) and they all need partner coordination. Nothing moves until hypercare after the S/4HANA go-live is over: changing middleware and ERP in the same weekend would make every EDI failure ambiguous.
Three migration approaches
SAP's migration guide for Process Orchestration describes three approaches for B2B interfaces, and hybrids are allowed.
| Approach | When SAP suggests it | What Contoso would do |
|---|---|---|
| Migrate to Cloud Integration only | Messages that rarely change, migrated 1:1; can be lifted into TPM later in a phased approach | Lakeside's SFTP flows: one stable partner, so no TPM agreement; its 850 is rebuilt on SAP's EDI integration templates with an Integration Advisor MAG rather than copied 1:1 |
| Migrate to TPM with Integration Advisor | Frequent changes, new messages, more B2B libraries, partner onboardings planned | The fleet customer template: Great Lakes and the four aftermarket customers, plus future customers |
| Migrate to TPM without full use of Integration Advisor | TPM wanted, but existing mappings reused with partial Integration Advisor use | Reuse PO mappings via ProcessDirect while MAGs are built |
Known limitations to plan around
- No direct import of partner master data. There is no direct import of PO partner profiles or of TPM objects like UDFs, so profiles and agreements are recreated in TPM. That is also the moment to clean up identifiers and contacts.
- Different EDI XML formats. The EDI XSDs in Cloud Integration differ from PO's, so a migrated PO mapping needs a transformation step before it, for example an XSLT that converts Cloud Integration's X12 XML into PO's structure. Newer EDI splitter and converter versions can also use the same XSDs as PO for X12 and VDA, which reduces this work.
- EDI separator scenarios. Interfaces with sender or receiver channels that use the EDI separator can't be migrated directly by the tooling and are rebuilt.
- Protocols. SAP's migration guide listed OFTP2 and RNIF as unsupported. Since 15 March 2026 SAP Integration Suite has an OFTP adapter (OFTP2) for the Edge Integration Cell runtime only; there is still no OFTP2 adapter on the cloud runtime and no RNIF adapter. Check the What's New and the SAP Road Map Explorer for changes. Contoso has neither, but automotive suppliers often use OFTP2, so ask before you promise.
Waves, cutover and control numbers
Theo plans waves by partner, not by message type, because the partner switches endpoints and certificates once for all its documents. Each wave has the same shape: build in CMC_DEV and test in CMC_TEST, connectivity and certificate exchange, partner test exchange with test-flagged interchanges, a cutover date agreed with the partner, a watch period and then decommissioning of the PO objects.
Two cutover details cause most incidents. First, control numbers: Great Lakes checks that Contoso's ISA13 interchange control numbers do not repeat. If the TPM number range for outbound 855s, 856s and 810s starts at 1 while PO had reached 4511, Great Lakes may reject the first production interchanges as duplicates. Set the number range's next value above the last PO value on cutover day. Second, in-flight documents: an order received by PO on Friday may be confirmed by S/4HANA on Monday. Decide which platform sends the 855 for documents in flight, and route the S/4HANA IDoc port or logical system for that partner accordingly.
- T-10 daysCertificates exchangedNadia's team sends Contoso's new public certificate; Great Lakes' certificate uploaded to the profile.
- T-5 daysTest exchange doneTest-flagged 850, 855, 856 and 810 completed in the test tenant; 997s reconciled.
- T-1 dayNumbers alignedOutbound number ranges set above the last PO ISA13 values; in-flight orders listed.
- T 0SwitchGreat Lakes points AS2 to the Integration Suite URL; Contoso switches its S/4HANA outbound port for the partner.
- T+1 to T+10Watch periodDaily volume and acknowledgments compared with PO history; PO channels stopped but kept.
- T+30DecommissionPO objects for the partner deleted after the watch period and sign-off.
What would you do?
On Great Lakes' cutover day, the first three 855s from Integration Suite are rejected by Great Lakes with "duplicate interchange". The 850s and 997s are fine. What is the most likely cause?
- Migrate B2B by partner wave after hypercare; partners switch endpoints and certificates once for all their documents.
- SAP describes three approaches: Cloud Integration only, TPM with Integration Advisor, or TPM with partial Integration Advisor use.
- Plan for no direct import of partner profiles, different EDI XSDs, EDI separator rebuilds, RNIF (unsupported) and OFTP2 (Edge Integration Cell only).
- Continue outbound control numbers above the last PO values and decide in advance who handles in-flight documents.
Check your understanding · not graded
Lesson check
1. Which partner is the best pilot for Contoso's first B2B wave?
2. Why can't a migrated PO EDI mapping always run unchanged in Cloud Integration?
3. What must Contoso do with outbound interchange control numbers at partner cutover?
4. According to SAP's migration guide, which protocol was not supported in Cloud Integration?