ERP Archiving: The Complete Guide to Archiving a Legacy ERP Application (2026)

Every ERP migration leaves a system behind. The new platform takes open items and a few years of balances; the old Lawson, PeopleSoft, Oracle EBS, SAP, or JD Edwards instance keeps everything else — often twenty years of payroll, GL, AP, and procurement history — and someone in IT owns it until it’s dealt with.

ERP archiving is how you deal with it. This guide covers what an ERP archive has to contain, where it should live, how to secure and validate it, what the retention rules require, and how to actually turn the legacy system off. It’s written for the IT director or application manager who has the old system on their list.

What ERP archiving actually means

An ERP archive is a complete, read-only copy of a retired ERP application that people can use without the ERP. Three words in that sentence do the work:

Complete. Every table, every year, plus the things that aren’t tables: attachments, comments, and the security model. Partial archives (“just the important tables”) fail the first time someone needs a record that wasn’t on the list.

Read-only. Nothing transacts in the archive. That’s what makes it cheap: no application servers, no batch jobs, no patching, no database license.

Usable without the ERP. The AP clerk, payroll specialist, HR generalist, and auditor can find what they need through a search interface, not a SQL prompt. This is the difference between an archive and a backup, and it’s where most projects cut corners.

Three ways to store archived ERP data

On-premises copy of the database. Keep a read-only instance of the ERP running, or restore the database somewhere and point reporting tools at it. Full control; also full cost — database licensing, servers, patching, an administrator, and audit scope — for a system nobody transacts in. Most organizations that “archive” this way are really just keeping the ERP alive.

Data lake export. Copy the tables to cloud object storage (S3, Azure Data Lake) as Parquet or CSV, and query with Athena, Synapse, or similar. Cheap to produce and useful raw material if you have a data engineering team. But the export drops the security model, the attachments, and the reports, and it requires SQL to use. See data lake export vs. application archive for the full list of what’s missing.

Application archive. The data lake export with the application layer put back: a searchable web interface, role-based security that mirrors the ERP’s, the standard inquiries and reports, attachments linked to their records, and sign-on through your identity provider — deployed into a cloud account you own. This is what APIX is, and it’s the model this guide assumes for the rest of the way.

What to archive: the checklist

1. All transactional tables, all years — including the history tables that purge jobs have been writing to (in Lawson, APAPIHIST, QUARTWAGE, and the rest of the *HIST family).
2. Master and code tables — the small tables that turn codes into names. Without them the archive is a pile of IDs.
3. Attachments and comments — scanned invoices, offer letters, PO documents, stored in the ERP’s attachment structures and linked to their parent records.
4. The security model — which roles could see which companies, process levels, business units, or accounting units. It has to be reproduced in the archive, especially for HR and payroll data.
5. The standard lookups — vendor payment history, employee pay and job history, GL account detail by period, PO and receiving history. Delivered, not left as an exercise.
6. Validation evidence — row counts and checksums per table, captured at load, so the archive is defensible in an audit.

If you’re archiving Lawson specifically, our Lawson 10 data dictionary lists every table and field, and this post covers which Lawson tables people actually ask about.

Where the archive should live

In a cloud account you own — not the vendor’s. It’s the answer to every hard question:

• Security review: the archive runs under your existing IAM, logging, encryption, and network controls.
• Access: sign-on through your SAML provider; offboarding in AD offboards the archive.
• Vendor risk: if the vendor disappears, the data is still in your account in an open format.
• Cost: you see the actual cloud consumption — for a multi-terabyte archive queried a few hundred times a month, usually a few hundred dollars a year.
• Exit: leaving the vendor is stopping the subscription. There’s no export because the data never left.

Retention: how long, and what rules apply

Long enough that “keep everything” is the practical answer. The floors: IRS employment-tax records four years; FLSA payroll three; ERISA benefits six; HIPAA documentation six (45 CFR 164.316); CMS cost-report support five, Medicare managed care ten; SOX audit workpapers seven; state public-records schedules seven to permanent. The archive has to satisfy the longest rule that applies to each record type, and the incremental cost of keeping 2003 alongside 2023 is close to zero. Full breakdown: retention requirements by industry.

Securing the archive

Two requirements, both non-negotiable for payroll and HR data:

• Role-based access that reproduces what the ERP enforced. An HR partner sees her population; a plant controller sees his accounting units. A data lake export with bucket-level permissions fails this test.
• Authentication through your identity provider. No local user list on the archive.

Ask the vendor for their SOC 2 report — the report, not a statement — and for where the data physically lives.

Validating the archive

Before the source is shut off, not after. Row counts per table, checksums, and a validation report kept with the archive. Then a human test: twenty records your users know — specific invoices, checks, employees — found in the archive by the people who’ll use it.

The decommission

1. Final snapshot after the last transaction in the old system.
2. Validation as above.
3. Written sign-off from AP, payroll, HR, and finance.
4. Logins disabled; 30-day observation.
5. Servers, database licenses, and hosting cancelled; DR plan and retention schedule updated to point at the archive; destruction certified if a hosting provider was involved.

With an application archive the load-to-decommission window is weeks, not quarters — APIX runs about 30 days from kickoff to a decommissionable source system.

What it costs, and what it saves

A read-only legacy ERP kept alive typically costs $200K–$500K a year all-in (hosting, database licensing, an administrator’s time, audit scope). An application archive is typically under $75,000 a year on a three-year term. Details: the real cost of keeping a legacy ERP alive.

Choosing a vendor

Ten questions that separate an archive from a data dump — ownership, completeness, security, sign-on, usability, validation, format, total cost, timeline, exit — are in 10 questions to ask an ERP archiving vendor.

Where to start

List who still logs into the legacy system and why. Get the hosting and support invoices. Pull the retention schedule. Then book a discovery session — we’ve archived Lawson, PeopleSoft, and Oracle environments for organizations from Mayo Clinic and Boston Medical Center to DC Water and Pacific Life, and we’ll tell you what we’d keep, what we’d drop, and what it would take.