— May 18, 2026 · 7 min read

EDI vendor lock-in: 5 tests to assess your ESB

The real cost of a proprietary ESB or EDI hub is not the subscription price, it is the cost of leaving. Five concrete tests to estimate that cost before signing, or to decide whether a migration is worth it.

Test 1: operational data portability

The question: can you export the full history of exchanged messages (audit log, raw payloads, ACKs, status events) in an open format (NDJSON, CSV, Parquet) without vendor intervention?

The assessment: ask for a demo export of 100 000 messages with the expected columns (ID, sender, receiver, reception timestamp, send timestamp, status, message type, payload size). The time to produce this export and the format quality are telling. Red flag: need a proprietary connector or a paid API with rate limit. Good: direct export via admin UI in minutes, documented open format.

Test 2: transformation mappings export

The question: can you extract the mapping rules (EDIFACT ↔ pivot JSON, UBL ↔ ERP) in a readable, reusable format on another engine?

The assessment: ask for the export of an ORDERS EDIFACT D.96A → canonical JSON mapping. Examine the format. Red flag: proprietary binary format (Boomi .mxp, MuleSoft .jar, IBM .map from WebSphere Transformation Extender), or proprietary XML tied to a specific runtime (IBM Sterling B2B Integrator .map). Good: standard XSLT, or readable TypeScript/Python code, or documented YAML/JSON format, or partially portable DataWeave. Stedi bets on JavaScript mappings, which is interesting for portability but still tied to their runtime.

Test 3: partner credentials portability

The question: can you export the full profile of each partner (X.509 certificates, AS2 IDs, AS4 endpoints, agreed SLA, technical contacts) in a machine-readable format?

The assessment: ask for the JSON or YAML export of 100 partner profiles. Red flag: PDF or Excel export requiring manual re-entry on target (seen several times!). Good: structured export covering every field including certificates (PEM or DER), with documented secrets management.

Test 4: monitoring and alerting schema

The question: are monitoring metrics (latency, success rate, throughput, error rate per partner) exposed in an open format (OpenTelemetry, Prometheus, OpenMetrics)? Are alerts defined as code (Terraform, Pulumi) or only via proprietary UI?

The assessment: ask for a Prometheus /metrics endpoint or an OpenTelemetry OTLP exporter. Red flag: metrics visible only in a proprietary UI with separate billing for export. Good: native OpenTelemetry exporting to any backend (Grafana, Datadog, New Relic). See our page on EDI metrics: SLO, error budgets, KPIs.

Test 5: contractual exit clauses

The question: what does the contract say about end of relationship — export cost, guaranteed data access time after termination, exit deliverables format, ownership of mappings written during the contract?

The assessment: ask Legal for the exit clause before signing. Red flag: "data remains accessible 30 days after termination for 50 000 EUR" or "mappings are vendor property" (seen at some classic enterprise ESBs). Good: free access 90 days, guaranteed open format, client-owned mappings. Some vendors (Stedi, B2Brouter, Storecove) explicitly market "no lock-in" and deliver; others prefer not to discuss it.

What to do concretely?

For a 2026 greenfield project, prefer code-first or explicitly portable solutions: Stedi (JavaScript-first), in-house code on Apache Camel or NiFi, Kafka Connect + ksqlDB. For migration from a legacy lock-in, plan the exit in two phases: (1) extract and re-document existing assets in a pivot format (often a 6-12 month effort for a large group), (2) migrate flow by flow to the new runtime.

The most common mistake: wanting to "migrate everything at once" without doing phase 1. The project derails at 40% completion when undocumented mappings, rules in custom scripts, special cases in operational config are discovered. Phase 1 is less glorious but it conditions the rest.

Conclusion: portability as the primary criterion

For an ESB or EDI hub, the "portability" criterion should weigh at least as much as "features" and "pricing" in an arbitration grid. Once signed, an EDI platform often stays 10-15 years in the company. The ability to leave it in 7 years at a reasonable cost is as important an asset as the ability to deploy it today at a reasonable cost.