Logistics and distribution
AS/400 (IBM i) data archives: what to do before decommissioning
By SourceX Editorial · Updated
Short answer
AS400 data archiving before decommissioning comes down to five steps in order: inventory everything on the system, extract complete files with their relationships, document every field and code, settle retention with finance and counsel, and assess the history before shutdown. The rule: never power off an IBM i until the archive is tested and signed off.
Key takeaways
- An IBM i holds more than the ERP database; spool files, IFS documents, journals and saved queries matter too.
- Extract complete physical files with their keys, not printed reports, so records can be rejoined later.
- A field dictionary built from DDS source and staff interviews is part of the archive, not an extra.
- Electronic accounting records can fall under IRS retention rules for machine-sensible records.
- Assess the history before shutdown, while the system and the people who understand it are still available.
What has to happen before an AS/400 is decommissioned?#
Before an AS/400 is decommissioned, the IT team needs a complete inventory, a tested extract with relationships intact, field documentation, a retention decision and sign-off from the business. Each step depends on the one before it, and skipping ahead is how companies end up hunting for someone who can restore an old tape.
Most distributors and manufacturers reach this point after moving to a newer ERP, often leaving the IBM i running read-only for audits and lookups. The longer it sits idle, the harder the job gets: the programmer who knows the files retires, the hardware maintenance contract lapses, and nobody remembers which library holds what.
What lives on the system besides the ERP database?#
The IBM i holds far more than the ERP tables, and an archive plan should list every object type before anyone decides what to keep.
Spool files deserve a second look. Many companies relied on printed reports for month-end, credit decisions and customer statements, and those reports may be the only record of a total as it stood on the day it was run.
| Object | What it holds | Archive decision |
|---|---|---|
| Physical files | Orders, invoices, inventory, customers, vendors | Extract in full with keys |
| Logical files and views | Indexes, joins and selection rules | Document them and use them to rebuild relationships |
| Source files | RPG, COBOL and CL programs, DDS definitions | Keep; they explain business rules and field meanings |
| Spool files and output queues | Historical reports, invoices and statements | Keep those used for audits or customer disputes |
| IFS directories | Scanned documents, PDFs, EDI files, attachments | Inventory and extract with links back to records |
| Journals and receivers | Change history for journaled files | Decide with counsel; may hold the audit trail |
| Saved queries | Queries staff built and ran for years | Keep as evidence of how data was used |
| User profiles and authorities | Who could see and change what | Export a list for the audit record |
- 01Your work records
- 02Personal details removed
- 03You approve the release
- 04Licensed to AI developers
How to extract with relationships intact#
Extracting with relationships intact means exporting complete physical files with their keys and every member, not running reports or partial queries. A report shows what someone once asked; a full file lets an analyst ask a new question years later.
Reconciliation is the step teams skip under deadline pressure. Compare row counts per file and a handful of control totals, such as invoice totals by year, against the live system, and keep the results with the archive so an auditor can see the extract was complete.
- Export every physical file in the ERP libraries, including multi-member files.
- Keep primary and foreign keys exactly as stored, including leading zeros.
- Convert EBCDIC text using the correct CCSID and test special characters.
- Unpack packed and zoned decimal fields and keep their original precision.
- Convert legacy date formats and record the conversion rule used.
- Reconcile row counts and control totals against the live system.
- Save the extract with checksums and a manifest of every file.
Document every field before the experts leave#
Field documentation is the dictionary that keeps an archive readable, and it should be built from DDS source, field text and interviews with the people who used the system. Short cryptic field names and single-letter status codes made sense to the original programmers and to almost nobody since.
For each file, capture its purpose, the meaning of each field, every code value and what it stands for, which programs wrote to it, and known quirks such as a field reused for a new purpose after a modification. Interview the programmer and long-tenured users from order entry, purchasing and accounting; their explanations often decide whether a field is usable at all.
Settle retention before deleting anything#
The retention decision sets how long each record family must be kept and in what form, and it belongs to finance, counsel and the business, not IT alone. Tax is one driver: under IRS Rev. Proc. 98-25, machine-sensible records in an automated data processing system must be retained so long as their contents may become material to tax administration, at a minimum until the limitation period for each tax year expires.
Rev. Proc. 98-25 also lets a taxpayer request a record retention limitation agreement with the IRS, and it requires prompt notice and a replacement plan if such records are lost or destroyed. That is one more reason to test the archive before the system goes dark. Other drivers include contracts, warranty exposure and any legal hold.
| Record family | Retention driver to check | Who decides |
|---|---|---|
| General ledger, payables, receivables, invoices | Tax rules for electronic records and audit needs | CFO with the tax advisor |
| Sales orders and shipments | Customer contracts, warranty and dispute history | Sales leadership and counsel |
| Purchasing and vendor files | Vendor contracts and rebate audits | Purchasing and finance |
| Payroll and HR files | Employment and tax rules | HR and counsel |
| Lot and serial history | Recalls and product liability | Quality and counsel |
Choose a read-only archive format#
A read-only archive format should let users find a record without IBM i skills, and three patterns are common. Some companies keep a small hosted IBM i partition for lookups, some load extracts into a modern SQL database with a simple viewer, and some keep documented flat files with no viewer at all.
The hosted partition preserves the screens users know but keeps a dependency and a bill. A SQL database with a viewer is easier to query and to hand to auditors. Flat files are cheapest to keep and hardest to use. Whichever is chosen, keep a final full system save on separate media in separate locations as insurance.
Assess the history before shutdown#
Assessing the history before shutdown means asking whether years of orders, exceptions and returns have value beyond compliance while the system and its experts can still explain them. Older ERP records often show how a business handled backorders, substitutions, credit holds and returns over a long period, the kind of linked operating record AI developers look for.
The first pass needs only metadata: which files exist, the years covered, how records link and what customer contracts say. SourceX runs that pass as a metadata-only fit check, the start of the SourceX five-step transaction of Supply, Rights, Preparation, Approval and Delivery, and nothing leaves the company at that stage. If the history proceeds, the extract and field dictionary feed the Supply step, and the SourceX Evidence Packet traces provenance back to the original IBM i files.
Illustrative: a supply distributor retires its IBM i#
Illustrative: a fictional plumbing and HVAC supply distributor moved to a cloud ERP and kept its IBM i in read-only mode for audits. The hardware maintenance renewal is due, and the long-time RPG programmer plans to retire.
The IT director inventories every library and finds years of credit memos and return authorizations held only in spool files. The team extracts all physical files to a SQL database with a manifest and reconciled control totals, and the programmer spends their last weeks on a field dictionary. Finance and counsel set retention by record family, leadership runs a metadata-only fit check on the order, return and backorder history, and only then does the final save and power-down happen.
Frequently asked questions
Can we keep the backup tapes instead of extracting the data?
Tapes alone make a weak archive. Restoring them requires compatible IBM i hardware or a hosted partition, a suitable operating system level and someone who knows the libraries. Keep a final save as insurance, but rely on a documented, tested extract for day-to-day access and audits.
Should we migrate old history into the new ERP instead?
Usually only open items and recent history go into a new ERP, because old codes and structures rarely map cleanly. Loading decades of history creates conversion work and clutter. A separate read-only archive keeps old records intact and searchable without distorting the new system.
Who should sign off on decommissioning?
Finance, counsel, the business owners of each record family and IT. Each confirms the archive covers its needs: finance for tax and audit, counsel for holds and contracts, operations for lookups. Record the sign-off with the archive manifest so the decision can be shown later.
What about data on the system that belongs to customers?
Some distributors hold customer-provided files, such as EDI documents, specifications or consignment records, under contract terms. Identify them in the inventory, check those terms for return or destruction duties, and keep them separate in the archive so they can be handled on their own schedule.
Sources
- Rev. Proc. 98-25 treats machine-sensible records in a taxpayer's automatic data processing system as records under IRC 6001 that must be retained so long as their contents may become material to tax administration, at a minimum until the period of limitation for assessment, including extensions, expires for each tax year. Source
- Rev. Proc. 98-25 lets a taxpayer request a Record Retention Limitation Agreement with the IRS to limit which machine-sensible records must be kept, and requires prompt notice to the IRS and a replacement plan if such records are lost, stolen, destroyed or materially inaccurate. Source
Related resources
See if your company qualifies
A short company assessment. No data uploads are needed.