How long should you keep a legacy ERP after go-live?

There is no single duration, and a figure quoted as a universal retention period is not a usable answer because retention periods are set per record type, per jurisdiction and per entity, and because several of them restart on an event rather than running from a fixed date. Decide it per record class instead, answering three questions for each: what must still exist, who must be able to reach it and within what time, and what must be destroyed. Keeping the whole legacy system running answers all three at once, which is why it is the default, but it is the most expensive answer and it is rarely the one any record class actually needs. Confirm each period in writing with your tax adviser and your counsel for the jurisdictions and entities you file in, record who confirmed it and on what date, and attach a review date to every class.

What is a defensible destruction certificate?

A defensible destruction certificate is a short signed record, created at the moment data is destroyed, that names seven things: the data class destroyed, the system or medium it was held on, the date and time, the method used, the volume or record count, the retention rule and review that authorised the destruction, and the person who approved it. It is the evidence that destruction followed a schedule rather than convenience, which is the distinction that matters if the destruction is questioned later. Two rules make the certificate meaningful. Destruction never proceeds while a legal hold or an open assessment covers the class. And the certificate is filed where it survives the system it describes, because a certificate stored inside the archive it destroyed cannot be produced.

Do you have to keep the old ERP running to satisfy an audit?

Usually no. What an auditor or a tax authority asks for is the record and the ability to read and test it, not the application that produced it. That is satisfiable by an extract plus the schema, the code and description lists, and the stored documents, provided the extract can be searched and totalled and reconciles to the closing balances you filed. Some rules do speak to the form electronic records must be kept in, and they tend to describe an extract rather than a running application. United States Revenue Procedure 98-25 asks that records reconcile with both the books and the return, and that each retained file carry its record layouts, file descriptions and field definitions including the meaning of every code used to represent information. Canada Revenue Agency Information Circular IC05-1R1 requires records kept electronically to be retained in an electronically readable format even when hard copy is available, meaning a copy the agency can process on its own equipment in a non-proprietary, commonly used interchange format. Check the current version of each, and your own jurisdictions, with your adviser rather than relying on a citation copied from a secondary source.

erpification.com · the definition, and the service

Erpification / Guides / Should you keep the old system readable?

Should you keep the old system readable?

You are not deciding how long to keep the old system. You are deciding, per record class, three things: what must still exist, who must be able to reach it and how fast, and what must be destroyed. Answered that way, the decision gets a dated calendar instead of a shrug.

Guide · updated 2026-10-17

On this page

The default is a decision nobody made
Three questions, per record class
Four ways to keep it readable, and what each costs
The clock register: what restarts a retention period
What “readable” means to an auditor
The read log
The twelve-month review gate
The destruction certificate
The shutdown calendar
What goes wrong, and its cause

The default is a decision nobody made

Most companies decommission a legacy ERP by not decommissioning it. The server stays up, the licence renews, two people keep their logins, and the question of what to do with it moves to next year. Nobody chose that. It happened because the only answer available at cutover was a number copied off a web page: keep everything seven years, or ten, or longer, and decide later.

That number is the first thing to put down. Retention periods are set per record type, per jurisdiction and per entity, and several of them do not run from a fixed date at all, so a single figure quoted as near-universal cannot be true of all of them at once. This guide gives you instead the three decisions a number of years is pretending to make, and a gate that forces them to be revisited while the knowledge is still in the building.

One thing is worth doing on the day the cutover freeze ends, before any of the rest. Make the legacy system read-only, for everybody, including the finance team. A writable legacy system produces corrections that exist in one system and not the other, and no reconciliation afterwards will tell you which version is right. That belongs in the window itself, alongside the configuration freeze described in the cutover runbook, which sets the rollback deadline from the first irreversible emission.

Three questions, per record class

A record class is a type of record, not a module and not a database. “Finance” is not a class. “Posted journals” is, and so is “supplier invoice images”, because the two have different clocks, different readers and different destruction rules. Splitting by module is the most common mistake here, and it is what causes personal data to sit inside a class kept for tax reasons.

Build one row per class. The three columns are the whole decision.

Record class	Reachable by whom, how fast	Set the period from
Posted general ledger and journals	Controller and external auditor, within days	The statutory book-retention rule for each entity, confirmed in writing by your adviser
Tax filings and supporting workpapers	Tax adviser, within days, in a form that can be totalled	The assessment and reassessment windows for each jurisdiction, plus any open assessment
Customer invoices and credit notes, as issued	Credit control and any customer who disputes, same day	The longer of the tax rule and the limitation period for a contract claim
Supplier invoices and payment files	Payables and the auditor, within days	The tax rule, plus any supplier dispute or recovery audit under way
Bank statements and reconciliations	Controller, within days	The statutory rule, and the oldest unreconciled item
Payroll and employment records	HR only, and only on a named request	Employment and payroll rules, plus the limitation period for an employment claim
Inventory and stock movement history	Operations, within a week, in aggregate	Costing and audit need, not a statute, in most cases
Serial, lot and warranty history	Service desk, same day, by serial number	The longest warranty or service obligation still live on a unit in the field
Quotes, pipeline and CRM notes	Sales, if at all	Commercial usefulness, which is short, and privacy rules, which may be shorter
System audit trail and user access logs	Internal audit, within a week	The audit scope that may still cover the period the log describes
Free-text notes containing personal data	Nobody, by default	A minimisation rule: destroy unless a named class above requires the record

Two notes on how to fill that third column. Name the rule, the jurisdiction, the entity, the adviser who confirmed it and the date they confirmed it. An unattributed period is the same problem as the number you just discarded. And where the honest answer is “no statute, we keep it because operations want it”, write that, because it is the class the read log will later settle.

Four ways to keep it readable, and what each costs

The choice is usually posed as keep it or kill it. There are four forms in between, and each answers the reachability question differently. Pick the cheapest form that satisfies the readers named in your table.

Form	What it preserves	What it costs, and what breaks
Live read-only instance	Everything, including reports, drill-down and the stored documents, exactly as users remember it	Licences, hosting, the operating system and database patches, and an access review. Breaks the first time a vendor ends support or a dependency can no longer be patched
Powered-off virtual machine	The same, in principle	Cheap to store and expensive to prove. Needs a restore rehearsal at least yearly, with the date recorded, or it is an untested assumption. Breaks on licence keys, dongles and activation servers that no longer answer
Extract plus schema	The rows, if and only if you also keep the table definitions, the code and description lists, the keys between tables and a written note of what each flag means	The work of documenting it, done while the people who know are still available. Breaks when the extract is taken and the code lists are not, which is the single most common archiving failure
Rendered document archive	The documents as they were issued: invoices, credit notes, statements, remittances, as searchable files with an index	Storage and an index that is maintained. Breaks for anything analytical, because you cannot re-total a question nobody printed
History loaded into the new ERP	Whatever you loaded, in the system people already use, with no second login to remember	Mapping work, and a risk of its own: loaded history that does not reconcile pollutes the new system's reports. Load it as a separate, clearly marked source or not at all

Most companies end up with a mix, which is correct: a document archive for anything a customer or an auditor might ask to see, an extract plus schema for the ledgers and subledger detail, live read-only access for the finance team through their first full year, and nothing at all for the classes with no statutory clock and no reader. What makes the mix defensible is that each class was assigned a form on purpose. The work behind the loaded-history option is the work described in the data migration checklist, which sets the loading order and the reconciliations that must tie; history is the part of it most often deferred without anybody deciding to.

The clock register: what restarts a retention period

The reason a flat number of years fails is that some clocks do not start when the transaction posts. They start on an event, and some of them restart. Keep one short register of live clocks, with the class each one attaches to and the date it is next expected to expire.

Statutory clocks

aBook and record retention, per entity and jurisdiction
bAssessment and reassessment windows
cPayroll and employment record rules
dSector rules, where you are in a regulated sector

Event clocks, which override everything above

eA legal hold or anticipated litigation
fAn open audit, assessment or objection
gA grant, subsidy or credit subject to later verification
hA warranty or service obligation still live on a unit
iAn insurance claim, or a period an insurer may examine
jA sale, financing or diligence process in progress

Counter-clocks, which shorten rather than extend

kPrivacy minimisation: personal data kept no longer than its purpose
lA deletion request already accepted
mA contractual undertaking to a customer to delete their data

A legal hold is not a row in a table. It is a stop. While one is live on a class, no destruction of that class proceeds, the review date is pushed, and the reason is written in the register. This is also the sentence that makes the whole scheme safe: an organisation that destroys on a documented schedule, and demonstrably stops the schedule when a hold lands, is in a far stronger position than one that kept everything and cannot say why it still has what it has.

What “readable” means to an auditor

The practical test is narrower than the fear. An auditor or an authority asks for a record and for the ability to read it, search it, total it and tie it to what you filed. An extract with its code lists and its documents passes that test. The application that produced it is rarely the thing being asked for.

There is real law about the form electronic records must be kept in, and two instruments describe an archive more precisely than most archiving plans do.

In the United States, Revenue Procedure 98-25 covers records held in an automatic data processing system. Two of its requirements are worth lifting out. On reconciliation, it says machine-sensible records support and verify a return “only if they reconcile with the taxpayer's books and the taxpayer's return”, and it wants that shown in two directions: record totals by account against the account totals in the books, and against the return. That is the second of the three questions below, written as a rule. On documentation, for each retained file it asks for the record formats or layouts, the file descriptions, and the field definitions “including the meaning of all ‘codes’ used to represent information”, plus the chart of accounts and the account descriptions. An archive keeps the rows; that paragraph is what makes the rows mean anything, and it is the extract-plus-schema row of the table above restated as an obligation.

In Canada, the Canada Revenue Agency's Information Circular IC05-1R1, Electronic Record Keeping, sets out subsection 230(4.1) of the Income Tax Act: records kept electronically must be retained in an electronically readable format for the prescribed period “even when hard copy is available”. The circular defines that format as a system able to produce an “accessible and useable” copy, meaning one the agency can process on its own equipment with its own software, in a non-proprietary, commonly used data interchange format.

Two design consequences follow. Printing the archive does not discharge the obligation, so the paper set is a convenience and never the plan. And a proprietary backup or a dormant virtual machine answers a rule written around a commonly used interchange format badly, which is the strongest argument available for the extract over the powered-off instance.

One caution, because the secondary sources get this wrong. Rev. Proc. 98-25 dates from 1998, where it reaches depends on facts about your own entity, and these are two jurisdictions out of however many you file in. Verify the current version and your own jurisdictions with your adviser before you design around either. Copying an old citation because everyone else does is how a retention policy acquires a footnote nobody has checked.

Three questions settle most of the rest. Can you produce a named document from the archive without the old application? Can you total a class and tie that total to the closing balance you filed? Can you show which code in the extract means what, from a list written at the time? Three yeses mean the form you chose is probably sufficient. The chart those totals tie to is the subject of which chart changes are free, forward-only or never reversible.

The read log

Here is the part almost no retention policy has, and the part that makes the rest reviewable. Turn on a read log the day the archive goes live, and keep it for the life of the archive. One line per access: the date, the person, the class they opened, and one short free-text reason. Four or five fields, no workflow, no approval step. If access is through a read-only instance, the log is a report from the system. If it is through an extract on a share, the log is the share's own access log plus a sign-out sheet for anything downloaded.

The log exists to turn an argument into evidence. Every decommission meeting contains somebody saying the team cannot possibly manage without the old system. That claim is either true or it is a habit, and twelve months of log settles which. It also answers the quieter question of who still has access: people leave, and their logins do not.

Two refinements earn their keep. Log the class, not just the login, because “eleven reads” is useless and “eleven reads, all of them supplier invoice images, all by payables” is a decision. And log the reason in the reader's own words, because the reasons tell you which classes to move into the new system permanently instead of archiving at all.

The twelve-month review gate

Every class gets a review date, twelve months from the day the archive opened. The gate is a short meeting with the log in front of it, and it has exactly three outcomes.

Twelve months on. For this class, what do the log and the clock register say?

Zero reads, no live clock

Destroy, on a documented schedule

Put it on the shutdown calendar with a date, destroy it on that date by the stated method, and file the certificate. This is the branch that stops the archive growing for ever.

Reads, no live clock

Downgrade the form, re-date the review

The class is used, so it stays. Move it to the cheapest form the actual reads need, usually from a live instance to a document archive, and set a new review date twelve months out.

A live clock

Keep, with the clock's own date

The review date becomes the clock's expected expiry, named in the register: the assessment that closes, the hold that lifts, the last warranty unit that ages out. Not twelve months, and not for ever.

The gate is the whole argument of this page. It converts “keep everything, decide later” from a default into an explicit, dated calendar, and it makes the cost of keeping something visible to the person approving it. It is also what makes the destruction defensible later: the question that gets asked is not “why did you destroy this?” but “did you destroy it under a schedule, or when it became inconvenient?”

Run the first gate at twelve months, not at thirty-six, for one reason: at twelve months the people who built the extract are still reachable, the schema notes are still accurate, and a gap can still be filled. At thirty-six the archive is a box nobody will open and nobody will sign to destroy.

The destruction certificate

One page per destruction event, signed, with seven fields. Nothing here is onerous, and all of it is unavailable after the fact.

Class destroyed, in the same words the retention table uses.
Where it was held: system, server, medium, cloud location, and every copy including backups.
Date and time.
Method: deletion and overwrite, cryptographic erasure with the key destroyed, physical destruction, or the provider's documented process, named.
Volume: record count or size, so the certificate describes something specific.
Authority: the retention rule, the review that reached this outcome, and the date of that review.
Approver: one named person who signed, by role as well as name.

Two rules make the certificate worth having. Backups count as copies, so a certificate that ignores the backup rotation is inaccurate on the day it is signed. And the certificates are filed somewhere that outlives the system they describe, with the retention table and the clock register beside them. A certificate stored inside the archive it destroyed cannot be produced.

The shutdown calendar

The output of all of the above is not advice. It is a dated list, short enough to live on one page, that someone owns.

Freezelegacy read-only, last day of cutover
Classifyrecord classes, readers, clocks
Choose a formcheapest that serves the readers
Log readsfrom the day the archive opens
Month 12 gatedestroy, downgrade, or re-date
Certifysign, file, set the next date

Dates, not durationsEach step has an owner and a calendar date. The only step with a fixed interval is the gate, and after the first one its interval is set by the clock register rather than by habit.

Give the calendar to the person who owns the close, not to the project. Projects end, and this does not. The handover belongs in the deferred list that comes out of hypercare, which ends on a condition rather than a date, because an archive with no owner is the same object as no archive at all.

What goes wrong, and its cause

Six failures, each with the mechanism that produces it. All six are decided before they happen.

Symptom	Cause
Nobody can read the extract when it is finally needed	The rows were extracted and the code lists, key relationships and flag meanings were not. The extract is readable; the data is not interpretable
The thing asked for is the attachment, not the row	Scans and emailed PDFs lived outside the database, on a file share or in the mail system, and were never in scope. Inventory the document store as its own class
A licence renewal arrives for a system in use by two people	Keeping the instance alive was never a decision with a cost attached to it, so no gate ever compared the cost with the read log
Two versions of a corrected invoice exist	Legacy was left writable after cutover. Correct the correction in the new system only, and read-only the old one on day one
Everyone insists the archive is essential and nobody can say which part	No read log. The claim cannot be tested, so the expensive form is renewed by default
Personal data turns up in a class kept for tax reasons	Classes were drawn by module instead of by record type, so free-text notes and contact history travelled with the ledger

None of this is a technology problem, which is the point it shares with the four outcomes traced back to the gate where each was decided. The archive is where an implementation's last unmade decision goes to wait, and twelve months is how long it waits before the knowledge needed to make it has left the building.

Before any of thisIf the move itself is still open, start with the readiness check, twenty scored statements that say when the honest answer is no, or with why headcount does not predict system class, which describes the middle path vendors leave out of the comparison.