Changing Platforms? The Export Clause, the File List, and the Dry Run That Proves It

The question that decides a migration is rarely technical. It is contractual, and it was answered months or years before anyone typed the word migration into a vendor ticket. Someone signed an agreement that either described how data leaves or stayed quiet about it. Everything downstream follows from that paragraph.

What has shifted recently is that buyers are asking about it earlier. Exit terms used to surface in year four, during a renewal fight. Now they get marked up during the initial redline, alongside uptime and price escalators. Vendors have adjusted: more of them publish export documentation openly, and more will commit in writing to a format and a turnaround window. That change is worth using while you have leverage, which is before you sign, not after.

What the export clause needs to say, in plain terms

A clause that only says the customer owns its data is decorative. Ownership without delivery is a philosophical position. The useful version names four things: the scope of data covered, the format it arrives in, how long the vendor has to produce it, and how long after termination the obligation survives.

Survival is the one most often missing. If assistance expires on the termination date, you are negotiating for your own records at the exact moment you have nothing left to trade. Thirty to ninety days of post-termination access, with the vendor's hourly rate for assistance fixed in advance, removes the entire argument. Ask also for a deletion certificate on a defined date, so the record of what was destroyed and when is in a file rather than in someone's memory.

Two more items earn their space. A ceiling on exit assistance fees, because an unpriced service is an unlimited invoice. And a statement that exports include historical records, not just the current state, since a snapshot of today's catalog tells you nothing about what a customer paid in 2022.

The file list most teams underestimate

People think of a migration as customers and orders. Those are the easy two. The records that cause the delay are the ones that encode relationships rather than transactions.

• Customer-specific price lists and contract pricing, including expiration dates and approval history
• Account hierarchies: parent companies, ship-to locations, buyer roles and spending limits
• Quotes in progress, and the rules that turned a quote into an order
• Catalog data with attributes, units of measure, pack quantities and substitutions
• Product media and documents, with the filename-to-SKU mapping that makes them useful
• Invoices, credit memos, payment terms and open balances
• Punchout and EDI configurations, which usually live in the vendor's console and nowhere else
• Tax settings, shipping rules, and any logic written as code inside the platform

Integration logic is the category that tends to be discovered late. It is rarely covered by an export at all. Write it down yourself, in a spreadsheet, while the system is still running. Anyone who has moved a mid-sized distributor between platforms has learned this by rebuilding a shipping rule from a customer complaint.

The tools that do the actual work

Three delivery paths exist and most migrations use all of them. A bulk export of flat files for catalog and customers. An API pull for anything the bulk export truncates, typically order history and attachments. And a direct database extract, which some vendors offer and some do not. Ask which of the three a b2b ecommerce platform supports before the demo ends, because the answer predicts the shape of your exit years in advance.

On the receiving side, keep a staging area between the old system and the new one. Load nothing directly. The staging copy is where you run counts: record totals by table, sums of order values by month, distinct customer identifiers, byte counts on media. Reconciliation is arithmetic, and arithmetic is the only thing that will tell you a transfer finished. The National Institute of Standards and Technology is responsible for measurement and data interoperability standards in the United States, and the discipline it represents applies here in its simplest form: if you cannot measure the before and the after, you have not verified anything.

Keep a field-level mapping document. One row per source field, the destination field, the transformation applied, and who approved it. It feels bureaucratic on day one and saves a week when a price comes out wrong in testing.

The dry run is the part you cannot skip

Run the full export and load at least twice before the real cutover. The first pass finds the character encoding problems, the truncated description fields, the dates that arrive in the wrong order. The second pass confirms the fixes held and gives you a reliable clock on how many hours the transfer takes, which determines whether you cut over on a Friday evening or need a longer freeze.

Then keep the old system readable, not editable, for a defined period after go-live. Read-only access costs little and settles the questions that only appear once real users are placing real orders. Budget for it in the exit terms, and the final week becomes an operational exercise rather than a negotiation.

Treat the export path as a feature you are buying, priced and documented alongside everything else. Vendors who answer the question cleanly tend to be the ones whose data you can actually get at, and the buyers who ask it at signing are the ones who move on their own schedule.