Think Build Implement Repeat
Data & Scraping

Getting Your Data Out When You Leave a Supplier

Last updated:

Test the exit at the entrance

The time to establish how you leave a supplier is before you join them. Ask during evaluation: can we export everything, in what format, how, and at what cost?

Then actually do it during the trial. The gap between what an export is described as and what it contains is where the problem lives.

What a complete export includes

  • The main records, obviously — customers, orders, transactions
  • Attachments and documents, not just references to them
  • History and audit trail, which is frequently omitted
  • Configuration and custom fields you invested time in
  • Relationships between records, in a form that can be reconstructed
The common disappointment is an export of the main tables with attachments missing and relationships flattened. Technically an export; practically a partial one.

Take a periodic export while you are a customer

Not because you plan to leave, but because it protects against several scenarios at once: supplier failure, a dispute, an outage, or an accidental deletion on their side.

Quarterly is enough for most systems. Store it somewhere you control and check occasionally that it opens.

Leaving cleanly

  1. Export everything, before giving notice if the contract permits
  2. Verify the export against record counts in the live system
  3. Check attachments open and are complete
  4. Confirm what the supplier will delete and when, in writing
  5. Keep access long enough to reconcile after the new system is live

When the export is inadequate

Options in order: ask for a fuller export as a paid service, use the API to extract what the export omits, or extract from the interface as a last resort.

Where the contract promised export and the reality does not deliver it, that is a contractual conversation and worth having formally rather than working around quietly.

Then plan the migration properly

An export is not a migration. Profile the data, map it to the new system, rehearse the load, reconcile the counts and totals, and keep the old system readable for months.

Migrations fail on data rather than on code, and an export you have not examined is exactly where the surprises live.

Frequently asked questions

Can a supplier refuse to give us our data?

Where personal data is involved you have rights, and commercially it depends on the contract. Practically, checking at purchase is far more effective than arguing at exit.

What format should we ask for?

Something open and structured — CSV or JSON — with a documented schema. A proprietary backup file you cannot read without their software is not an export.

How long should we keep the old system?

Read-only access for at least three months after cutover. Something always turns out to be needed and it is far cheaper than reconstructing it.

What if the supplier goes out of business?

This is precisely why the periodic export exists. Businesses relying on a supplier's continued existence to access their own data have a single point of failure they did not choose deliberately.

Keep reading

Never tested your export?

Run one this week and open it. If it is thinner than expected, that is worth knowing now rather than during a migration.

Book a free 30-minute call Get a project estimate WhatsApp us

Related services

What we build for problems like this one

Web ScrapingData Science