Migrating an EDI Trading Partner From VAN to AS2

You've probably got the email already: a partner's EDI team announcing they're sunsetting VAN connectivity for direct trading partners and want you on AS2 within 60 to 90 days. Or maybe it's the invoice that finally pushed you over the edge, per-kilocharacter VAN fees that don't shrink no matter how much you optimize message size. Either way, an EDI VAN to AS2 migration is one of those projects every EDI manager eventually runs, and getting it wrong means duplicate orders, missed ASNs, or a very unhappy trading partner on day one of cutover.

Why partners push for this migration

Partners push AS2 because it's a direct, real-time protocol with built-in delivery confirmation, and it cuts out the VAN's per-transaction fees entirely. AS2 reduces the cost of transactions compared to expensive VANs while extending EDI to partners who don't want to pay for VAN infrastructure. That said, don't expect to drop your VAN entirely. Major retailers like Walmart, Amazon, and Costco require AS2, but most businesses serving those same retailers still ultimately need both AS2 for retailer compliance and a VAN for partners on different protocols, plus monitoring and backup connectivity. This migration is almost never "replace the VAN." It's "move this one partner off the VAN and onto AS2, partner by partner."

What you need before starting

Before you touch any configuration screen, gather four things: the partner's current VAN mailbox ID and qualifier, their AS2 companion guide (every serious trading partner publishes one), a working AS2 station, and a confirmed change window with a named contact on the partner's EDI or B2B integration team. Skip any of these and you'll be troubleshooting blind on go-live day.

On the software side, you'll need to deploy a software application that can send and receive AS2 messages, and since it's exchanging EDI data, it must support a range of security features suited for business processes, not just basic file transfer. Cleo Integration Cloud, IBM Sterling B2B Integrator, and open-source OpenAS2 all fit this role, as do managed AS2 gateways from providers like Aayu Technologies. If you're running a TMS with native carrier connectivity, like Cargoson, MercuryGate, Descartes, or Transporeon, you may not need to build any of this at all for transport-side partners. Those platforms handle the connection layer themselves, which is worth knowing before you sink two weeks into standing up an AS2 station for a single carrier relationship.

Step-by-step AS2 trading partner setup: the actual migration

Here's the sequence that works, in order. Don't skip steps to save time, especially the parallel testing step, which is where most of the real problems surface.

1. Pull the partner's AS2 requirements from their companion guide. You need their AS2 ID, AS2 URL, preferred encryption algorithm (3DES, AES128, AES192, or AES256 are common), MDN type (synchronous or asynchronous), and whether they require signed messages. Every AS2-capable partner or VAN publishes this; if they don't, ask their EDI contact directly.
2. Generate your AS2 identifier and X.509 certificate, then exchange details with the partner. As JSCAPE describes it, once you've deployed your AS2 solution, the next step is exchanging AS2 connection details with your trading partner so both sides can interconnect their AS2 solutions. This means sending your AS2 ID, URL, port, and public certificate, and receiving the same from them.
3. Configure inbound and outbound AS2 connections in your station. Map the AS2-From and AS2-To headers exactly as the partner specified, including case. Unlike SFTP, AS2 authentication runs on certificates, not usernames and passwords, so a single mistyped header value breaks the connection in both directions. One vendor's documentation is blunt about this: a single wrong character in either AS2 ID breaks both directions of communication.
4. Allowlist the partner's AS2 IPs on your firewall, and confirm they've done the same for you. This step gets skipped constantly and causes the most confusing failures, because the failure looks like nothing happened at all. A send that times out with no HTTP status and no MDN at all almost always means traffic isn't reaching the AS2 server, which points straight at an IP allowlist or firewall issue rather than anything in your AS2 configuration.
5. Send a test document over AS2 while the VAN connection stays live. An 850 purchase order or 856 ASN both work well as test payloads. You're looking for two confirmations: a positive MDN, and a valid 997 or 999 functional acknowledgment. As Aayu Technologies puts it, a complete EDI transaction requires both a successful AS2 transmission confirmed by a positive MDN receipt and a functional acknowledgment confirming the business document itself was accepted.
6. Run a full parallel period with both channels active. Don't cut the VAN after one clean test. Run at least one complete transaction cycle, ideally covering every document type you exchange with that partner, purchase orders, ASNs, invoices, so mapping or envelope differences surface before they hit production traffic exclusively.
7. Cut production traffic over to AS2, update the partner profile in your EDI system, and decommission the VAN mailbox for that partner only. Not the whole VAN account, just that one partner's routing.

How you know it worked

Success looks like positive MDNs on every single transmission, matching MIC values between what you sent and what the MDN confirms, clean 997/999 acknowledgments, and zero documents landing in the old VAN mailbox after cutover. The MIC check matters more than people think. According to Orderful's documentation, the MDN includes the MIC of the original message, which the sender can use as a guarantee that the recipient is processing the same content that was sent. If your MIC doesn't match what the partner's MDN reports, something got altered in transit or your hashing algorithm doesn't match theirs, and that's a signal to dig in before declaring victory.

Failure mode: certificate mismatch causing negative MDNs

This is the failure you'll hit most often at go-live, and it's almost always fixable in minutes once you know where to look. A negative MDN citing decryption failure or signature verification failure means your certificates are out of sync somewhere.

Troubleshooting guides consistently break AS2 failures into the same categories. Most AS2 EDI errors fall into four buckets: certificate problems, network and HTTP errors, MDN configuration mismatches, and MIC mismatches, and troubleshooting means identifying which layer failed before applying the standard fix for that category. For certificate issues specifically, the fastest diagnostic is comparing serial numbers. Orderful's own troubleshooting docs recommend that you compare the serial number your platform shows for the certificate to the one your AS2 software or partner references, since negative MDNs and AS2 software logs often print the serial, to quickly confirm whether the correct certificate is uploaded. If you're migrating a Walmart connection specifically, the same logic applies to RetailLink. Aayu's Walmart-focused guide recommends you compare the AS2 identifiers on both Walmart RetailLink and your AS2 provider configurations and fix any mismatches, since certificate misconfigurations can result in decryption failures or signature verification failures. Nine times out of ten, the fix is re-uploading the current certificate on whichever side is stale, usually because someone rotated a certificate months ago and the partner never got the update.

Timeline and rollback plan

Set expectations early with your team and the partner. With proper planning and support, EDI VAN migration typically takes two to six weeks, depending on trading partner count, document complexity, and whether migrations happen in phases, and white-glove services can compress that further. Don't delete the old VAN mailbox on cutover day. Keep it active, unused but reachable, for at least one billing cycle in case the partner needs to fail back or a document gets misrouted during the transition. This costs you one more invoice cycle of VAN fees for that mailbox; it's worth it against the alternative of a lost purchase order.

The hybrid model isn't a stopgap, it's the standard end state for most EDI managers. You'll run direct AS2 for your highest-volume, most demanding partners and keep the VAN in place for the long tail, plus archiving and compliance needs the VAN handles better than a point-to-point connection ever will.

When to skip building this yourself

If you're managing dozens of trading partner or carrier connections, standing up and maintaining individual AS2 stations, rotating certificates, and troubleshooting MDN failures partner-by-partner stops making financial sense fairly quickly. This is exactly the gap that platforms like Cargoson, MercuryGate, Descartes, and Alpega fill for shippers on the transport side, abstracting the AS2/EDI connection layer so you're not managing certificates for every carrier individually. For everything else, weigh build-it-yourself against a managed AS2 gateway or full-service VAN before you commit engineering time to a protocol that, for most partners, you'll only ever touch during onboarding and certificate renewals.

Next step: pick one lower-risk partner, ideally not your highest-volume retailer relationship, and run this migration end to end before you touch anything mission-critical. You'll learn more from one clean cutover than from any amount of documentation.