Exit planning
What Happens to Your Data When You Leave a School ERP
Every school software relationship ends eventually — through growth, acquisition, or simple change. The schools that leave cleanly are the ones that settled the exit terms on the day they signed. Here is what ‘your data’ really includes, what a usable school ERP data export looks like, and the clauses to ask for in writing — from any vendor, including us.
The best time to plan your exit is the day you sign
A new school software contract is signed in a hopeful mood. The demo went well. The vendor’s team is attentive. The principal is thinking about admission season running smoothly, not about what happens in year four. So the contract gets read for price and features, and the pages about data — if they exist at all — get skimmed. Nobody negotiates the exit while they are excited about the entry. Yet that is exactly when it is cheapest to negotiate, because nobody is upset yet and nothing is at stake.
Fast forward a few years. The school has grown, needs have changed, and the management decides to move. Suddenly the questions arrive all at once. Can we get our records out? In what format? Who does the work? Who pays for it? How long will it take? And what happens to the copies the old vendor keeps? If those answers are not already written into the contract, they get settled by negotiation at the worst possible moment — after the relationship has cooled and the vendor has no commercial reason to hurry.
This is vendor lock-in — the situation where leaving a supplier is so difficult or costly that you stay even when you no longer want to. In Indian school software it is rarely malicious. Most of it is structural: nobody agreed, in writing, what ‘your data’ means, in what format it comes back, on what timeline, and at whose cost. This post walks through each of those questions in turn, and it ends with a plain list of exit clauses to ask for before you sign anything.
‘Your data’ is much more than the student list
Ask a vendor for ‘our data’ and you will usually receive the obvious tables: students, staff, classes, fee ledgers. But a school’s record is far richer than that, because the software has been quietly accumulating institutional memory for years. The parts people forget are the parts that hurt most when they turn out to be missing. Before any exit conversation — better still, before any signing — write your own inventory of what the system will actually hold. Most schools are surprised by the length of the list.
Configuration deserves special mention because it is invisible until it is gone. Configuration means the settings that describe how your school works: fee structures, concession rules, grading bands, approval chains. The rule that a sibling concession applies to the second child only, or that refunds above a limit need the trustee’s approval — someone decided each of these, and the software remembers the decision so people do not have to. That memory does not transfer by itself. Ask for a readable statement of your configuration, so decisions can be re-made deliberately rather than rediscovered through mistakes.
- Attachments and scanned documents: transfer certificates, birth certificates, income and category certificates, medical records — often uploaded once and kept nowhere else.
- Photographs: student photos, staff photos, event galleries — frequently the school’s only digital copy.
- Fee receipts and their PDFs: the ledger entries are data, but the numbered receipt documents issued to parents are records in their own right.
- Audit history — the log of who changed each record and when: your evidence in any dispute over a mark, a fee, or an admission.
- Message logs: circulars, fee reminders, and parent communication — proof of what the school told whom, and when.
- Report card templates and the marks behind them, not just the final PDFs.
- Configuration — the settings encoding years of institutional decisions: fee heads, concession rules, grading schemes, approval chains.
A database dump is not an export
When schools ask for their data, some vendors offer a database dump — a raw copy of their internal tables, in whatever structure their engineers designed for their own convenience. Technically, everything is in there. Practically, it can be close to useless. Cryptic table names mean nothing to your office staff, the relationships between tables are undocumented, and your next vendor will charge for the archaeology needed to make sense of it all. A dump satisfies the letter of ‘we gave you your data’ while quietly defeating its purpose.
A usable export is different. It arrives in open formats — file types any common software can read, such as CSV or spreadsheet files for tables and PDF for documents — with human-readable column names, one file per kind of record, and documents grouped so a receipt can be matched to its student. The opposite is a proprietary format: a file type only the vendor’s own software can open. A proprietary export is not an exit. It is a longer leash.
You do not need to be technical to test this. Ask for a sample export during the evaluation, before you sign, and open it on an ordinary office computer. If your registrar can find one student’s fee history in it within a few minutes, it is an export. If it needs the vendor’s engineer to interpret, it is a dump. Whichever standard you saw in the sample is the standard to write into the contract.
History is usually the first casualty
When a migration is scoped, current data gets all the attention: this year’s students, this year’s fee dues, this term’s marks. Older records get quietly labelled ‘archive’ and left behind. It feels like a reasonable trade at the time, because the new system has to run tomorrow morning. But schools live on history. A transfer certificate request can arrive a decade after a student leaves. An audit can ask about a fee concession granted four years ago. The old system’s answer to those questions leaves with the old system.
Audit history is even more fragile. The record itself — a mark, a receipt — usually survives a move. The trail behind it, showing who entered it, who changed it, and when, almost never does, because the new system starts its own trail from zero. If a question ever arises about an old record, that lost trail was your answer. So decide deliberately what history the school needs, take it as a readable export even if it never enters the new system, and store it somewhere the school itself controls.
Settle who pays for the export, and how long it takes
An export takes real work. Someone has to run it, check it, package the attachments, and hand everything over securely. So it is legitimate for that effort to have a cost. What is not legitimate is discovering the cost for the first time after you have given notice — when you have no leverage left and every week of delay hurts. If the contract is silent, the price of your own data becomes whatever the vendor decides it is on the day you ask.
Timelines are the same story. A school moving between systems is running a project with a hard deadline, usually the start of a term. An export that arrives months late can sink the whole migration, because the new vendor cannot load what it has not received. The fix is not suspicion; it is arithmetic done in advance. Agree at signing what an export costs — ideally nothing for standard formats — and how many days after a written request it will be delivered. Both belong in the contract, not in an email thread during the exit.
After you leave, deletion should be evidenced, not assumed
Handing you a copy is only half the exit. The other half is what happens to the copies the vendor keeps — in their live systems, in their backups, sometimes in their reporting tools. ‘We will delete it’ is easy to say and impossible to see. The practical question is whether deletion can be evidenced: will the vendor confirm in writing, at a named point in time, that your institution’s data has been removed from live systems, and state the schedule on which it will age out of backups?
This matters legally, not just operationally. Under India’s data protection law, the DPDP Act, a school remains accountable for the personal data of its students and parents even while a vendor holds that data on the school’s behalf. In general terms, that means return and deletion are not favours a vendor grants; they are part of what a school needs from any vendor in order to meet its own obligations. This is context, not legal advice — but it is a strong reason to put deletion in writing.
A fair vendor will explain, honestly, that deletion is not instantaneous. Backups exist precisely so that data is hard to destroy, and they expire on a cycle rather than on demand. That honesty is a good sign, not a red flag. What you are asking for is not magic: a written confirmation when live deletion happens, and a stated backup-expiry window after which the remaining copies are gone. Vagueness on this question is the thing to worry about — not the existence of backups.
Leaving mid-year is a different, harder problem
Most exits are planned for the summer break, when one academic year has closed and the next has not begun. A mid-year exit — forced by a contract dispute, an acquisition, or a vendor winding down — is far harder. Fee instalments are half-collected. Attendance registers are half-filled. Exams are half-conducted. The data is not a tidy archive at that point; it is a moving picture, and every day the handover slips, the copy you eventually receive grows staler and harder to reconcile.
Two habits make a mid-year exit survivable. The first is the export habit: take a full export at least once every term, even while you are perfectly happy with the vendor — which is why the right to export at any time, not only at exit, is worth confirming before you sign. The second is contract language that survives disputes: the data-return clause should hold even if fees are contested or the agreement is terminated for cause. A clause that vanishes exactly when you need it protects nobody.
The exit clauses to ask for before you sign
None of this needs an adversarial negotiation. It needs one page in the contract, agreed while everyone is still friendly. A good vendor will accept these terms readily — precisely because they rarely need to be used, and because agreeing to them signals confidence that you will stay by choice rather than by friction. If a vendor resists putting them in writing, that resistance is itself useful information, gathered at the cheapest possible time. Here is the list to bring to the table.
Notice what is not on the list: penalties, accusations, or assumptions of bad faith. Every item is something a well-run vendor already does informally for customers who ask. Writing it down simply removes the dependence on goodwill — and on the particular people in the room — because by the time you leave, the account manager may have changed twice and nobody will remember what was promised verbally at the first demo.
- Ownership: the institution owns its data, stated plainly — including uploads, documents, and photographs.
- Scope: ‘data’ is defined to include attachments, scanned documents, photographs, receipts and their PDFs, message logs, audit history, and a readable statement of configuration.
- Format: exports in open, documented formats such as CSV and PDF — not a raw database dump, and never a format only the vendor’s software can open.
- Ongoing access: the right to take a full export at any time during the engagement, not only at exit.
- Cost: the export fee, if any, fixed in the contract — with standard-format exports ideally free.
- Timeline: a stated number of days from written request to delivery of the complete export.
- Survival: the data-return clause remains in force even during a dispute or a termination for cause.
- Deletion: written confirmation when data is removed from live systems, plus a stated backup-expiry window.
- Mid-term exit: the same terms apply if either side ends the agreement early, including mid-academic-year.
Our own posture — and how to test us with the same list
SquareCampus is built as a School Operating System — a governed operating layer for institutional decisions — and our position on exit is the one this post argues for. The institution owns its data. Complete exports in standard formats are available throughout an engagement, not only on the way out. Access is role-scoped, actions land on audit trails, and data is encrypted in transit and at rest. The platform runs on AWS Mumbai (ap-south-1) with a multi-AZ design and an India-first residency posture, and it is designed to support a school’s obligations under the DPDP Act.
We also do not ask schools to rip anything out. A bounded SquareCampus deployment coexists with the existing ERP, LMS, payment portal, and identity provider, which stay authoritative for their own domains; a later rollout may consolidate selected fragmented tools when — and only when — the institution chooses. That posture only works if leaving any layer, including ours, stays cheap. Which is one more reason we hold ourselves to the checklist above rather than merely recommending it to others.
So test us with it. The security page at squarecampus.com/security/ describes the access, encryption, and audit posture; the infrastructure page at squarecampus.com/infrastructure/ covers hosting and residency; and the data processing addendum at squarecampus.com/data-processing-addendum/ carries the formal language on data handling. Bring the exit clauses to any conversation with us and ask for written answers. And if you are renewing with someone else, use the list anyway. That is what it is for.
Put the exit terms in writing — starting with ours
Read how SquareCampus approaches ownership, exports, access, and auditability — then bring the exit-clause checklist to a security review and ask for every answer in writing.