Switching B2B providers.

Most platform teams do not go looking for a new B2B provider. The trigger arrives from somewhere else: a prospect needs a protocol or a region you cannot cover, a customer asks for visibility your provider does not expose, or onboarding a single trading partner turns into a two-week engineering task that your roadmap absorbs quietly and repeatedly.

The commercial version of the same problem is pricing that punishes the growth you are trying to build. If every new customer, partner or document volume tier costs you more than it earns, the infrastructure is working against the business model rather than under it.

There is also the case where nothing is broken. B2B service and pricing both move over several years, and an arrangement that fit the platform you had in 2020 may not fit the one you are selling now. Testing the market periodically is reasonable on its own merits.

This is the difference between a platform changing providers and an enterprise changing its own connections, and it governs every decision that follows. An enterprise migrating its own EDI has one set of trading partners, one internal deadline, and one group of people to keep informed. You have all of that multiplied by your customer base, and the deadline is not yours to set alone.

It means a cutover is not an internal project. It is exposure across every customer at once, on infrastructure they bought from you rather than from your provider. Your customers did not choose the provider underneath, they chose you, so any disruption lands against your name and your support queue.

Two consequences follow, and they shape the rest of this guide. Anything that cannot be done one customer at a time will eventually be done to all of them at once, so a provider you cannot onboard incrementally is a provider you cannot migrate to safely. And anything that requires your provider to act on your behalf becomes a queue you do not control, which is why the shape of the integration surface matters more here than it does for a single enterprise.

A provider change is rarely only a swap. It is the one moment when the line between what your team builds and what it merely maintains is open for redrawing, and platform teams usually discover the line has drifted.

The work that tends to sit on the wrong side of it is unglamorous and continuous: rotating certificates, working through partner onboarding mechanics, keeping up with protocol revisions, handling interconnect paperwork between networks, holding archives for retention periods nobody chose. None of it differentiates your product. All of it consumes engineers who could be working on something that does. Whatever falls below that line should arrive with the provider rather than stay in your backlog.

Above the line is the part that should not move at all. The workflows your customers use, the way B2B state appears in your product, the data model your features are built on: these are yours, and a provider change should leave them intact. If evaluating a move means contemplating a rebuild of product surface, the boundary was drawn in the wrong place, and that is worth knowing before you migrate rather than during.

Write the line down before you start evaluating. It is a more accurate description of what you are buying than any feature list, and it gives you a concrete test to put to each candidate: which side of this line does each responsibility land on, and who is accountable when it fails?

Pricing is the easiest thing to compare and the least likely to determine whether the migration succeeds. Four questions do more work.

First, what is the integration surface? Establish which operations you can perform in code rather than by raising a ticket: creating a trading partner, provisioning a protocol, checking whether a document arrived, pulling an audit trail. Every operation that is available only through a portal or a support request is an operation your platform cannot offer its own customers, and a step that will not scale when you onboard fifty of them in a quarter.

Second, what does the coverage actually include? Match the protocols, standards and regional requirements against your current traffic and against the deals you lost. Coverage gaps are the most common reason platforms move, and the second most common reason they move again eighteen months later.

Third, who carries the operational responsibility when a document fails? Establish what the provider monitors, what it tells you, how quickly, and through what channel your support team can actually use. A provider that resolves problems well but only tells you when you ask has moved the operational load onto your team rather than taking it on.

Fourth, can it be run multi-tenant? Separation between your customers, per-customer configuration, and reporting you can expose in your own product are either present in the model or they are something you will build and maintain yourself.

If the prior question of whether to build this capability at all is still open, the build versus buy analysis covers it, and the B2B layer page covers where the capability belongs in your architecture.

Build a complete picture of what you are actually running before you commit to a date. For each customer, that means the trading partners, the protocols and transports in use, the document types moving, the maps and transformations applied, and the identifiers each relationship depends on.

The inventory usually shrinks the job. Platforms that have been running B2B for several years typically find dormant relationships, partners who stopped trading, maps kept alive for a customer who left, and connections built for a pilot that never went anywhere. Retiring those is cheaper than migrating them, and the audit is the moment you have the attention to do it.

It also tells you the real shape of the migration. Customers are rarely uniform: a handful will carry most of the partner count, and the tail will each have two or three connections. That distribution, rather than the customer list, is what your wave plan should follow.

Move in waves, grouped by customer rather than by protocol or partner. A customer whose traffic is split across two providers mid-migration is a support conversation you will have repeatedly, so the unit that completes should be the unit your customer recognizes.

Start with a wave small enough to absorb a surprise and representative enough to be worth learning from. An internal account or a customer with a handful of straightforward partners will surface most of the process problems: how long provisioning takes, where your runbook is vague, which of your own systems make assumptions nobody documented.

Run old and new in parallel where the provider and the partner allow it, and keep the previous path available until the new one has carried real traffic through a full business cycle, including a month end. Rollback stops being theoretical the moment you decommission the old connection, so decide deliberately when that happens rather than letting it lapse.

Give every wave a documented test result and an explicit sign-off before the next one starts. On a multi-customer migration the sign-off is what prevents a single unresolved issue from propagating across the remaining waves.

In most migrations the trading partners on the other side change nothing. Their connection details, their protocols and their document formats stay as they are, which is why a well-run provider migration is close to invisible from outside.

Close to invisible is not the same as unannounced. Partners need to know a change is happening, when, and who to contact if something looks wrong on the day, and a partner who first learns of a migration from a failed document will escalate to your customer rather than to you.

Decide early who sends that communication. On a platform migration the partner relationship usually belongs to your customer, not to you, so the message tends to be more credible coming from them. That makes it your job to give your customer the notice, the timing and the contact route, early enough to send it themselves.

Authorization letters

Moving interconnects between networks requires written authorization, on company letterhead and signed, confirming the request comes from the organization entitled to make it. On a platform migration these are usually signed by your customer rather than by you, which puts them on someone else's calendar. Start collecting them before you need them.

Qualifiers and identifiers

Compile every qualifier and identifier being moved, per customer and per partner. This is the reference document that lets anyone on the project establish which relationships belong to which customer and which network each one sits behind. Without it, coordination across waves becomes guesswork at exactly the point where precision matters.

The cutover window

Pick a window with full support coverage on both sides, yours and the provider's. Avoid month end, quarter end, and any seasonal peak your customers trade through. If your customer base spans regions, remember that a quiet window for you may be the middle of a business day for the partners on the other side of their connections.

The provider change does not stop at the network boundary. Wherever B2B state appears inside your product, a document status, a partner list, an error your support team reads, a report a customer downloads, something behind it is about to be served by a different system.

Bring your engineers in early enough to test how files are actually received, routed and acted on, rather than confirming that they arrive. Document content can be identical while file naming, delivery cadence, acknowledgement timing or error semantics differ, and those are the details that break automated handling downstream rather than at the edge.

Brief support before the first wave, not after it. They will field the questions regardless of where the change originated, and a support team that can distinguish a migration symptom from an unrelated fault is the difference between one escalation and a pattern of them.

Check the notice period and the renewal terms on the agreement you are leaving, well ahead of the migration. Automatic extensions are common, and a renewal that triggers mid-migration turns a planned saving into a year of paying twice.

Establish what leaving costs in practice: exit or de-conversion fees, what happens to historical data and archives, how long you retain access after termination, and in what format. Archived documents tend to matter for compliance long after the connection they came from has been retired.

Negotiate for the growth you are planning rather than the volume you have. Pricing that scales cleanly as you add customers, partners and document volume is worth more to a platform than a lower entry rate, and kilocharacter rates, the standard billing unit in this market, are usually negotiable as volume rises.

Watch the first full business cycle closely, including a month end, because the failure modes that matter tend to be periodic rather than immediate. Documents that only move at period close will not have been exercised by a successful cutover day.

Measure against the reasons you moved. If the trigger was onboarding time, time the next few partners and compare. If it was operational load, count the tickets your team handled before and after. If it was coverage, confirm the deals that were previously blocked can now be served. A migration justified on a problem and then measured on uptime has not been evaluated.

Then write down the new baseline while the detail is still fresh. The next platform team to inherit this decision, possibly your own, will want to know what normal looked like.

Each of these organizations migrated to ECGrid, and each one is the example behind a stage above. Company details are withheld; the outcomes are as reported. They sit here at the end rather than up front because the guide itself is meant to hold up whichever provider you pick.

If you found this guide while weighing a migration, we hope it leaves you better prepared, whichever provider you choose next. If ECGrid is one of the options on your list, here is the honest version of what moving to us involves.

Most of the hesitation we hear comes from platform teams, and it is reasonable. If you embed B2B connectivity in something your own customers depend on, a migration is not an internal project. It is exposure across every customer at once, on a timeline you do not fully control. That is a case we have to earn rather than assume. What we have built for it is an API-first network: partner setup, document status and audit data are all reachable in code, so onboarding can run partner by partner at your pace instead of as a single cutover you have to survive. The phased approach described earlier in this guide is the one we run ourselves.

If you run EDI in-house rather than selling it onward, the same things matter for different reasons: seeing what actually moved and when, connectivity that covers the protocols your partners insist on rather than the ones that are convenient, and support that answers when a document does not arrive. Our self-service tools and responsive support model are meant to give you more control without trading away reliability. We work with companies of all sizes and across industries, and we are glad to be judged on the parts of this guide that are hardest to get right.

Complete the form and our team will follow up shortly. You can also reach us through our contact page.