EDI Go-Live Strategy: Big-Bang, Dual-Run, or Phased?

An EDI cutover decision, transitioning from one EDI solution to another, is not a project management preference. Most practitioner guidance treats it as one: walk through the pros and cons of big-bang versus phased, weigh the tradeoffs, pick what fits your timeline. That framing is understandable, and it is almost entirely wrong for EDI. 

A generic ERP cutover is consequential. An EDI cutover is consequential and live. The moment your new system goes into production, it starts exchanging documents with retailers who have active scorecards, hard must-arrive-by-date (MABD) windows, and compliance penalty programs that issue chargebacks automatically.  

For example, Walmart's On-Time In-Full (OTIF) program holds suppliers to a 98% threshold for collect suppliers; missing it triggers a 3% cost-of-goods-sold penalty billed as an invoice. Amazon's Advance Ship Notice (ASN) chargeback structure compounds across missed transactions. These are not theoretical consequences you can clean up after the fact. A bad cutover creates P&L damage the same week it happens. 

That's the risk picture most cutover content doesn't account for. What follows is a decision framework for choosing between the three main EDI go-live strategies: big-bang, dual-run, and phased. The framework is built on the specific operational factors that make EDI different from every other migration you'll run. 

SPS Commerce helps suppliers execute EDI cutovers through a managed network of more than 300,000 connections, pre-built retailer integrations, and cutover specialists with experience across hundreds of go-live events. Learn more about SPS Commerce Fulfillment. 

What's Actually at Stake in an EDI Cutover? 

Before picking a strategy, let’s cover some fundamentals of EDI risk. Four factors distinguish an EDI cutover from a standard system migration. 

Live Retailer Relationships 

EDI is your operational interface with every retail trading partner. If your new system sends a malformed 856 ASN to Target, Target's system doesn't call you. It logs a defect. That defect shows up on your scorecard, and depending on the retailer, a scorecard hit triggers a chargeback that may take months to dispute and may never fully resolve. 

Hard Timing Windows 

Retail compliance is time-indexed. Purchase orders (POs) have MABD windows. ASNs must be transmitted within specific timeframes after shipment. Functional acknowledgments (997s) have response time requirements. A cutover that disrupts transaction timing, even briefly, creates a cascade of compliance failures that weren't errors in any operational sense but will be treated as errors by retailer systems. 

Chargeback Asymmetry 

Errors in EDI are cheap to make and expensive to recover from. A configuration problem that causes three days of malformed ASNs doesn't cost three days' worth of attention to fix. It creates weeks of dispute work, with no guarantee of full recovery. 

No Meaningful Test Environment 

You can run EDI testing in a sandbox, but there's no substitute for production. Retailer companion guides change, AS2/SFTP certificate configurations interact with real systems in ways staging can't replicate, and the actual behavior of 997 acknowledgment cycles often differs between test and production environments. Your first production transaction is always an integration test in some sense. 

This is the context in which your cutover strategy decision lives. Now let's look at what you're actually choosing between. 

What Are the Three Go-Live Strategies? 

These terms get conflated frequently enough that precise definitions matter before applying them to a real decision. 

Big-Bang 

Cut all trading partners and document types over to the new system at a single defined moment. The old system is decommissioned immediately or shortly after go-live. There's no period of parallel operation: when the cutover date arrives, the new system is the system. 

Dual-Run (Parallel) 

Operate the old and new systems simultaneously for a defined window. Both systems send or receive documents during this period. The team reconciles transaction outputs from both systems to validate the new one before decommissioning the old. 

Phased 

Cut over in defined waves by trading partner, document type, geography, or business unit, with each wave validated before the next begins. At any given moment, some partners are live on the new system and others are still on the old one. No single partner is ever running on both systems simultaneously. 

The key distinction to carry forward: phased and dual-run are often used interchangeably. They're not the same thing. In a phased rollout, each wave is a discrete cutover event: once a partner moves, they move completely. In a dual-run, the same partners and document types are flowing through both systems at the same time. The operational implications are very different, and conflating them leads teams to choose dual-run when they actually wanted phased. 

Is Big-Bang Right for Your EDI Cutover? 

Big-bang is the most misunderstood of the three strategies. It's often dismissed as too risky, and sometimes it is. But it's also the fastest, the lowest total cost, and when the conditions are right, the cleanest option. The failure mode is concentrated and immediate. The success case is a complete, decisive transition with no data divergence risk and no ambiguity about which system is authoritative. 

When Big-Bang Works 

Big-bang is the right call when all four of the following are true:  

• The partner count is manageable (roughly 10 to 15 or fewer). 

• The team has cutover experience or is working with a managed partner that does.  

• Your highest-volume retailers are already mapped and tested. 

• You have a credible fallback if something goes wrong.  

That last condition matters considerably. "We can always go back to the old system" is only a real fallback if the old VAN connection is still live, the legacy EDI platform is still operational, and someone has clear authority to invoke that decision. 

"The teams that execute big-bang well have done the same level of preparation you'd expect for a phased rollout — they've just concentrated it into a tighter window. The cutover itself is almost anticlimactic when the work has been done correctly. The problem is that teams confuse 'big-bang' with 'fast' and skip steps. That's when it falls apart." — Eric Shelton, SPS Commerce 

When Big-Bang is the Wrong Call 

If your partner count is large, if you have significant OTIF exposure concentrated in two or three key retailers, if your team hasn't run a production EDI cutover before, or if your fallback is essentially "hope it works," big-bang is the wrong choice. The failure mode is severe. All partners go dark simultaneously, there's no partial recovery path, and the team is racing to restore production while chargebacks accumulate. 

The concentrated failure mode of big-bang is also its most misunderstood characteristic. It feels riskier than it is when conditions are right, and less risky than it is when they're not. 

Is Dual-Run Right for Your EDI Cutover? 

Dual-run is the most commonly chosen strategy. It is also, in most EDI scenarios, the wrong one. 

The appeal is straightforward: keep the old system running while you validate the new one. If something goes wrong, fall back to the system you know. It reads as conservative, and conservative reads as safe. 

The problem is that dual-run carries its own significant risks that rarely surface in the "pros and cons" framing of generic content. 

Data Divergence  

When both systems are producing transaction outputs for the same partners, the source of truth is ambiguous. Which system's 810 invoice is correct? Which ASN does the retailer have on file? Reconciliation between dual systems is operationally expensive and never perfectly clean, particularly when retailer acknowledgment behavior differs between the two. 

Team Exhaustion 

Running two EDI systems simultaneously doubles the operational load. This is sustainable for days, not weeks. Teams that commit to a four-week dual-run window typically find that by week two, one system is receiving more attention than the other, which defeats the purpose of the parallel window. 

The Never-Ending Project Dynamic 

Dual-run requires a decision about when to stop running parallel. That decision is almost always harder than teams expect, because there's never a moment where the new system is obviously perfect. The threshold tends to shift. Teams extend the parallel window once, twice, indefinitely. Six-month "temporary" parallel states are not unusual. 

Ambiguous Failure Diagnosis 

When something goes wrong during a dual-run, the presence of two systems makes root cause analysis harder, not easier. Is the problem in the new system? The old system? The reconciliation process? EDI transaction errors during a dual-run are frequently attributed to the wrong system, which delays resolution. 

"The scenario I see most often is a team that defaulted to dual-run because it felt like the safe choice, and then discovered two months in that they're maintaining two EDI environments at full cost, nobody fully owns either one, and the decision to cut over to the new system has quietly become political. Dual-run doesn't eliminate risk — it spreads it out over a longer period and makes it harder to see." — Eric Shelton, SPS Commerce 

When Dual-Run is Appropriate 

Dual-run makes sense in a narrow set of circumstances:  

• A single extremely high-stakes retailer relationship where the fallback math genuinely justifies the cost. 

• Your team has the capacity to sustain the operational load. 

• You have a firm, pre-agreed decision date for cutting over.  

Without that last condition, a locked exit date, dual-run has a strong tendency to become permanent. 

For most mid-market suppliers, dual-run is neither necessary nor sustainable. The better alternative, in most cases, is a phased approach. 

Is Phased Right for Your EDI Cutover? 

Phased rollout is the strategy most teams should default to, and the one that generates the least discussion in general content because it sounds like a compromise between the other two. It isn't. It's a distinct approach with its own logic that makes the most sense for suppliers with:  

• 15 or more trading partners 

• Meaningful retailer compliance exposure 

• A team still building cutover experience, it's usually the right answer 

The core advantage of a phased rollout is that it contains the failure mode. If wave one has a problem, the problem affects that wave's partners, not your entire trading partner roster. You learn, adjust, and carry those lessons into wave two. Each wave also has a clean cutover event with a clear before-and-after state, which means diagnosis is faster and rollback, if needed, is scoped. 

Thrive Market's EDI onboarding program illustrates the operational logic of phased at scale. Working with SPS Commerce, the retailer onboarded more than 400 vendor partners across coordinated waves, achieving near-100% vendor compliance while managing a supply chain under significant volume pressure. No single wave failure could have derailed the entire program, and the structure of the waves created built-in learning loops between them. As Thrive Market's supply chain team put it: 

"Having merchandising, supply chain and IT all part of the initiative was critical to its success. SPS provided the program, staffing and best practices. But we also needed to provide the internal resources, alignment, and collaboration. Together, this made our EDI transition and implementations initiative a success." — Thrive Market Supply Chain Team, via SPS Commerce case study 

Sequencing Matters More Than Some Teams Expect 

In a phased rollout, which partners go first is a strategic decision, not a scheduling convenience. The framework below recommends starting with lower-risk partners: those with smaller order volumes, less OTIF exposure, or more forgiving scorecard structures, and treating early waves as live integration tests that protect your highest-stakes relationships. If Walmart or Target is in wave one and something goes wrong, you've learned something at maximum cost. 

For SMB and emerging suppliers especially, the sequencing conversation is as important as the strategy decision itself. A team running its first production EDI cutover should not be doing so against its highest-stakes retailer relationship. Early waves are practice with real consequences, and sequencing them to protect critical partners is the single most underutilized lever in a phased plan. 

When Phased is the Wrong Call 

Phased requires sustained executive attention across the entire rollout period. If sponsorship fades after wave one, the program typically stalls. Phased also takes longer to reach full production, which matters when timeline pressure is real. If you're racing against a contract deadline or an ERP go-live date, a long phased window may not be viable. In those cases, a compressed big-bang with strong preparation may outperform a phased approach that runs out of runway. 

How to Choose: A Four-Factor Decision Framework 

The right go-live strategy is determined by four operational variables. Evaluate each one, and the decision usually becomes clear. 

Factor 1: Trading Partner Count and Exposure Concentration 

A small partner count (under 10 to 15) with relatively even distribution across retailers favors big-bang. A large partner count, or significant concentration of OTIF/revenue exposure in a few key retailers, favors phased, with those high-stakes retailers sequenced into later, better-practiced waves. Dual-run is rarely the right answer regardless of partner count. 

Factor 2: Retailer Compliance Penalty Risk 

If your highest-volume partners operate under strict compliance regimes — Walmart's OTIF threshold for collect suppliers being 98%, Amazon's ASN chargeback structure — the cost of a production error is immediate and not fully recoverable through dispute. This biases toward phased, with lower-risk partners first. If your retailer mix is relatively forgiving on compliance enforcement, big-bang risk math improves. 

Factor 3: Internal Team Capacity and Cutover Experience 

A team that has run production EDI cutovers before, or is working with a managed partner that has, can execute big-bang with confidence. An untested team, or one already stretched across other project commitments, should phase. Dual-run often looks attractive to teams with limited capacity precisely because it appears to reduce pressure. In practice, it doubles workload rather than distributing it. 

Factor 4: Fallback Quality 

This is the most underweighted factor in most cutover plans. A real fallback means the legacy EDI environment is still operational, the old VAN connection is live, someone has clear authority to invoke the rollback decision, and the team knows exactly what reverting looks like in operational terms. When all of that is true, big-bang risk math improves substantially. When your fallback is theoretical or dependent on a system that's already been decommissioned, phased is your only viable option. 

What Has to Be True Regardless of Strategy 

Strategy determines sequencing. Discipline determines whether you're ready to execute at all. Whichever approach you choose, the following are non-negotiable. 

Trading partner notification and re-certification 

Every partner on the new system needs to complete re-certification before go-live on their wave. This is not a formality. Retailer companion guides change, and assuming your mapping is current is one of the most common sources of post-cutover errors. 

Mapping validation against current companion guides 

Validate every transaction set: 850 purchase orders, 856 ASNs, 810 invoices, and 997 functional acknowledgments, against the retailer's current companion guide, not the version you mapped against six months ago. 

Certificate and credential rotation 

AS2 certificates, SFTP keys, and VAN credentials all need to be verified or rotated as part of the cutover. Certificate mismatches don't fail gracefully. They produce silent transaction failures that don't surface until a retailer reports a missing document. 

997/MDN behavior testing  

Functional acknowledgment behavior in production sometimes differs from staging. Confirm that your new system is generating and processing 997s correctly before the first live transaction. 

Hypercare staffing 

Plan for two to four weeks of dedicated monitoring coverage immediately after each go-live event. The first production window is when configuration assumptions meet reality, and catching problems early is dramatically cheaper than catching them after a scorecard cycle. 

Clear rollback criteria 

Define in advance what rollback looks like and under what conditions the team invokes it. A rollback decision made during a production failure, without pre-agreed criteria, is almost always made too late. 

What a Managed Partner Changes About This Decision 

Whichever strategy you choose, the single biggest variable in cutover success is the experience of the team executing it. Teams that have run EDI cutovers across hundreds of go-live events carry knowledge that no internal team accumulates quickly: which retailer companion guides have changed recently, which AS2 configurations create unexpected certificate behavior, and where 997 reconciliation gaps typically appear. 

That experience changes the risk math under any strategy. A big-bang cutover executed by an experienced managed partner carries substantially less risk than the same cutover executed by an internal team running it for the first time. A phased rollout with pre-built connections to your trading partners runs faster and with fewer mapping errors than one built from scratch. As Avlon Industries put it when describing what their managed partner brought to go-live validation: "They know the retailer's requirements, so the setup and testing are quick and reliable. They do it all in a very short period of time." (SPS Commerce case study) 

For many suppliers in the $50M to $500M range facing an ERP migration, the cutover decision and the build-vs.-buy decision are the same decision. If you're replacing your EDI environment as part of a SAP S/4HANA transition (SAP's mainstream support for ECC ends December 31, 2027, and migrations are taking 18 to 36 months to complete), a managed partner can eliminate EDI dependencies from the current ERP first, creating a stable, tested foundation before the ERP cutover begins. That sequencing reduces risk on both projects. The network monitors retailer spec changes and transaction exceptions on an ongoing basis, so your team isn't debugging EDI workflows mid-cutover while simultaneously managing everything else an ERP migration requires. 

Summary: Choosing Your EDI Go-Live Strategy 

The right EDI go-live strategy is a risk math problem with four inputs: trading partner count and exposure concentration, retailer compliance penalty risk, internal team capacity, and the quality of your fallback options. 

Big-bang is the right choice for small partner counts with strong preparation and a real fallback. Dual-run fits a narrow set of circumstances and is the wrong default for most suppliers despite being the most commonly chosen approach. Phased is the right default for medium-to-large partner counts, meaningful compliance exposure, and teams building cutover experience, with sequencing decisions that protect high-stakes retailer relationships. 

Whatever strategy you choose, the cutover disciplines are the same: trading partner re-certification, companion guide validation, credential rotation, 997 testing, hypercare coverage, and pre-agreed rollback criteria. 

The framework above will get you to the right answer for your situation. The question of who executes it is worth asking at the same time. 

Planning an EDI cutover? SPS Commerce Fulfillment brings pre-built retailer connections, proven cutover procedures, and a managed network that monitors retailer spec changes and transaction exceptions on an ongoing basis, so your team can stay focused on the ERP migration rather than debugging EDI workflows. Explore SPS Commerce Fulfillment.