Legacy AS/400 (IBM i) manufacturing ERP data: archive before you retire it

Why AS/400 retirement puts manufacturing history at risk#

AS/400 retirement puts manufacturing history at risk because the data only makes sense inside the system that wrote it. Files in DB2 for i often have short, cryptic names, store dates as plain numbers in house formats, use packed decimal fields and EBCDIC character encoding, and depend on code values defined in other files or inside RPG programs.

Many manufacturers ran a green-screen ERP for decades, sometimes heavily modified. When they move to a new ERP, the project loads item masters, bills of material, routings, open orders and balances. Closed sales orders, production orders, lot history, engineering changes and quality records stay behind on a machine that the company now wants to switch off.

The people risk is as real as the technical one. The programmer who knows which file holds the real ship date, or what an order status code meant before a past modification, may be close to retirement.

The retirement checklist: extract, document, retain, assess#

The retirement checklist has four steps, and the order matters: extract before you document, document before staff leave, set retention before anyone deletes, and assess further use only once the archive is complete and readable.

Extract: getting data out of DB2 for i#

Extracting data from DB2 for i means producing two things: open-format copies that any tool can read later, and a restorable save of the original libraries in case a question can only be answered on the system itself. Neither replaces the other.

Convert character data from EBCDIC, unpack packed decimal fields, and keep date fields both in their raw form and converted, so mistakes in conversion can be checked later.

• 1List every library in use, including custom libraries added over the years.
• 2Export each physical file to CSV or a columnar format through SQL access, with the field definitions alongside.
• 3Take a full save of the libraries to save files or tape and confirm it can be restored.
• 4Export the source members of RPG, COBOL and CL programs, since business rules live there.
• 5Capture spooled reports that users relied on, as reference copies of how numbers were presented.
• 6Collect documents stored in the integrated file system, such as attachments and scanned files.
• 7Reconcile record counts and key totals between the system and the extracts.

Document: make the files readable without the system#

Documenting the files means writing down what a future reader needs to understand a table without logging into the old system. For each file, record its purpose, its key fields, what each field means, the date and number formats used, and the code tables it depends on.

Dataset documentation research offers a useful pattern. The Datasheets for Datasets paper borrows from electronics, where every component ships with a datasheet, and asks that each dataset carry one covering why it was created, what it contains, how it was collected and what it should be used for. A one-page datasheet per major file, written by the programmer and checked by a business user, is a practical version.

Note the known quirks too: fields reused for a different purpose after a modification, periods when a process was run outside the system, and records created by conversions from even older software.

Retain: keep what finance, tax, legal and quality need#

Retention needs set the minimum scope of the archive, so the CFO or controller should confirm them before anything is deleted. Tax records are one input. The IRS says to keep records supporting income, deductions or credits until the period of limitations for that return runs out, generally 3 years, with longer periods in some situations, and to keep property records until the limitations period expires for the year the property is disposed of.

Other needs often run longer. Customer contracts, product liability exposure, warranty obligations, quality and lot traceability commitments, and any legal hold can all require older records. List each need, its owner and the record types it covers, then confirm the archive holds them in a form someone can query. Retention periods are general information here; confirm the periods that apply to your company with your tax adviser and counsel.

Illustrative: a valve maker retires its green-screen ERP#

Illustrative: a fictional industrial valve manufacturer ran a heavily modified RPG-based ERP on an AS/400 for most of its history, covering order entry, MRP, shop floor reporting, quality and service. It is moving to a cloud ERP, and the implementation plan loads masters, open orders and balances only.

The CFO insists on an archive workstream. IT extracts every production library to open formats and takes a restorable save. The last in-house RPG programmer spends dedicated time writing datasheets for the order, production, lot and quality files. Finance, quality and legal sign a retention schedule, and the old hardware is retired only after test queries succeed against the archive.

Later, when warranty claims arrive for valves built before the switch, quality traces heat lots in the archive. When leadership asks whether the history could support a data license, the datasheets make the assessment straightforward.

Assess: which AS/400 history may have further value#

AS/400 history may have value beyond retention when it records decisions and outcomes over a long period. Quote-to-order history, MRP exceptions and expedites, production orders with labor and scrap, engineering change history, nonconformance and corrective action records, and service and warranty history are the record families most often worth assessing.

Age cuts both ways. Long histories add depth and show how processes changed, while recency is also a value driver, and records that are hard to decode raise preparation cost. Customer-owned drawings, pricing and export-controlled work are excluded whatever their age.

How SourceX approaches legacy ERP archives#

SourceX picks up legacy ERP archives once they are extracted and documented. Its first review is a fit check based on a description of the archive, covering modules, years and record families, with no files exchanged. SourceX never hosts multi-terabyte datasets, so an archive of that size remains on the company's servers or travels on encrypted drives if a package proceeds.

In the SourceX Enterprise Data Value Framework, long linked histories can rate well on scale, domain expertise and human-generated signal, while data cleanliness and preparation cost decide how much decoding work stands between the archive and a usable package.