Getting Your Data Out of Any System, Including Ours
Lock-in is rarely deliberate and usually structural. What to test before you sign, what to check annually, and what an exit actually requires.
Lock-in is rarely a plot
Very few software vendors deliberately trap customers. What happens is more ordinary: the export was built for a simple case, nobody asked for the complicated one, and the complicated one is where your actual history lives.
The result is the same either way. You can leave, and you cannot take the part that mattered.
This article is written to be used against us as much as anyone else. A piece about lock-in from a vendor is only worth reading if it names the questions that are awkward for the author, so those are the ones below.
What "your data" actually means
Most exports produce a list of startups. That is the easy part and it is not what you would miss.
The records that carry real value are the ones with structure:
Applications with their scoring detail. Not the final average - each evaluator's score on each criterion, plus the rubric that was in use for that round. This is what makes a past decision explicable, and it is the single most commonly lost record.
Funding with its chain. Source, allocation, commitment, tranche, milestone, evidence, approver. A list of payments is not the same thing and will not satisfy anyone asking about a specific disbursement.
Space with its history. Allocations, rates, deposits taken and returned, payments made and missed.
Progress over time. Stage at entry and at each review. A single current stage tells you nothing about movement.
The requests. Document and change requests, with their state and dates. This is the record of what you asked for and whether it arrived.
If an export gives you the first item on each of those lists and not the second, you have a directory, not your history.
Test it during the trial
The only reliable method. Not a question in an RFP, not an assurance in a call - do it.
During evaluation, ask to:
- Run an export yourself, without raising a support ticket
- Open the file in a spreadsheet
- Find one specific thing - a particular application's per-evaluator scores, a particular tranche's milestone
Step three is the test. Exports frequently pass steps one and two and fail step three, because the flat file omits exactly the nested detail you needed.
The questions worth asking
Can we run an export ourselves, or is it a request? A support ticket is a dependency, and it is a dependency at the exact moment relations may be strained.
What format? CSV or JSON. A PDF is a picture of data. An export you cannot load somewhere else is not an exit.
Does it include history, or only current state? Current state is a snapshot. History is what you cannot rebuild.
Are files included? Uploaded documents, pitch decks, evidence attached to tranches. Often stored separately and often not in the export.
Is there an API? Not because you will build something. Because an API means the data is structured and reachable programmatically, which is a stronger guarantee than any export promise.
What happens after we leave? How long is data retained? Can you export during a notice period? Is there a fee? Get the answer before signing, when you have leverage.
Make it an annual habit
Once a year: run a full export, open it, check that the detail is still there, and keep the file somewhere institutional.
Three reasons. Upgrades break exports, and finding out during an exit is the worst time. Staff turnover means the person who knew how to do it may have left. And holding a recent copy converts a difficult conversation into an administrative one.
It takes an hour and it is the cheapest insurance in the whole software relationship.
The other kind of lock-in
Worth naming because it is more common than the technical kind.
Process lock-in. Your programme has bent to fit the software - the rubric matches its scoring model, the pipeline matches its statuses. Leaving means redesigning the programme, not just moving data.
Knowledge lock-in. One person understands the configuration. If they leave, you cannot change anything safely, let alone migrate.
Integration lock-in. The finance system, the website and the funder dashboard all pull from it.
The defences are dull: document your process independently of the software, have two people who understand the configuration, and prefer integrations that read from an API you could point elsewhere.
Where we stand
Since this article would be worthless without it: EcoSync exports applications with per-evaluator scoring detail, funding with its full chain from source to tranche, startup records and space history, in machine-readable form, run by you rather than by us. There is a public data API with keys and access logging.
Test it anyway. That is the entire point of the article - a vendor's description of its own export is not evidence, and you should hold us to the same standard as everyone else on your shortlist.
Frequently asked questions
- What should you test before signing with any vendor?
- Run an export during the trial and open the file. Not a promise of an export, not a screenshot - an actual file, produced by you without a support ticket, containing applications with their scores, funding with its tranche history, and startup records.
- Is a PDF export enough?
- No. A PDF is a picture of your data, not your data. What you need is something a spreadsheet or another system can read - CSV or JSON - because the point of an export is being able to use it somewhere else.
- What is usually impossible to export?
- Relationships and history. Most systems will give you a list of startups. Far fewer will give you which evaluator gave which score on which criterion, or which tranche was released against which milestone with which evidence. Those are the records you cannot reconstruct.
- How often should you test an export?
- Once a year, and keep the file. It verifies the export still works after upgrades, and it means that if the relationship ever ends badly you already hold a recent copy rather than negotiating for one.
