How Do You Migrate EDI Without Breaking Your Trading Partners? A Cutover Playbook

Most EDI migrations fail in the boring middle: not the new mapping, but the two weeks when nobody is sure which system owns an order. The fix is a parallel run with a clear owner per document, a hard cutover date per partner, and acknowledgment checks that prove the new path — not hope — carried the traffic.

I have watched the same pattern repeat. A team picks a new platform, rebuilds its maps, tests happily in a sandbox, then flips everything on a Friday. On Monday a retailer is missing 856 · Ship Notice / ASN documents, invoices are duplicating, and the old VAN mailbox is still receiving files nobody is reading. The technology worked. The handover did not.

What actually needs to move in an EDI migration?

Four things move, and only one of them is the map.

First, connectivity: AS2 certificates, SFTP keys, VAN interconnects, and the partner-facing identifiers (ISA/GS IDs) that tell a retailer who sent a file. Change an ID without telling the partner and your perfectly valid file lands in a stranger's mailbox.

Second, the maps themselves: an 850 · Purchase Order inbound is rarely just an 850. It carries that partner's quirks — a buyer who puts the ship-to in an unusual segment, a warehouse code hidden in a reference field. Those quirks live in old support tickets, not in the spec.

Third, acknowledgment ownership: who sends the 997 · Functional Acknowledgment, who watches for it, and who acts when it does not arrive. During a migration this is the first thing that falls between two systems.

Fourth, history. When a chargeback dispute arrives three months later asking what you actually sent on the 810 · Invoice, "we migrated" is not evidence. Export the old archive before access ends.

How long should you run old and new systems in parallel?

Long enough to see one full order cycle per partner — order, ship notice, invoice, acknowledgment — and no longer.

Pick one pilot partner, ideally a mid-volume one who answers emails. Route only that partner through the new system while everyone else stays on the old one. Compare outputs file by file: same purchase order in, same invoice out. Where they differ, decide which one is right; the old system is not automatically the reference, it sometimes carries a bug you have faithfully reproduced for years.

Then cut partners over in small batches, one batch per week. Never migrate a partner the week they run a promotion, a warehouse move, or their own system change. Two moving systems cannot debug each other.

What breaks most often during cutover?

Certificates and calendars.

AS2 and SFTP credentials expire on their own schedule, and migration projects love to collide with a renewal nobody owned. Inventory every certificate and key with its expiry date before you start, and renew anything that expires inside the migration window on the old system first.

The other silent breaker is scheduling. The old platform polled a mailbox every 15 minutes; the new one polls hourly. Nothing is "broken," but a retailer measuring your ASN timeliness just watched you get four times slower. Match the old cadence first. Optimise later, from a position of trust.

Duplicate documents are the third classic. Both systems send the same invoice during an overlap, the buyer pays once and short-pays the duplicate, and finance inherits the mess. The rule is absolute: for any given partner and document type, exactly one system is the sender of record on any given day. Write that matrix down — partner, document, owner, cutover date — and make it the single source of truth for the whole project.

How do you know the migration is actually done?

Not when the new system goes live. When the old system is quiet and you can prove it.

Watch the old mailbox for a full cycle after the last cutover. Zero inbound files, zero unacknowledged outbound files, zero partner emails asking where something went. Check that every partner's 997 · Functional Acknowledgment is arriving on the new path, not just that files leave.

Then decommission in writing: cancel the VAN mailbox, revoke the old certificates, and keep a read-only archive export with a note of where it lives. Migrations that never formally end keep charging you — in mailbox fees, in expiring certificates someone renews out of habit, and in the next engineer not knowing which system is real.

Frequently asked questions

Can you migrate EDI without telling your trading partners?
Sometimes, if your IDs, connectivity endpoint, and file formats stay identical. If any of those change, tell them early — partners need to update allowlists, certificates, and test windows, and a surprise change reads as an outage.

Should you rebuild maps from scratch or lift and shift them?
Lift the logic, rebuild the implementation. Carrying partner quirks forward is essential; carrying a decade of workarounds for a platform you just left is not.

What is the safest day to cut over?
Early in your partner's quiet part of the week, with your team present for the first full cycle — never on a Friday afternoon before a holiday weekend.

Migrating EDI is less a software project than a trust project, one partner at a time. That is the work we do every week at SignalEDI — AI-assisted mapping and flat monthly pricing, with healthcare sets in every plan.

— Chris, founder of SignalEDI