Switching Systems: Writing Your Exit Plan First
The questions to ask about leaving are the ones you have most leverage over before you join, and least appetite for once you have. What a real exit looks like, what almost no SME vendor can give you — including us — and the four things to write into the arrangement while you are still a prospect.
Nobody negotiates their exit at the start, because it feels like planning a divorce during the engagement. It is the opposite: exit terms are the cleanest possible signal about how a vendor thinks. A vendor comfortable telling you exactly how you would leave is a vendor who expects to be kept for reasons other than difficulty.
And you will need it. Businesses outgrow systems, get acquired, change sector, or find that the thing they bought for inventory cannot do the manufacturing they moved into. Switching is normal. Being unable to switch is a position you were placed in, usually by not asking four questions.
What an exit actually requires
The two halves of leaving a system
What you need out
To operate on day one somewhere else
- Master data — items, customers, suppliers, assets, employees — as spreadsheets with every field, not a printable report.
- Open positions — unpaid invoices, unpaid bills, open orders, current stock — because these become the new system's opening balances.
- Transaction history for the periods a regulator or auditor can still ask about.
- Attachments. Delivery notes, supplier invoices, contracts, employee documents. Almost always forgotten, and almost always the part that cannot be reconstructed.
- The audit trail, if you operate anywhere that an access history matters.
What you have to prove afterwards
Which is a separate job from extracting
- That the extract is complete — record counts checked, not eyeballed.
- That what you extracted loads into whatever comes next, tested before you stop paying.
- That the old data was deleted when it should have been, or retained if you are obliged to retain it.
- That somebody still has the credentials, three months later, when a question arrives.
The overlap you should pay for
- Keep the old subscription running for one month past cut-over. It is the cheapest insurance in the whole exercise.
- Do the extract twice — once as a rehearsal, once for real, on a date.
The four questions, and what a straight answer sounds like
Ask every vendor, including this one, before you sign
You are not scoring the capability. You are scoring how quickly and specifically the answer comes.
Is there one button that exports everything?
Make them prove it: Ask them to show it. Not describe it — show it, in the product, in the meeting.
Do attachments come with the export?
Make them prove it: Ask specifically about files, separately from records. The two are almost never handled by the same mechanism.
How long do you keep our data after we leave, and can you prove deletion?
Make them prove it: A number of days, and whether you get anything in writing at the end of it.
Who does the extract — you, or a support ticket to them?
Make them prove it: If it is a ticket, ask the turnaround and whether it is chargeable. Both answers will be worse in the month you actually leave.
Our own answer, which is not the flattering one
What AWRA OpsHub does today
- Every list and report exports to CSV and PDF, per module, including the reports that carry your operational history.
- A per-user data export covering the personal data held about an individual, which is what a subject access request actually needs.
- A document vault with checksums and access logging, so the files exist as first-class records rather than loose uploads — and you can see who read what.
- The API, which is a genuine route to a bulk extract if you or your developer are willing to use it.
- Soft deletes and a trash window, so a deletion during a messy migration is recoverable rather than final.
What it does not do
- No single full-tenant export button. A migration-grade extract of everything is assembled from module exports — it is manual work, and we would rather you knew that now.
- No automated bulk export of attachments. Files come out individually or through the API.
- No per-record retention override, and no certificate of destruction issued at the end of a retention period.
- No scheduled or standing export you could use as a continuous backup of your own data.
This is a real gap and it is on our own list as one. We are stating it because the alternative — letting you find out in the month you leave — is how vendors earn the reputation the whole category has. If a full-tenant export matters enough to you to be a condition, say so; it is the kind of thing that gets built when a client asks in writing.
What to write down while you are still a prospect
Four sentences, in whatever the arrangement is. None of them is unreasonable and none of them costs a vendor anything if they are honest.
- Data ownership. Your data is yours, in plain words, not implied by silence.
- Extract on request. Machine-readable, all modules, within a stated number of working days, at a stated cost — including zero if that is the answer.
- A post-termination window. Access continues for a stated period after you stop paying, so you can extract without a deadline and a grudge in the same fortnight.
- Deletion on confirmation. What happens to your data afterwards, and whether you are told when it is gone.
The tell that matters most
How long the vendor takes to answer question two — do attachments come out. Records are the question everyone has prepared for; files are the one that separates a considered answer from a rehearsed one. If the reply is a confident yes with no detail, ask which format and where the file names come from.
The migration in the other direction
When you are the one arriving, the same reality applies in reverse: whatever the previous system gives you will be less than you expected, in a shape nobody designed for loading. Which means the practical exit plan is not "get everything out" but "get out what the next system can take in" — and that is a smaller, more achievable list.
It is also why what to migrate and what to abandon is worth reading alongside this: the discipline of leaving behind closed transactions and dead master data applies with more force when you are leaving a system than when you are leaving a spreadsheet, because a system has accumulated far more of both. And data exit, retention and deletion covers the obligations side — what you must keep, and for how long, whichever system you are in.
Our take
Ask the four questions in the first meeting and judge the speed of the answers rather than their content. Write down data ownership, extract on request, a post-termination window and deletion confirmation. And ask specifically about attachments, because that is where almost every SME vendor in this market — us included — is weaker than their answer implies.
Ask us the exit questions first
We will answer all four in the first meeting, including the one where the honest answer is that a full-tenant export is manual work today. It is a better basis for a long relationship than discovering it in the month you leave.
See plans & pricingFrequently asked questions
What should we ask a vendor about leaving before we sign?
Four things: is there one button that exports everything, do attachments come with it, how long do you keep our data after we leave and can you prove deletion, and who actually performs the extract. Judge the speed and specificity of the answers rather than their content — records are the question every vendor has prepared for, attachments are the one that separates a considered answer from a rehearsed one.
Can we export everything from AWRA OpsHub?
Every list and report exports to CSV and PDF per module, there is a per-user personal data export, and the API is a genuine bulk route. What does not exist is a single full-tenant export button, so a migration-grade extract of everything is assembled from module exports and is manual work. There is also no automated bulk export of attachments. Both are on our own gap list.
Why do attachments matter so much in an exit?
Because they are the part that cannot be reconstructed. A stock figure can be re-counted and a customer list can be rebuilt from invoices, but a signed delivery note, a supplier invoice, a contract or an employee document exists once. They are also handled by a different mechanism from records in most systems, which is why "yes, you can export everything" is often true of records and not of files.
What should be written into the arrangement?
Data ownership in plain words; an extract on request that is machine-readable, covers all modules, and has a stated turnaround and cost; a post-termination access window so you are not extracting against a deadline; and what happens to your data afterwards, including whether you are told when it is deleted. None of these costs an honest vendor anything.
How long should we keep the old system running after switching?
One month past cut-over, paid for. It is the cheapest insurance in the exercise — the questions that need the old system almost always arrive in the first three weeks, and re-subscribing to answer one of them costs more than the month did. Do the extract twice as well: once as a rehearsal, once for real, on a date.
Do we get a certificate confirming our data was deleted?
Not from us — there is no proof-of-destruction certificate and no per-record retention override, and the shipped retention policies cover logs and operational telemetry rather than live business records. If a deletion certificate is a requirement in your sector, raise it explicitly with every vendor you evaluate, because it is a common assumption and an uncommon feature at this end of the market.
