Systems and records
Keeping a legacy ERP read-only after go-live: costs, risks and alternatives
By SourceX Editorial · Updated
Short answer
Keeping a legacy ERP read-only after go-live is the fastest way to preserve history, but it carries license, hosting, security and skills costs that grow every year it runs. Treat read-only access as a bridge with an end date, then move history to an archive platform or a documented database export that people can still search.
Key takeaways
- Read-only access is a bridge, not a retention plan; set its end date at go-live.
- Archive platforms keep history searchable without the old application, in exchange for a setup project and a subscription.
- Database or flat-file exports cost least to keep but need a data dictionary and someone who can query them.
- Unpatched servers and a single person who understands the old system are the largest hidden risks.
- Choose the replacement by the questions people actually ask the old system, not by table count.
Why do companies keep the old ERP running?#
Companies keep the old ERP running because it is the quickest way to answer questions the new system cannot: what this customer paid last time, why that order was credited, where a lot was shipped. At go-live nobody has time to design an archive, so read-only access becomes the default.
The trouble arrives later. The old system still needs a server, an operating system, a database license, sometimes a maintenance contract, and a person who remembers where things are. Those costs keep running long after the project team has moved on, and nobody owns the decision to stop them.
What does read-only access really cost?#
Read-only access costs more than the license line on the budget. The table lists the cost and risk lines a CFO or COO should expect, and who usually notices each one first.
Check the license before assuming read-only use is free. Some vendors require an active maintenance agreement or a particular license type for continued use, while some perpetual licenses allow use without support. The answer is in your agreement, not in the vendor's sales materials.
| Cost or risk | What drives it | Who usually notices |
|---|---|---|
| License and maintenance | Vendor terms that tie continued use or support to paid maintenance | CFO at renewal |
| Hosting and hardware | Old servers or virtual machines, backups and storage | IT budget owner |
| Security exposure | Operating systems and databases that no longer receive patches | Security reviews, insurers, auditors |
| Fading skills | Fewer staff who know the screens, reports and data model | Whoever gets the next audit request |
| Access control | Former users still enabled, shared logins, no MFA | Auditors |
| Silent failure | A server or database that dies with nobody watching | Whoever next needs an old record |
What are the alternatives to keeping it running?#
The alternatives are an application archive platform, a database or flat-file export, or loading old history into the new system's reporting layer. Each trades cost against how easily people can find what they need.
A common pattern for mid-size distributors is a combination: a short read-only bridge, then a documented database export with a handful of rebuilt reports for the questions people really ask, and an archive platform only where many users need regular lookups.
| Option | Cost profile | How people find records | Main risk | Best when |
|---|---|---|---|---|
| Keep the legacy ERP read-only | Ongoing license, hosting and support | Familiar screens and reports | Unpatched systems and fading skills | A short bridge with an end date |
| Application archive platform | Setup project plus subscription | Search screens and saved reports over extracted data | Incomplete extraction, a new vendor dependency | Many users need regular lookups for years |
| Database or flat-file export | Low storage cost, some setup | SQL, BI tools or spreadsheets | Undocumented tables nobody can query | Lookups are rare and IT can support them |
| History loaded into the new reporting layer | Modeling effort, no extra license | Same dashboards as current data | Mapping errors that mix old and new | Leaders want trends across both systems |
How do you decide which history people actually need?#
Decide by collecting the real questions people ask the old system, then grouping them by record type. The answer usually covers far less than the full database, which makes the replacement cheaper and the end date realistic.
- Log every question asked of the old ERP since go-live, with who asked and why.
- Group the questions by record type: customer pricing, orders and returns, vendor history, inventory movements, financial detail.
- Note whether each answer must be exact, such as an invoice copy, or approximate, such as a trend.
- Confirm retention requirements for each record type with finance, tax advisers and counsel.
- Flag records that may have value beyond lookups, such as return and exception histories for analytics or licensing.
- Set the date read-only access ends and the date the replacement must be tested.
What must an export keep to replace read-only access?#
An export replaces read-only access only if it keeps the links and meaning the application supplied. The screens knew which codes meant what, which records belonged together and which transactions were voided; raw tables do not.
Keep the internal keys that connect orders, shipments, invoices and returns. Export the code tables, such as reason codes, payment terms, warehouse codes and the user list. Write a short data dictionary for the tables people will use, and save copies of the most-used reports so their logic can be rebuilt.
Then test the export by answering real past questions with it before the old system is switched off. If a question cannot be answered, fix the export while the source still exists.
What does switching off the old ERP involve?#
Switching off the old ERP is a short project of its own, and skipping steps is how companies end up with orphaned servers or lost history. Take one final full backup and keep it alongside the export, then disable every user account and remove the system from the network.
Cancel licenses and maintenance in writing and file the vendor's confirmation. Wipe or destroy disks under your IT policy, and record the decommissioning in the system register: what was retired, where the export lives, who owns it and when it is due for review. That record is what an auditor, acquirer or buyer will ask for later.
Illustrative: a plumbing supply wholesaler sets an end date#
Illustrative: a fictional plumbing supply wholesaler goes live on a cloud ERP and keeps its old on-premises ERP read-only on a server in the back office. By the next insurance renewal, the server runs an unsupported operating system, the analyst who knew the reports has left, and the insurer's questionnaire asks about unpatched systems.
The CFO and COO review what people actually looked up: customer price history, returns with reason codes and vendor rebate records. IT exports the full database into a company-controlled SQL instance, documents the main tables and code lists, rebuilds the few reports people used and tests them on real past questions.
The old ERP is then switched off. The export is kept under a retention schedule, and its order and return history is put forward for a licensing assessment.
How SourceX views a retiring ERP#
SourceX treats a retiring ERP as a moment to assess, not only to store. Order histories, returns, service exceptions and inventory corrections can be licensable records, and they are easiest to interpret while the old system and the people who used it are still around.
The assessment starts with metadata: the system, the years of history, the record families and any restrictions, with no files shared. When a package moves ahead, SourceX never hosts multi-terabyte extracts; they remain on company infrastructure or travel on encrypted drives, with provenance and release authorization documented in the SourceX Evidence Packet.
Frequently asked questions
Can we cancel vendor maintenance and still use the old ERP?
Sometimes. Some perpetual licenses allow continued use without maintenance, while subscription and term licenses usually end access when payments stop. Read the license grant and termination clauses, and ask the vendor in writing before canceling, because losing the license can cut off even read-only use.
Is a database backup the same as an archive?
No. A backup preserves data so it can be restored into the same software, which you may not have later. An archive or export is meant to be read without the old application. Keep backups during the bridge, but build a readable export before the software goes away.
Will auditors accept an export instead of the original system?
Auditors generally want complete, reliable records they can trace, and a documented, tested export often meets that need, but expectations vary. Ask your auditors and tax advisers before switching off the old system, and keep the export's documentation and reconciliation with it.
How long should read-only access last?
Long enough to build and test the replacement, and no longer. Set the end date at go-live and tie it to milestones, such as the first year-end close in the new system and auditor sign-off, rather than leaving it open-ended.
Who should own the legacy data after go-live?
A named business owner, usually in finance or operations, with IT as custodian. Without an owner, nobody approves the end date, the retention rules or requests to use the history for analysis or licensing, and the old server simply keeps running.
Related resources
See if your company qualifies
A short company assessment. No data uploads are needed.