There is a particular invoice that turns up once a year in a lot of finance inboxes. Licence and support renewal for a system nobody has logged into since the migration. Somebody queries it, somebody else says we cannot switch it off because of the history, and it gets paid. Again.
I have seen a server kept alive for the best part of a decade to answer a question an auditor asks twice a year. The box was under a desk. It had a sticker on it. Nobody was entirely sure who the sticker referred to any more.
The frustrating thing is that the objection is completely correct. You genuinely cannot switch it off, because the history genuinely matters. It is the conclusion that is wrong, which is that keeping the history means keeping the system.
The short version: you do not need the old system to keep its history, you need the history to be queryable and defensible. Extract the transactional data, reconcile it back to the old system's own reports until the variance is zero, freeze it, and give it to finance as a Power BI archive with an audit pack they can hand straight to an auditor. Then decommission the original and stop paying for it. The reconciliation is the part that makes this an archive rather than a copy.
What you are actually paying for
Worth adding up properly, because it is rarely just the licence.
There is the licence or support contract itself, which is the number people quote. There is the server it runs on, whether that is a physical box, a VM somebody is paying for, or a hosted instance. There is the operating system and database underneath it, which increasingly cannot be patched, which is why your security review keeps flagging it. There is somebody's time, a couple of hours here and there, always the same person, always the one who has been there longest and will not be there forever.
And then there is the cost nobody puts on the list, which is that the knowledge is walking out of the door. When the last person who understands the old system's chart of accounts retires, the archive question gets a lot more expensive than it is today. That is the real deadline on this piece of work, and it is not in anybody's diary.
How long do you actually have to keep it
Get this from your accountant or auditor rather than from a blog, because it depends on your entity, your sector and any live disputes. But as a rough shape: six years is the number most UK finance teams work to for tax and VAT records, and plenty of things run longer than that. Contracts with long warranty or defect periods. Anything under a live dispute. Sector rules and grant funding conditions that come with their own retention terms. Product liability, in manufacturing.
Two useful consequences of asking the question properly. The first is that the retention period is finite, so this is a cost with an end date rather than forever. The second is that it is often longer than people assume, which means "we will keep the server another year and decide then" is a decision you are going to make six more times.
"Can we not just keep a database backup?"
Reasonable question, and the answer is that a backup is insurance, not an archive.
A .bak file on a NAS satisfies nobody at the point of use. To read it you need somewhere to restore it to, a database engine of the right vintage, and in most cases the application on top, because the schema was designed for the application rather than for a human. Which means the licence you were trying to cancel. Meanwhile nobody has tested the restore, and an untested backup is a strong opinion rather than a fact.
The test is not whether the data still exists. It is whether somebody in finance can answer an auditor's question from it this afternoon, without help, without a restore, and without asking IT for anything. If they cannot, you do not have an archive.
What a proper archive contains
The data itself, first: transactional history extracted out of the old system, modelled properly rather than dumped as tables, with the master data it needs to make sense. Customers, suppliers, nominal codes, product codes, all of it, including the codes that were retired in 2019 and still sit on old transactions.
Then the reconciliation, which is what separates this from a spreadsheet export. Run the old system's own reports, one last time, before it goes off. Trial balance, aged debtors, aged creditors, sales by period, per financial year. Then reproduce every one of those from the archive and compare. Variance of zero, per year, or it does not ship. That reconciliation is the evidence that the archive is the same business, not just a similar looking pile of numbers, and it is the thing you show an auditor when they ask why they should believe it.
Then the audit pack: the handful of views an auditor or an inspector actually asks for, built and ready, so that the question "did Company X pay invoice 4471, and when" takes thirty seconds rather than a panic. Drill from the summary all the way to the individual transaction, because a summary nobody can drill into is exactly the thing an auditor will not accept.
And finally the boring paperwork that makes it defensible. What was extracted, what was deliberately left behind, when it was frozen, who signed it off, and what the reconciliation showed. Two pages. Those two pages are the difference between an archive and a folder.
One more thing worth saying out loud: the archive should be frozen and read only. Nobody, including you, edits history. If a figure in the archive is wrong, the archive is wrong and gets rebuilt and re-reconciled, with a note. That rule is easy to keep on day one and impossible to introduce later.
The order of operations
Extract and reconcile while the old system is still running, always. It is tempting to switch it off and then tidy the data up afterwards, and it is the one mistake in this whole process that cannot be undone. You need the ability to run the old reports again when a variance shows up, and it will show up.
So: extract, model, reconcile to zero, build the audit pack, get finance to sign that they can answer their own questions from it, take one final backup for the file, and only then decommission. The last step is the easy one and the only one anybody remembers.
Anyway
If you are paying to keep something alive purely so the history is reachable, that is a spend with a fixed end and a fairly small fix. The Legacy System Archive is what I do for exactly this, from £1,950, or from £6,500 for the finance-grade version with the zero variance reconciliation per year. There is a live example built on anonymised ERP data in the portfolio if you would rather click around it than read about it.
Or work out what the old system costs you a year, including the server and the person, and see whether the number surprises you. It usually does.