The cost of leaving
is set on the day you join.
Nobody evaluates software by asking how they would stop using it. The demo is about what the product does, the negotiation is about price, and the question of how a school would extract four years of its own records never comes up, because on the day you sign you cannot imagine wanting to. That is precisely why it is the cheapest moment to ask. A vendor courting a school will answer an awkward question in writing; a vendor that has already been paid for three years has no particular reason to hurry.
This is not about expecting bad faith. Most products are built by people who never intended to trap anyone, and the thinness of their export is an accident of what got built first. But the effect on you is identical whether it was designed or neglected: if getting your records out takes a developer or a fortnight of copying screens by hand, you are not choosing freely the next time you review the decision. You are choosing between the product you have and a cost you cannot face.
Four answers,
only two of them useful.
The distinction that matters is between data and documents. A CSV is data: you can open it, sort it, correct a typo in two hundred rows at once, and feed it to something else. A PDF is a document: a picture of data that a person can read and a computer cannot usefully process. Both have their place — a PDF archive of last year's registers is perfectly sensible — but a school offered only PDFs has not been given an export, it has been given a filing cabinet.
The fourth row is the one to take seriously, because it is far more common than vendors admit and it never appears in a feature list. If the only route out is an administrator copying records screen by screen, work out roughly how many hours that is for your student numbers and treat that figure as part of the price of the product. It is a real cost. It is simply deferred until the moment you are least able to absorb it.
Four categories,
and they are not equal.
Schools reliably get this order wrong, and always in the same direction: they fight hardest for the history and forget the contacts. History feels valuable because it is large and because it represents work. But ask what you would actually do with four years of imported attendance in a new system, and the honest answer is that nobody will ever open it. What you need is for it to be readable if someone asks — an archive, a PDF set, a folder of spreadsheets on your own drive — not for it to live inside the new platform pretending to be current.
Contacts, by contrast, cannot be recreated at any price. A school that loses its parent email addresses has lost the ability to tell families anything, in the specific week it most needs to. Check that the export includes the parent or guardian contacts and not only the students, because in many products those sit in a different table and are quietly left out. The curriculum sits third and is the one to test rather than trust: ask for a sample export of one course before you sign, and see what arrives.
GDPR is not the tool
you think it is.
This comes up in every discussion of school software and is almost always misunderstood, so, carefully, and with the usual caveat that this is not legal advice and your jurisdiction may add to it. The right to data portability under GDPR belongs to an individual, over their own personal data. A parent can ask for the data held about their child in a structured, commonly used, machine-readable form. That is a real and useful right, and the rights requests article covers how it works in practice.
What it is not is a route for a school to extract its entire database from a vendor. Your records as a business — your course structures, your timetable, your commercial history — are not somebody's personal data, and no data protection right compels a supplier to hand them over in a convenient format. That is governed by your contract, and by whatever the product happens to support. Schools that assume the law has their back here discover otherwise at the worst moment. Put the export commitment in the agreement, in words, with a format and a timescale, or accept that you do not have one.
Our export is real.
You cannot run it yourself.
Every claim above applies to SprintUp, so here is ours without softening. A full export of everything held about one person exists, produces a readable document, and is recorded in an audit log. A school administrator cannot run it. Today those operations sit with us as the platform operator: you ask, we produce it. There is no self-service button that hands a school its whole dataset, and we would rather write that sentence here than let you find it in the month you had decided to leave.
What this should mean for your decision is not that you avoid us, but that you ask us the same follow-up this article tells you to ask everyone: what is the turnaround, what format, and will you put it in writing. Ask our competitors too. Most of this market works the same way, and the difference between vendors is usually not the capability but whether they will tell you about it before the contract rather than after. The red flags article lists "you can export your data" among the answers that need a second question, and we put ourselves on that list deliberately.
Five sentences,
sent by email.
Spoken answers evaporate. Send it, to every vendor on the shortlist and to the one you already use, and keep the reply: Which categories of our data can we export ourselves, without contacting support? In what formats? Does the export include parent and guardian contact details, and our course and assessment content? Who runs it, and what turnaround do you commit to? And can we have a sample export of one course before we sign?
The sample is the part that separates answers from reality, and it is startling how often a confident yes becomes a qualified one when a file has to be attached. It also costs the vendor almost nothing if the capability genuinely exists, which is exactly why the reluctance is informative.