Retiring IFS Applications means preserving agreed historical records and usable access before removing the source application dependency. For this scenario, prioritise equipment hierarchy, maintenance history and voucher context. Compare required reports and documents with source evidence, test permissions and obtain business acceptance before scheduling shutdown.

This guide covers the retirement questions, a mock-data ArchiveHub demonstration and the validation work needed to define a project scope.

What keeping IFS Applications read-only really costs

Cost categories are a discovery checklist, not a guaranteed savings calculation. Verify support status, deployment, shared infrastructure and contract terms for the actual installation.

  • The Oracle Database. IFS Applications runs on Oracle, so an inquiry-only instance still means Oracle licences, support and a DBA to patch, back up and tune it.
  • The middleware and client. The application server and the IFS Enterprise Explorer client have to stay on mutually supported versions, on operating systems that eventually go out of support themselves.
  • Vendor support. Keeping an old release supported, or running it unsupported, both carry a cost: one in fees, the other in risk.
  • Skills. Knowing the navigators, the analysis screens and the IFS data model is specialist knowledge, and the people who have it are increasingly busy with the new platform.
  • Security and audit access. Person, employee, supplier and payment data stays exposed on a system that is no longer actively managed, and every audit needs accounts, roles and a guide.

Scope, versions and evidence

This is an illustrative workflow, not a customer case study. Confirm the source release, deployment, modules, customisations and extraction permissions before using the mappings below. Tables and report labels describe the demonstration catalogue; native-report equivalence has not been independently certified. Use agreed source reports and representative records for acceptance testing.

An archive is not a replacement for every operational feature of the retired ERP. Document required historical tasks, excluded functions and any archive-derived calculations.

Historical data to scope for IFS Applications

ArchiveHub archives the IFS tables under their native _TAB names, with every column keeping its IFS name and a description. Anyone who used to write SQL against the IFS views will find the same vocabulary: companies, sites (CONTRACT), code parts, voucher types, objects, PM actions.

Representative tables in the archive:

  • Finance: GEN_LED_VOUCHER_TAB and GEN_LED_VOUCHER_ROW_TAB (GL vouchers and rows), ACCOUNTING_BALANCE_TAB (GL balances by period, account and cost center), and ACCOUNTING_PERIOD_TAB, where period 0 is year opening, 1 to 12 are the months and 13 is year closing. The code part structure is in ACCOUNTING_CODE_PART_TAB and ACCOUNTING_CODE_PART_VALUE_TAB, the code parts being A Account, B Cost Center and so on. Alongside them sit VOUCHER_TYPE_TAB, ACCOUNT_GROUP_TAB, BUDGET_PERIOD_AMOUNT_TAB, BUDGET_VERSION_TAB and CASH_ACCOUNT_TAB.
  • Ledger items and payments: LEDGER_ITEM_TAB (open and closed customer and supplier items), LEDGER_TRANSACTION_TAB (payment applications), PAYMENT_TAB, TAX_LEDGER_ITEM_TAB, TAX_DECLARATION_TAB and STATUTORY_FEE_TAB.
  • Customers and suppliers: CUSTOMER_INFO_TAB, SUPPLIER_INFO_TAB, their address tables, and IDENTITY_PAY_INFO_TAB.
  • Sales: CUSTOMER_ORDER_TAB, CUSTOMER_ORDER_LINE_TAB, CUSTOMER_ORDER_DELIVERY_TAB, CUSTOMER_ORDER_INV_HEAD_TAB and CUSTOMER_ORDER_INV_ITEM_TAB.
  • Purchasing and invoices: PURCHASE_ORDER_TAB, PURCHASE_ORDER_LINE_TAB, PURCHASE_RECEIPT_TAB, MAN_SUPP_INVOICE_TAB and MAN_SUPP_INVOICE_ITEM_TAB.
  • Inventory: INVENTORY_PART_TAB, INVENTORY_PART_IN_STOCK_TAB, INVENTORY_TRANSACTION_HIST_TAB (the stock ledger) and INVENTORY_TRANSACTION_CODE_TAB.
  • Maintenance: EQUIPMENT_OBJECT_TAB (functional and serial objects in their site, plant, unit and component structure) and EQUIPMENT_OBJECT_MEAS_TAB measurements. Work orders are in ACTIVE_SEPARATE_TAB and HISTORICAL_SEPARATE_TAB, and their cost lines in WORK_ORDER_CODING_TAB. Also kept: PM_ACTION_TAB and PM_ACTION_CALENDAR_PLAN_TAB, PERMIT_TAB, and the fault code tables for symptoms, causes, discovery and performed actions.
  • Projects and assets: PROJECT_TAB, SUB_PROJECT_TAB, ACTIVITY_TAB, PROJECT_TRANSACTION_TAB, FA_OBJECT_TAB and FA_OBJECT_TRANS_TAB.
  • HR and payroll: PERSON_INFO_TAB, COMPANY_PERSON_TAB, EMP_JOB_ASSIGN_TAB, PAY_LIST_TAB, PAY_LIST_EMP_TAB, PAY_LIST_ROW_TAB and WAGE_CODE_TAB.
  • Audit: HISTORY_LOG_TAB and HISTORY_LOG_ATTRIBUTE_TAB, TRANSACTION_SYS_LOCAL_TAB (background jobs) and FND_USER_TAB.

Explore the demonstration

GL Voucher Rows list in ArchiveHub GL Voucher Rows: posted voucher rows by company, voucher type, period and code parts, as in GL Voucher Rows Analysis. ArchiveHub demonstration using mock data; not a native ERP screen or customer implementation.

GL Voucher Rows detail page in ArchiveHub GL Voucher Rows detail: a single voucher row with its code part values, amounts and voucher reference. ArchiveHub demonstration using mock data; not a native ERP screen or customer implementation.

Subledger Reconciliation list in ArchiveHub Subledger Reconciliation: each subledger compared with its GL balance, period by period. ArchiveHub demonstration using mock data; not a native ERP screen or customer implementation.

Explore the report reference catalogue

These mappings identify intended business workflows, not certified one-for-one equivalents. Confirm availability, source coverage, filters, currencies, dates and calculations for the selected release and implementation.

Finance

  • GL Voucher Rows: reference workflow: GL Voucher Rows Analysis.
  • GL Balances: reference workflow: GL Balance Analysis, the trial balance per period from 0 to 13.
  • Accounts: reference workflow: Code Part Values for the Account code part (the chart of accounts).
  • Budget Analysis: reference workflow: budget follow-up, comparing Budget Period Amounts with GL balances.
  • Cash Account: reference workflow: Cash Account transactions with a running balance.
  • Payments: reference workflow: Mixed Payment and Payment Analysis.
  • Tax Transactions: reference workflow: Tax Transactions Analysis.

Receivables

  • Customers: reference workflow: Customer (Enterprise) with credit information.
  • Customer Invoices: reference workflow: Customer Invoice Analysis.
  • Customer Open Items: reference workflow: Customer Analysis: Open Items, aged at the archive cut-off.

Payables

  • Suppliers: reference workflow: Supplier (Enterprise) with payment information.
  • Supplier Invoices: reference workflow: Manual Supplier Invoice and Supplier Invoice Analysis.
  • Supplier Open Items: reference workflow: Supplier Analysis: Open Items, aged at the archive cut-off.

Sales

  • Customer Orders: reference workflow: Customer Order and Customer Order Analysis.

Supply Chain

  • Purchase Orders: reference workflow: Purchase Order and Purchase Order Analysis.
  • Inventory Parts: reference workflow: Inventory Part and Inventory Part In Stock (spare parts).
  • Inventory Transaction History: reference workflow: Inventory Transaction History (the stock ledger).

Maintenance

  • Equipment Objects: reference workflow: the Equipment Navigator / Functional Object, with object history.
  • Active Work Orders: reference workflow: Prepare Work Order / Active Work Orders open at the cut-off.
  • Historical Work Orders: reference workflow: Historical Work Order.
  • PM Actions: reference workflow: PM Action, with generated work orders and schedule compliance.
  • Failure Analysis: fault history per object, with MTBF, MTTR and availability.
  • Maintenance Cost Analysis: Work Order Cost analysis per object, year and category, to find cost hotspots.

Projects

  • Projects: reference workflow: the Project Navigator (capital projects).
  • Project Transactions: reference workflow: Project Transactions.

Fixed Assets

  • Fixed Asset Objects: reference workflow: Fixed Assets: Object, with object transactions.

HR and Payroll

  • Employees: reference workflow: Company Person / Employee File.
  • Pay Lists: reference workflow: the Pay List per employee, by cost center.

Audit

  • History Log: reference workflow: History Log, the audited changes to master data.
  • Background Jobs: reference workflow: Background Jobs, the scheduled tasks such as Update GL, depreciation, PM generation and payment proposals.
  • Subledger Reconciliation: reference workflow: posting control reconciliation of the subledgers against GL Balance Analysis, per period.

Source documents stay attached

Document types below illustrate the intended scope. Include source attachments and external repositories explicitly, and test retrieval and record linkage before decommissioning.

ArchiveHub keeps archived documents attached to the IFS records they belong to: purchase orders, supplier invoices, customer invoices, work order reports, fixed asset objects, projects, employees, customers and suppliers. An engineer opening a historical work order sees the work order report with it; an auditor opening a supplier invoice sees the scanned original.

Beyond the reports

Confirm these capabilities, configuration requirements and limits during the demonstration and scope review; the report catalogue alone does not validate them.

  • Ad-hoc query builder across the configured archived tables, with the IFS column descriptions and suggested joins, for example EQUIPMENT_OBJECT_TAB to HISTORICAL_SEPARATE_TAB to WORK_ORDER_CODING_TAB.
  • Retention rules and purge with approval: maintenance records often need to be kept far longer than invoices, and the rules can say so.
  • Legal hold for records involved in an incident investigation, claim or audit.
  • Personal-data governance: agree the lawful retention, access and deletion requirements with the responsible privacy and records teams. Product features alone do not establish regulatory compliance.
  • Access controls: define and test permissions for the required companies, records and sensitive fields. Do not assume that system-level roles reproduce the original ERP permissions, particularly for payroll and HR data.
  • OData feeds to Excel, Power BI and SAP Analytics Cloud, for example for reliability analysis on the failure history.

How the decommissioning project runs

  1. Extract the IFS tables from the Oracle database with their native names and descriptions.
  2. Validate. Row counts are checked per table. Balances must tie out: ACCOUNTING_BALANCE_TAB against GL Balance Analysis per period, and customer and supplier ledger items, inventory, fixed assets and payroll reconciled to the GL, using the same posting-control logic as IFS.
  3. Parallel read access. Maintenance, finance, project and HR users work in ArchiveHub while the IFS instance is still available.
  4. Retire after acceptance. Obtain documented sign-off for data reconciliation, document retrieval, user access, retention and legal holds, recovery and remaining integrations. Retire only the approved components; shared infrastructure may still be needed. End or reduce subscriptions, licences and support only where the contract permits. Budget for archive operation and any residual costs.

Equipment lives longer than ERPs

A transformer or a compressor can outlast two or three ERP generations. ArchiveHub keeps its IFS history readable in IFS terms, without keeping IFS Applications running.

Questions about IFS Applications retirement

Why preserve equipment hierarchy after IFS retirement?

A historical work order needs enough asset, site and component context to be understood. Validate the equipment relationships and required documents along with the work-order transactions.

Does a finance reconciliation prove maintenance-history completeness?

No. Test maintenance lookups separately, including selected work orders, costs and available supporting records. Finance and engineering should sign off their own acceptance cases.

What does this ArchiveHub demonstration prove?

The screenshots illustrate how selected records can be presented using mock data. They do not prove production completeness, customer outcomes or parity with every IFS Applications report. Request a demonstration against your own approved scope and acceptance cases.

Related retirement resources

For the broader project approach, see Legacy application retirement planning. To evaluate how users will find transactions, follow relationships and retrieve documents, explore archived data reporting. These resources complement this IFS Applications-specific scope rather than replace source-system validation.

Evidence and further reading

The report catalogue and screenshots originate from an internal mock-data demonstration. They are not vendor certification or customer implementation evidence.

For version-specific mappings, obtain the applicable vendor documentation and compare it with the installed system. No independently verified, release-specific mapping reference is supplied with this draft.

Fixed-price IFS Applications retirement engagement

ArchiveHub offers a fixed-price engagement for IFS Applications retirement and historical data access, based on an agreed scope, deliverables and acceptance criteria. Request a scoped proposal covering your source systems, data, documents, reporting and validation requirements. The proposal should specify included services, exclusions, ongoing platform or hosting charges, and how scope changes will be handled.

Discuss your IFS Applications retirement requirements with ArchiveHub

IFS Applications is a trademark of its respective owner. ArchiveHub is not affiliated with or endorsed by IFS.