Every S/4HANA program has a work stream that starts looking small on the plan and does not stay small. It is not data migration, which everyone expects to be painful and budgeted accordingly. It is the interface.
When you change the ERP release, you do not change one connection. You reopen every point at which your systems talk to somebody else's – which for most manufacturers and distributors means the electronic data interchange layer that carries purchase orders, order confirmations, dispatch advices, and invoices to and from every trading partner you have. SAP EDI integration is rarely the headline item on a migration program. It is frequently the one that determines whether the cutover date holds.
The reason is arithmetic, not difficult. A single interface is a manageable piece of work. Your interface count is not one.
Three things happen at once, and the third is the one that surprises people.
Every interface must be validated. Not necessarily rebuilt – but each one must be tested against the new system's behavior, and "we did not change that one" is a hypothesis until it has been through a test cycle.
Some interfaces need to be rebuilt. Custom development that reached into the old system tables, or logic that depended on a structure that changed, does not survive the move intact.
Your trading partners do not care. This is the third thing. A partner has no interest in your migration program. They will not pause their document flow; they will not accept a degraded connection for a quarter, and in many cases, they will not make themselves available for retesting your schedule. The migration is your project. The service level is their expectation.
That combination is what turns an interface work stream into a critical path. And it usually surfaces late, because the interface inventory is often the last artifact anyone produces – well after the budget was set.
Worth being plain about this because the terminology gets used loosely in vendor material.
An IDoc – intermediate document – is SAP's structured format for moving business documents in and out of the system. It is an internal transport format, not an external standard. Your trading partners do not send IDocs. They send X12, EDIFACT, flat files, CSV, or increasingly a JSON payload over an API, in whatever version and with whatever partner-specific quirks their own implementation guide specifies.
Something must sit between those two facts. That something is what "IDoc middleware" refers to: the layer that translates between the ERP's internal document format and the many external formats your partners actually use, handles the acknowledgements and error conditions in both directions, and gives someone visibility when a document does not arrive.
The important consequence is that this layer's job is not going away. Whatever else changes in the ERP program, you will still need translation between one internal format and dozens of external ones, and someone will still need to see it when a partner's invoice fails validation at 2am.
Every organization ends up in one of these three, sometimes in more than one simultaneously.
Coherent, supported, and single vendor. The trade-off is usually who can operate it: the skills required tend to sit with SAP specialists, which means every partner change becomes a request into the SAP team's backlog, competing with functional work. Technology is not a constraint. The queue in front of the work is.
Fast for the first three partners and progressively less fast after that. Every connection is bespoke, nothing is reusable, and the knowledge lives with whoever built it. The failure mode is well known and rarely priced: an undocumented estate that nobody wants to touch, which becomes the reason the next migration is deferred.
The ERP handles the business process; an integration platform handles the translation, routing, monitoring, and partner-specific handling. The advantages are reusing across partners and the ability to change a partner mapping without touching the ERP. The trade-off is a platform to own, a second system in the landscape, and a real evaluation to run rather than a default to accept.
No option here is free, and none is universally correct. A ten-partner estate with stable specifications is a different problem from a two-hundred-partner estate with retail customers who revise requirements annually. Any vendor – including us – who tells you the third option is always right describing their product line, not your landscape.
Five questions that produce different answers from different vendors, which is the point.
Does the integration layer touch the ERP, or sit beside it? If the migration plan starts expanding into SAP itself, stop and ask why. Replacing the translation layer should not mean touching either endpoint.
Who can change partner mapping? Specifically: a business process owner, an integration team, or a ticket to the vendor? This determines your change of latency permanently, not just during the program.
How does it handle the formats that are not IDoc and not X12? The awkward ones. The partner-specific flat file. The legacy fixed-width extract. The API that one customer insisted on. The estate is defined by its exceptions.
What does a failed document look like to a human? Can an operations person see which document, which partner, which field, and what to do – without a log file or a support ticket?
Can it run both paths during cutover? The ability to run legacy and new integration in parallel through at least one full business cycle – month-end, quarter-end, and your seasonal peak – is what converts a big-bang risk into a scheduling problem.
The Lobster Data Platform is a dedicated integration layer of the third kind. Electronic data interchange in its common formats, SAP IDocs, flat files, and APIs is handled in one environment – including the formats arriving from partners who will never change how they send them – with mapping and monitoring built for operations users rather than for specialists. The ERP stays where it is. When a partner changes a specification, the change happens in the integration layer, by the team closest to that partner.
Lobster is a European-proven integration platform now delivered in North America by Bosch Mobility Platform & Solutions – with a Bosch-operated cloud footprint in the U.S. AWS region, Level 1 and Level 2 support staffed on this continent, and a dedicated North American professional services team. Cloud or on-premises deployment is both supported. For an S/4HANA program running on a North American cutover calendar, support hours in your own time zone during hyper care is not a minor consideration.
IMTS 2026 runs September 14–19 at McCormick Place in Chicago. If an ERP program is on your 2027 plan, the most useful thing to bring is your interface inventory – every partner, every document type, every format, every failure from the last twelve months. Vendor conversations get more concrete when both sides are looking at a real landscape instead of a capability list.