SupplierWiki curates detailed articles to help suppliers win at retail.

Don't let Walmart Post-Audits catch you off guard in 2025. Join Allie and Bekah to learn best practices for preventing and disputing Post Audits.

Prepping for Walmart Audits

Post Audits are preventable and disputable! Join Allie and Bekah to learn how to best prepare for Walmart Post Audits.

Articles

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. 

 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. 

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. 

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. 

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. 

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. 

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. 

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

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. 

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. 

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. 

 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. 

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. 

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

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."

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. 

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. 

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. 

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. 

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. 

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."

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

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. 

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:  

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 

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. 

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. 

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

, 810 invoices, and 997 functional acknowledgments, against the retailer's current companion guide, not the version you mapped against six months ago. 

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. 

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. 

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. 

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. 

Exigences produit « Retail-Ready » pour les fournisseurs débutants

Lorsqu'une marque a bâti une activité solide en vente
directe au consommateur (DTC), l'expansion vers le retail semble souvent être
l'étape logique suivante. Pourtant, de nombreux nouveaux fournisseurs se
heurtent rapidement à une réalité bien connue et frustrante. La première
commande arrive — et les premiers problèmes surgissent :

• Le code-barres EAN (GTIN) n'est pas validé par les données
de référence GS1 du distributeur.

• Les dimensions du carton ne correspondent pas au fichier
article.

• L'emballage échoue au test de chute.

• Les cartons sont livrés dans une configuration incorrecte.

Chaque problème pris isolément peut sembler mineur — mais
ensemble, ils entraînent des retards, des déductions et une cascade de
problèmes opérationnels dont il est difficile de se remettre, souvent avant
même que le produit n'atteigne le rayon.

C'est là que de nombreuses marques émergentes atteignent
leurs limites. Elles réalisent qu'un bon produit ne suffit pas. Il s'agit
d'éliminer les obstacles opérationnels. Un produit qui circule de manière
précise, cohérente et évolutive à travers le système opérationnel d'un
distributeur représente un tout autre défi — c'est pourquoi les marques qui
débutent dans le commerce de détail doivent y être particulièrement attentives.

Pourquoi les exigences des distributeurs ont augmenté

Des distributeurs comme Carrefour et Leclerc ont
considérablement renforcé leurs exigences. Des programmes comme le système de
certification IFS/BRC et des normes de validation plus strictes signifient que
les fournisseurs évoluent aujourd'hui dans un environnement de conformité
nettement plus structuré qu'il y a quelques années.

Le défi ? La plupart des fournisseurs traitent cela comme un
problème opérationnel — alors qu'il s'agit en réalité d'un problème de
conception produit. Les décisions concernant les EAN, l'emballage, les
configurations de lots et les données articles déterminent tout ce qui suit. Si
elles sont mal prises, aucune automatisation EDI ne pourra résoudre le
problème.

Ce que l'emballage Retail-Ready doit accomplir

Contrairement aux emballages DTC, qui arrivent accompagnés
d'un contexte grâce à la publicité et aux avis, l'emballage en magasin doit
fonctionner seul dans un rayon rempli de produits. Il doit remplir plusieurs
fonctions simultanément :

Votre emballage est votre principal vecteur de
communication. Il doit transmettre l'objectif, la différenciation et la valeur
ajoutée dès le premier instant. Grüns, par exemple, a amélioré sa performance
en rayon simplement en renommant « Cubs » en « Kids » et en passant à des
couleurs vives.

L'emballage Retail-Ready est conçu pour minimiser les coûts
de main-d'œuvre. Un emballage bien conçu permet aux employés de placer le
présentoir produit directement du carton d'expédition en rayon, sans avoir à
ranger chaque unité individuellement. Pour les grandes surfaces, cette
efficacité est une priorité.

Dans le cadre de normes comme IFS/BRC, l'emballage doit être
conforme en termes de matériaux, d'étiquetage, de codification et plus encore.
Toute déviation — un carton endommagé, un matériau incorrect ou un code-barres
EAN mal étiqueté — est considérée comme un défaut et peut entraîner le refus de
la livraison, un retour aux frais du fournisseur ou, en cas de récidive, un
déréférencement.

Huit domaines critiques pour les normes opérationnelles

Lorsque vous vendez à Carrefour, Auchan ou Leclerc à leur
échelle, vous ne pouvez pas compter sur la flexibilité qui fonctionne dans le
commerce en ligne. Il faut un système opérationnel rigoureux orienté vers une
qualité de livraison constamment élevée — c'est-à-dire que le distributeur
reçoit exactement ce qui a été commandé, en parfait état et dans les délais.

Y parvenir signifie respecter des normes opérationnelles
strictes dans huit domaines critiques :

Ces normes sont toutes interconnectées — les nouvelles marques doivent être conscientes que corriger un seul problème ne suffit pas pour réussir.

L'emballage nécessite souvent une refonte du produit

Réussir dans le commerce de détail signifie parfois repenser fondamentalement son produit :

• Ajuster le prix. L'espace en rayon est limité ; il peut être nécessaire de réduire la taille des packs pour atteindre un prix inférieur qui fonctionne mieux en magasin.

• Développer de nouvelles configurations. Les consommateurs achètent différemment en magasin et en ligne. Des lots familiaux ou des packs avantageux adaptés au comportement d'achat en magasin peuvent être nécessaires.

• Résoudre les problèmes fonctionnels. Des caractéristiques comme des sachets à ouverture silencieuse ou des poignées plus ergonomiques peuvent devenir des arguments de vente en rayon.

• Garantir la longévité. Votre emballage doit survivre intact au réseau de distribution. Des emballages mal conçus peuvent entraîner le classement des expéditions comme « marchandise problématique », restant invendables dans les centres de distribution.

Tout cela montre que l'emballage devrait être la priorité absolue lors de la préparation à l'expansion dans le commerce de détail. De nombreuses marques DTC à succès qui négligent ces aspects importants connaissent une baisse significative de leurs ventes de produits.

Pour de nombreuses marques qui entrent dans le retail, la gestion des EAN et GTIN devient le premier véritable défi opérationnel. Dans le DTC, la discipline en matière de codes-barres est souvent laxiste. Les marques réutilisent des identifiants, utilisent des codes-barres non conformes GS1 provenant de fournisseurs tiers ou maintiennent des fiches produits incohérentes sur différentes plateformes. Ces raccourcis ne posent généralement pas de problèmes lors de l'expédition directe aux consommateurs — dans le
commerce de détail, c'est différent.

Les grands distributeurs valident chaque code-barres par rapport aux données de référence GS1. En France, les GTIN doivent obligatoirement être obtenus directement auprès de GS1 — les codes-barres achetés auprès de tiers ne sont fondamentalement pas acceptés par les distributeurs comme Carrefour ou Leclerc. Si un code-barres est attribué en double, non enregistré ou associé à des informations produit erronées, l'article peut être immédiatement rejeté. Ce qui ressemble à un petit problème de données peut rapidement entraîner des retards d'intégration, des erreurs de réception de marchandises, des écarts de stock, des divergences dans les avis d'expédition et des refus de livraison aux frais du fournisseur.

C'est parce qu'un code-barres est bien plus qu'une simple étiquette scannable. Dans le retail, il fonctionne comme l'identifiant maître du produit dans toute la supply chain. Systèmes d'inventaire, réapprovisionnement, réception de marchandises, planification, rapports de ventes et données produit — tout dépend de l'exactitude de ces informations. Les distributeurs ne peuvent traiter efficacement les expéditions que si l'enregistrement électronique correspond exactement au produit physique. Code-barres, dimensions, poids, configuration de lot et nom du produit doivent correspondre dans tous les systèmes concernés. Même un petit écart peut générer du travail manuel, des exceptions d'expédition ou des problèmes coûteux en cascade.

Les données articles sont déterminantes pour l'emballage Retail-Ready

Dans le commerce de détail, les données sont aussi importantes que les camions et les entrepôts. Chez les grands distributeurs comme Aldi, des données articles précises garantissent que tout fonctionne sans accroc. Lorsque les données sont propres et correctes, les commandes sont traitées rapidement, les expéditions arrivent à temps et les produits atteignent le rayon sans problème.

Mais si les données sont erronées, les problèmes se propagent rapidement. Une seule erreur peut déclencher une réaction en chaîne qui ralentit la réception, retarde la mise en stock et génère des coûts dans tout le réseau.

Imaginez des millions d'euros de marchandises sur un quai de réception, impossibles à vendre. C'est ce qui se passe quand ce qui arrive ne correspond pas à ce que le système du distributeur attend. Dans ces cas, les équipes de réception ne peuvent pas traiter l'expédition. Elles la mettent de côté, documentent le problème et attendent que quelqu'un au siège le résolve. Cela ralentit les opérations, immobilise du capital et oblige les employés à effectuer un travail manuel qui devrait être automatisé.

Les erreurs de données ont des conséquences financières réelles. Dans le commerce de détail européen, les distributeurs comme Carrefour ou Leclerc traitent les écarts de données comme des défauts de qualité — avec des conséquences directes : les livraisons sont refusées, retournées aux frais du fournisseur, ou en cas de récidive, elles conduisent au déréférencement du produit. S'y ajoutent les ventes perdues dues aux retards ainsi que la perte de places en référencement attribuées à des concurrents.

• Articles ne correspondant pas à la commande

• Informations produit manquantes ou incomplètes

Ce qui ressemble à une petite erreur de données dans le système peut rapidement entraîner des refus de livraison, des retards de réception et une relation commerciale durablement dégradée avec le distributeur.

Lorsque les systèmes ne reflètent pas correctement le stock réel, il peut arriver qu'un site ait trop de marchandises tandis qu'un autre en manque. Des produits disparaissent de l'assortiment alors qu'ils devraient être disponibles, et les clients ne trouvent pas ce qu'ils cherchent. À long terme, cela nuit au chiffre d'affaires et sape la confiance des clients envers la marque.

Ce que de bonnes données articles contiennent

Pour que les commandes soient exécutées correctement dès la première fois, des données articles complètes et exactes sont nécessaires. Cela comprend :

 Des codes-barres corrects pour que les produits puissent être suivis partout.

Dimensions et poids pour que les distributeurs puissent organiser efficacement entrepôts et rayons.

Le nombre exact d'articles par carton, correspondant à ce qui est réellement livré.

 Marquages de matières dangereuses et mentions d'origine pour que les expéditions puissent être transportées en toute sécurité.

 Des photos claires pour l'achat en ligne.

Des liens corrects entre tailles et couleurs dans le système.

Il est important de saisir ces données correctement afin que vos produits puissent circuler efficacement dans les systèmes des distributeurs.

Obtenir un contrat avec un distributeur et être véritablement retail-ready sont deux choses différentes. Un produit qui performe bien sur Shopify ou Amazon peut échouer à chaque test opérationnel dès le premier jour chez Carrefour ou Leclerc — avec des EAN/GTIN incorrects, des configurations de lots non conformes, des données articles incomplètes, un étiquetage non conforme.

L'erreur la plus courante des fournisseurs débutants est de traiter ces problèmes comme des questions opérationnelles, alors qu'il s'agit en réalité de décisions produit. Le choix de la taille du lot, l'attribution du GTIN, la conception de l'emballage et l'exactitude des données articles — tout cela est décidé avant l'envoi de la première commande. Si ces décisions sont mal prises, aucune automatisation EDI ou optimisation des directives de livraison spécifiques au distributeur ne pourra résoudre le problème. Mais si elles sont prises correctement, votre supply chain a une vraie chance.

Pour d'autres articles destinés aux nouvelles marques préparant leur entrée dans le commerce de détail, rendez-vous sur 

Supplier Data Portability: A Checklist for Getting Raw Data into Your BI Tools 

 into Snowflake, Databricks, and any other cloud BI destination via Delta Sharing, so your team can work with retailer performance data inside the tools and workflows it already uses.

Supplier data portability means raw, structured, refreshable data flows directly into your BI stack (Snowflake, Databricks, Power BI, Tableau) without manual downloads or vendor dependency. Most supplier data vendors offer exports, not portability. This checklist helps IT, analytics, and operations leaders evaluate the difference across three layers: contract rights, technical integration, and operational reality. For a vendor example that passes its own test, see 

Your vendor says the data is exportable. It probably is: as a CSV you download one report at a time, or a flat file that arrives on Secure File Transfer Portal (SFTP) every morning if the job runs cleanly, or a PDF summary that requires a human to turn it into something a Business Intelligence (BI) tool can use. That is not portability. That is friction dressed up as a feature. 

Real portability means raw, structured, refreshable supplier data flows into the system your team actually works in (Snowflake, Databricks, BigQuery, Power BI, Tableau, Looker) without manual steps, without losing fidelity, and without depending on your vendor's continued cooperation every time someone needs to run a report. 

The supplier data category (EDI transactions, retailer point-of-sale (POS) sell-through, inventory feeds, scorecard performance, chargeback history) is historically one of the worst categories for data portability. Most vendors in this space were built on a portal-first model: the dashboard is the deliverable. That assumption made sense when reporting meant logging in and reading a chart. It does not hold when your team is building demand models, integrating across channels, or trying to feed retailer sell-through into the same Snowflake environment where your ERP data already lives. 

This article gives operations, IT, and analytics leaders a practical framework for evaluating whether their supplier data is genuinely portable: what to look for in vendor contracts, what the technical bar actually is, and what internal architectural decisions determine whether portability sticks.  

Why the Portability Problem Is Getting Worse Before It Gets Better

Has the modern data stack left supplier data behind?

Three pressures are converging right now, and each one is exposing portability gaps that teams could previously ignore. 

Modern data warehouses have become the default

Snowflake, Databricks, BigQuery, and Delta Sharing have matured into the standard destinations for enterprise data. BI and data engineering teams now expect operational data to land there natively, the same way financial data from Stripe lands in Snowflake via a direct share rather than a manual export. 

, for example, lets users send complete, up-to-date data and reports directly to Snowflake or Amazon Redshift without requiring code or engineering on the customer's side. Supplier data vendors have historically lagged this standard by years. Teams that have spent the last three years modernizing their data infrastructure now find that their retailer analytics and EDI data are still arriving as flat files or accessible only through vendor portals. 

AI and machine learning use cases need raw data

Supplier teams experimenting with demand sensing, automated exception handling, and integrated planning models need raw, structured, refreshable data, not summary dashboards. A dashboard tells you what happened. Raw data lets you build a model that tells you what is likely to happen next. That distinction is exposing a fundamental problem with portal-first vendor architectures: the data underlying the dashboard is often inaccessible in any form that a data science team can actually use. 

EDI is frequently treated as a backend function, isolated from business intelligence systems, and that separation creates missed opportunities for optimization, forecasting, and better decision-making. The same is true across the full range of supplier data categories. The intelligence is there. The question is whether teams can actually get to it. 

Vendor lock-in scrutiny has reached operational categories

Post-pandemic budget pressure and heightened software spend scrutiny have elevated data portability into procurement conversations. Buyers are now asking about exit clauses, data export rights, and standard format support during vendor selection, in categories like retailer analytics and EDI, not just traditional cloud and SaaS contracts. Companies have found themselves paying for services they no longer use simply because extracting their data would cost more than continuing the subscription. Others have lost years of business history when a vendor relationship ended without clear data access provisions. The supplier data category is not immune to this dynamic. 

What Supplier Data Actually Matters for BI and at What Level

Before working through the portability checklist, it helps to inventory which data categories are worth fighting for. Not all supplier data needs the same level of portability, and prioritizing the wrong categories wastes negotiating leverage. 

Vendor-calculated composite metrics (a vendor's proprietary "supply chain health score," an aggregated demand forecast, or a custom chargeback categorization) are derived outputs rather than raw data. Getting the raw inputs that produced these metrics matters more than getting the derived layer itself. More on that distinction in the next section. 

The Most Important Distinction: Raw Data vs. Derived Data

What is the difference between raw data and derived data in supplier analytics?

This is the concept that most portability conversations miss, and it is worth being precise about. 

 is the underlying transactional or operational record: the individual EDI 850 transaction with its line items, quantities, and dates; the daily POS sell-through by store and SKU from a specific retailer; the on-hand inventory count at a distribution center on a specific date. 

 is what a vendor calculates from that raw record: a weekly sell-through percentage, a fill rate score, a demand forecast, a chargeback category. Derived data is what shows up in dashboards. It reflects the vendor's analytical model, not just the underlying facts. 

The portability problem is that many vendors expose only the derived layer for export. You can download the fill rate score, but not the shipment records that produced it. You can export the weekly sell-through summary, but not the daily by-store data underneath. That limitation has two consequences. 

The first is analytical: when your team can access only derived outputs, they can analyze only what the vendor chose to calculate. They cannot build alternative models, cannot apply your company's own demand forecasting logic, and cannot cross-reference retailer data with internal ERP records at the transaction level. 

The second is structural: exporting only derived data means accepting the vendor's analytical model as a dependency, not just their platform. Switching vendors means rebuilding analysis on top of a different vendor's derived outputs, which may not align, not just mean migrating data. 

When evaluating a vendor's portability claims, the right question is not "can we export our data?" It is: 

"Can we export the raw inputs that your dashboard is built on, at full grain, in a structured format, with a refresh cadence that matches the data type?"

 A vendor who cannot answer that question with a clear yes and demonstrate it technically is not actually portable. 

What are the warning signs of supplier data vendor lock-in?

Vendor lock-in in the supplier data category rarely announces itself. It accumulates through contract language that seems reasonable at signing and through architectural choices that feel convenient until they are not. These are the patterns to know before they become a problem. 

 Some vendors export data in formats that require the vendor's own tools to interpret. The export looks like a data file, but in practice it is readable only through the vendor's parser or schema documentation, which is subject to change. Standard formats (CSV, JSONL, Parquet, Delta) are portable because any warehouse or ETL tool can ingest them without vendor involvement. 

Portal-only access with no programmatic alternative.

 A vendor portal that provides no API, no data share, and no file-based delivery outside the portal is not portable. It is also a single point of failure: if the portal changes, goes down, or the vendor relationship ends, the data is inaccessible. 

APIs scoped too narrowly for bulk extraction.

 Some vendors offer APIs that are technically available but practically useless for bulk historical access. Rate limits that allow 100 records per minute, endpoints that expose only current-state data rather than historical records, and API responses that return only aggregated views rather than raw transactions are access restrictions dressed as integrations. An API that cannot support a full historical data pull at onboarding, or a clean exit at termination, is not a portability solution. 

 When a vendor's export format combines raw records with vendor-calculated fields in a single schema, with no way to separate them, teams cannot distinguish the factual record from the vendor's interpretation of it. This is most common in scorecard exports and chargeback reports. 

Contracts that grant "export rights" without defining format, timeline, or cost.

 Vendor contracts should define the format in which the vendor must provide data, timelines for export, and costs, including provisions for portable formats even if you terminate the relationship. A contract that says "customer owns their data" but specifies nothing about how that data is accessible is not a portability commitment. The contract should specify formats including non-proprietary options like CSV, JSON, or XML, the timeframes within which data can be exported, and what happens to configurations and metadata. 

 This is the most consequential lock-in pattern and the least visible until it happens. A vendor whose contract grants access to data only during the active subscription, with no provision for historical export after termination, is holding years of operational history as a retention mechanism. Demand it in writing before signing. 

The checklist below is organized into three tiers: contract rights, technical integration, and operational reality. All three matter. A contract that grants portability rights but a technical architecture that makes them impractical is not portable. A solid technical integration without the contract backing is vulnerable. 

Work through each tier during vendor evaluation, contract renewal, and when conducting an audit of current vendor relationships. 

What Modern Data Stack Expectations Look Like

What does a truly portable supplier data integration look like?

The checklist above names the minimum bar. It is worth being specific about what passing that bar looks like in practice for teams working with current-generation data infrastructure. 

Native warehouse sharing is the benchmark.

 A vendor that delivers data via Snowflake private listing or Databricks Marketplace does not require you to build or maintain an ETL pipeline. The data lands in your warehouse with the same security model, governance controls, and refresh reliability as data you manage yourself. SPS Analytics System Integration delivers POS and sell-through data directly to Snowflake via private listing and to Databricks via marketplace integration, with Delta Sharing available for any other cloud destination. That architecture is what portability looks like in operational practice, not a CSV endpoint that requires engineering time to maintain. 

Delta Sharing is the open standard for cloud-agnostic portability.

 For teams whose BI environment is not Snowflake or Databricks, or who need to share data across cloud boundaries, Delta Sharing provides an open protocol that any Delta-compatible destination can receive. A vendor that supports Delta Sharing is not betting on a single warehouse provider's continued dominance. That matters if your data infrastructure evolves. 

Structured data is not the same as clean data.

 A vendor can deliver structured data that still requires substantial transformation before it is useful. The most portable vendor offerings pair structured delivery with data that has already been cleansed, standardized, and aligned to the customer's product catalog. SPS Analytics System Integration delivers the same retail sales and inventory data accessible through the platform, sent to your BI environment or cloud data warehouse, with full-service data acquisition, cleansing, validation, standardization, and delivery included. The cleansing is part of what you are evaluating, not a separate question. 

Refresh cadence is a technical commitment, not a marketing claim.

 A vendor who publishes refresh cadences in their API documentation and schema versioning in their developer docs is a vendor who has built their integration for production use. A vendor whose refresh cadence is communicated only through sales conversations has not. 

Architectural Decisions That Make Portability Real

How do you prevent internal decisions from re-creating vendor lock-in?

Portable vendors are necessary but not sufficient. Internal architectural choices can re-lock data even after a team has selected vendors who pass the checklist above. Three principles apply regardless of which vendor you choose. 

Keep raw data and derived data physically separate.

 When raw transaction records and vendor-calculated or internally-calculated metrics live in the same table, the raw signal becomes inseparable from the analytical model that processed it. Separate schemas, separate ingestion pipelines, and separate governance policies for raw and derived data are what preserve the raw layer's long-term utility. If a vendor changes their calculation methodology, or you switch vendors, you want the raw record untouched. 

Prefer open standards over vendor-specific formats.

 Delta Lake tables, Apache Parquet files, and standard SQL schemas are readable by any modern data tool. Vendor-specific binary formats, proprietary compression schemes, and custom serialization formats are readable only with vendor cooperation. When you build your ingestion pipelines against open formats, changing warehouse providers or adding new BI destinations does not require renegotiating vendor contracts. 

Build a routing layer between vendor feeds and downstream BI tools.

 When BI tools connect directly to vendor data feeds, without an intermediate staging layer, any change to the vendor's schema, refresh schedule, or delivery mechanism cascades immediately into downstream reports. A staging layer that receives raw data from vendors and presents a stable, internally-governed schema to BI tools absorbs vendor changes without breaking dashboards. This is the difference between a data architecture that can survive vendor transitions and one that cannot. 

Vendor lock-in rarely arrives as a single mistake. It creeps in through contract clauses that make exit expensive and through architectural choices that make change slow. The antidote is portability by design: keeping execution in your cloud, keeping data where it already lives, and making every evaluation and proof of concept a reversible choice instead of a one-way door. 

The Strategic Argument for Solving This Now

Data portability is not just an IT or procurement concern. It determines what analytical work your team can credibly take on and what remains permanently off the table. 

Suppliers who have solved the portability problem operate with a materially different set of analytical options. They can feed retailer sell-through into the same planning models that incorporate ERP demand signals. They can build exception detection workflows that fire when on-hand inventory crosses a threshold relative to recent POS velocity, without logging into a portal to check. They can run retrospective analysis across three years of historical EDI transactions to characterize which deduction codes recur at which retailers, and why. None of that is possible when the data lives inside a vendor portal. 

Suppliers who have not solved it are limited by the vendor's dashboard, regardless of how capable that dashboard is. The vendor's dashboard is a product designed to serve the median use case of their customer base. Your team's specific analytical questions (the ones that map to your assortment, your retailer mix, your deduction patterns, your forecasting methodology) are not the median use case. 

The gap between those two positions is widening. As AI-assisted demand sensing, automated exception handling, and integrated planning tools become more accessible to mid-market suppliers, the bottleneck will increasingly be whether the underlying data is structured, raw, and accessible enough to feed those tools. A vendor portal full of summarized dashboards will not close that gap. 

If working through the checklist above surfaces gaps in your current vendor relationships, the path forward is either negotiating portability provisions into your next renewal cycle or moving to vendors that already pass. 

 is built for this, with native Snowflake private listing, Databricks marketplace integration, and Delta Sharing to any other cloud BI destination, delivering structured, cleansed retailer data where your team already works. 

The checklist here was built in part from what that architecture already delivers. That alignment is intentional, and worth naming directly: a vendor confident enough in their portability to publish the evaluation criteria is the kind of vendor worth working with. 

Forecast Accuracy and Forecast Bias: The Two Numbers That Decide Whether Your Supply Chain Holds 

Forecast Accuracy and Forecast Bias

Metric Misalignment in Modern Supply Chains 

In modern supply chain management, organizations frequently default to forecast accuracy as their primary success metric. Viewed in isolation, though, accuracy is a strategic risk. A high accuracy percentage may look impressive on a quarterly report card, but it tells you nothing about the direction of your errors, 

. Without knowing why you missed (and in which direction), a high accuracy score can hide the problems that drain cash and hurt customer relationships. 

The strategic importance of demand planning comes down to resource allocation. Every percentage point of error represents a misallocation of labor, shelf space, and working capital. To truly optimizethose resources, teams need to recognize that forecast accuracy (average closeness) and forecast bias (directional consistency) are distinct diagnostics.  

Articles

SupplierWiki curates detailed articles to help suppliers win at retail.

Prepping for Walmart Audits

Overview

Articles