AS/400 decommissioning—more accurately, retirement of applications running on IBM i—preserves the business records, reports and evidence an organization still needs while removing dependence on the legacy application and platform. Success requires understanding IBM i objects and application behavior, not merely exporting Db2 tables.
AS/400, iSeries and IBM i: terminology matters
AS/400 and iSeries are earlier platform names that remain common in business and search language. IBM i is the current operating system in this lineage and runs on IBM Power. A “legacy AS/400 application” may therefore be a long-lived RPG, COBOL or packaged application running on a much newer IBM i environment.
Decommissioning scope should name the actual operating-system release, hardware or hosting model, application, libraries, database objects, integrated-file-system content and connected services. Do not infer age or support status from the AS/400 label alone.
Why IBM i retirement is more than a database extraction
IBM i organizes resources as typed objects. Application libraries may contain programs, service programs, physical and logical files, data areas, data queues, job descriptions, output queues and other dependencies. IBM explains that physical files store application data, while logical files can present one or more physical files in different sequences and formats. Database files can also contain multiple members.
Business evidence may exist outside relational rows: spooled files, stream files in the integrated file system (IFS), images, generated forms, data areas, message queues or external document repositories. Record meanings may be embedded in DDS definitions, RPG/COBOL code, copybooks, value tables or custom display programs. Extracting only SQL-visible tables can therefore omit required context.
Start with an IBM i application dependency map
| Layer | What to inventory | Why it matters |
|---|---|---|
| Libraries and objects | Application libraries, object types, owners, authorities, creation/change details and library-list behavior | Objects with the same name can exist in different libraries; resolution may depend on the library list |
| Db2 for i data | Physical files/tables, logical files/views/indexes, members, keys, constraints, triggers, aliases and SQL schemas | Files and members may encode partitions, companies, years or environments |
| Programs and rules | RPG, COBOL, CL, SQL, service programs, modules, job descriptions and configuration data | Code and objects may supply labels, calculations, status meanings and navigation |
| Content and output | IFS directories, document stores, output queues, spooled files, forms and images | Invoices, statements, job logs and operational evidence may not reside in business tables |
| Operations | Batch jobs, job scheduler, subsystems, data queues, journals, interfaces, replication, tape/save procedures and monitoring | Hidden dependencies can keep the platform operationally necessary after users move |
| Access | User profiles, group profiles, authorization lists, adopted authority, menu security and external identity controls | Historical access must not flatten the source system’s security boundaries |
Define the business records to preserve
Map files and objects into recognizable business entities: orders, shipments, invoices, payments, inventory movements, work orders, policies, claims or manufacturing records. For each entity, identify headers, lines, codes, descriptions, dates, organizations, related transactions, notes and supporting output.
Pay special attention to multi-member physical files. IBM documents that members are separate sets of records sharing a file format. A member name or library can carry business meaning—such as company or fiscal year—that is not present in each row. Preserve that provenance explicitly.
Save media is recovery, not routine historical access
IBM i save and restore capabilities can preserve databases, libraries and related objects for recovery. IBM documentation describes save files and media as copies in a special format that are restored before system users access the information. That is important for recoverability, but it is not a substitute for searchable business access after decommissioning.
Before shutdown, define the long-term recovery position separately from the historical-data service. Document compatible restore requirements, encryption keys, media ownership, test history, software entitlements and the people able to execute recovery. A backup that cannot be interpreted or restored under realistic future conditions is weak retirement evidence.
Spooled files and the integrated file system
IBM describes spooled files as stored output awaiting later processing or printing. In long-running applications, they may contain invoices, statements, labels, reports or job evidence that users regard as the official historical output. Inventory output queues, retention practices, external spool-management products and forms resources; then determine which output is a record and which is transient.
Also inspect IFS paths, QSYS.LIB access, shared folders, content-management products and interface landing areas. Connect retained files to the relevant business records where possible, preserve filenames and metadata, and record gaps rather than implying completeness.
A controlled IBM i decommissioning method
1. Establish platform and application scope
Record the IBM i release, partitions, ASPs or independent ASPs, application libraries, packages, source availability, database footprint, IFS paths, output queues, interfaces and operational tools. Separate the application being retired from other workloads sharing the partition.
2. Capture user tasks and statutory evidence
Ask business teams to demonstrate the exact inquiries, reports and print outputs they still use. Record selection parameters, screen meanings, drill paths, calculations and access restrictions. Screenshots are helpful discovery evidence but do not replace structured mappings.
3. Resolve objects into business context
Map physical files, logical files, members, reference data and output to approved business objects. Use metadata, source definitions and knowledgeable users to decode short field names, packed decimals, century indicators, blank/null conventions and application-specific status values.
4. Extract consistently
Choose a transactionally appropriate point in time. Account for active jobs, commitment control, journals and interfaces. Use repeatable runs and log source library, file, member, selection criteria, extraction time and transformation version.
5. Reconcile and test
Compare counts by library, file, member, organization and period; control totals for quantities and amounts; key relationships; code translations; document or spool inventories; and representative source reports. Business owners should validate complete scenarios, not isolated rows.
6. Cut over and isolate
Stop or redirect interfaces and scheduled jobs, control final updates, run the approved delta, remove routine user access and monitor for unexpected dependency calls. Maintain a rollback decision window appropriate to the program.
7. Authorize shutdown
Retire the agreed application services, credentials, network paths, monitoring and support processes only after acceptance. If other applications share the partition, isolate rather than indiscriminately retire shared platform components.
Validation and shutdown evidence
An audit-ready retirement package should identify what was preserved, excluded and disposed of. It commonly includes:
- approved application, library, file, member, IFS and output scope;
- source-to-historical mappings and code translations;
- extraction logs, point-in-time boundary and delta history;
- record-count and financial or quantity reconciliations;
- relationship, attachment and spooled-output test results;
- exceptions, risk acceptance and business sign-off;
- retention, legal-hold and access-control decisions;
- interface closure and dependency-monitoring results;
- backup/recovery disposition and final shutdown authorization.
Historical reporting without green-screen dependency
The goal is not to reproduce every display file. Give authorized users familiar search keys, readable labels, business-object views, related-record navigation, retained documents and reconciled reports. Preserve the original library/file/member and record identifiers as lineage, while presenting the history in business language.
Where a legacy report calculates values in RPG or COBOL, decide whether to preserve the original output, reimplement the calculation, or expose the underlying transactions. Any replacement calculation should be documented and tested against representative source results.
Retention, legal holds and disposition
Apply approved rules by record class and relevant business event. Consider personal information in customer, employee and supplier records; legal holds; access by company or geography; and deletion dependencies between related records and output. Indefinite retention should be an explicit decision, not the accidental result of keeping a partition powered on.
How ArchiveHub supports IBM i application retirement
ArchiveHub is designed to preserve agreed structured information, documents, metadata and business relationships in a governed experience independent of the legacy user interface. It can support modern historical search and reporting together with appropriately configured identity, authorization, encryption, audit and lifecycle capabilities. IBM i discovery, object mapping, extraction and business validation remain essential parts of delivery.
Review the vendor-neutral ERP archiving framework, explore ArchiveHub’s historical data platform, or compare Oracle ERP decommissioning and application retirement.
Frequently asked questions
Is AS/400 the same as IBM i?
Not exactly. AS/400 was an earlier system name; IBM i is the current operating system in that platform lineage. Many people still use AS/400 or iSeries to describe applications now running on IBM i.
Can we decommission one application on a shared IBM i partition?
Yes, but scope must distinguish its libraries, objects, jobs, interfaces, security and shared services from other workloads. The appropriate outcome may be application retirement and isolation rather than shutting down the partition.
Why not keep tapes or save files for historical requests?
They are important recovery artifacts but generally require a compatible restore environment and specialist operation. Routine historical inquiry needs validated, governed and understandable business access.
Should logical files be extracted as data?
Logical files generally define access paths or views over physical data rather than holding an independent copy, but their keys, selections and formats can reveal important application meaning. Preserve the relevant logic or reproduce and validate its effect.
Authoritative IBM references
- IBM Documentation: IBM i database files, physical files, logical files and members
- IBM Documentation: database save and restore
- IBM Documentation: using libraries for IBM i
- IBM Documentation: spooled files
- IBM Documentation: QSYS.LIB file system