Your Vendor Contract Protects the Code. Does It Protect Your Data When You Leave?

The clause everyone skips

Most SMBs and institutions have gotten reasonably good at one contract fight: who owns the code when the engagement ends. It's a visible, well-understood risk, so it gets a line item in the SOW. Data portability doesn't get the same treatment, and that asymmetry is backwards. Code you can usually replace — rebuild the feature, hire someone else to extend it. Three years of enrollment records, donor history, or customer support tickets trapped in a vendor's proprietary schema is a different kind of problem, because there's no rebuilding your own history.

The failure mode is quiet. You sign with a vendor whose platform looks fine, maybe even good, for the first eighteen months. Then you want to switch — pricing changed, support degraded, the product stopped fitting how your organization actually works — and you discover the contract never specified what "your data" means in practice, what format you get it in, or what the vendor is allowed to charge you to produce it.

What actually goes wrong

Three patterns show up repeatedly, and none of them require bad faith from the vendor — they're just what happens when nobody wrote the terms down.

Export exists, but it's not usable. A vendor can honestly say "yes, we offer data export" and still hand you a CSV dump of raw table rows with internal field names, no relationships preserved, and no documentation of what any of it means. Technically compliant, practically useless. Rebuilding that into something a new system can import is a project in itself, sometimes expensive enough that organizations just... don't switch, and the vendor knows it.

The export doesn't include everything you think it does. Core records usually come out fine. The things that get left behind are the parts that were added as the relationship matured: custom fields someone configured in year two, historical audit logs, attachments and file uploads, relationships between records that lived in the application layer rather than the database. If your data model grew organically with the vendor, your export is only as complete as whatever they chose to script for.

Getting it out costs money, and the price isn't fixed in advance. Some contracts are silent on this entirely, which means "reasonable fees for data extraction" gets defined unilaterally by the party you're trying to leave. For a school or college sitting on years of student information system data, that can mean a five-figure invoice to retrieve records you already paid to have created.

What to put in the contract instead

None of this requires exotic legal language. It requires specifying, before signing, the same way you'd specify code ownership:

• Format. Not "export available" but a named, structured format — standard CSV/JSON with a documented schema, or a direct database dump if the vendor uses one. If the vendor can't commit to a format today, that's information too.
• Scope. Every data type the system will come to hold, not just the obvious core tables. Explicitly include custom fields, attachments, audit trails, and configuration data — the things that accumulate after go-live and never make it into the original SOW.
• Timing. A maximum number of business days from a written request to a completed export, and what happens if that deadline slips.
• Cost. A capped or waived fee for a standard export, agreed at signing. If the vendor needs to charge for unusually large or custom extracts, define what counts as standard versus custom now, not after you've already given notice to leave.
• Format stability over time. A commitment that the export format won't silently change between your onboarding and your eventual offboarding, so the contract term you negotiated still means something three years later.

Why this matters more for schools and colleges than it sounds

For-profit SMBs can usually absorb a bad data migration as a cost of doing business. Institutions carrying FERPA-covered student records, health data, or donor and financial history don't have that luxury — a vendor transition that goes badly isn't just expensive, it can create a compliance gap if records become incomplete or unverifiable mid-migration. That's a reason to treat the portability clause as seriously as the privacy and security clauses already getting legal review, not as boilerplate to accept as written.

The takeaway

Before signing with any software vendor, ask for the data export format and fee schedule in writing, as part of the contract — not as a verbal assurance from sales. If the vendor can't answer specifically, that's the answer.