Retiring Infor M3 means preserving agreed historical records and usable access before removing the source application dependency. For this scenario, prioritise company and division context, vouchers and lot movements. 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 a read-only M3 costs you

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

An old M3 environment is not just an application. It is a stack:

  • Servers and a database sized for production, on IBM i or on a Windows and database server stack, with the licences and support contracts that come with them.
  • The M3 Business Engine and the clients in front of it, which have to stay patched and compatible with operating systems and browsers that keep moving.
  • Infor maintenance, if you are still paying it for a version that no longer receives development.
  • Know-how. Navigating M3 means knowing the program codes (CRS610, OIS300, MMS001), the panel sequences, the company and division split, accounting identities and the transaction codes on the ledgers. Fewer people know that every year.
  • Audit access. Temporary users, read-only roles, and someone to walk the auditor through the screens.

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 Infor M3

ArchiveHub keeps the M3 database as M3 built it, with its native table names and its two-letter field prefixes, so OKCUNO is still the customer number in the customer master and company/division context is retained where applicable to the selected tables.

Finance.

  • FGLEDG General Ledger Transactions and FGJOUR voucher headers, the source for GLS200 and the voucher audit trail.
  • FPLEDG Accounts Payable Ledger and FSLEDG Accounts Receivable Ledger, behind APS200 and ARS200.
  • FAPIBH/FAPIBL supplier invoice batches (APS450).
  • FCHACC accounting identities, FBUDGT budget lines, FBANKS bank statement lines with CBANKA bank accounts.
  • FFASMA fixed asset master and FFASDE depreciation.

Sales and distribution. OCUSMA customer master, OOHEAD/OOLINE customer orders, ODHEAD/ODLINE delivery and invoice lines, OPRBAS sales price lists.

Purchasing. CIDMAS supplier master with CIDVEN financial data per division and CIDADR addresses; MPHEAD/MPLINE purchase orders.

Items and inventory. MITMAS item master, MITBAL item warehouse, MITFAC item facility cost, MITLOC balance identities, MITTRA stock transaction history, MITWHL warehouses.

Manufacturing. MPDHED, MPDMAT and MPDOPE product structures and routings; MWOHED, MWOMAT and MWOOPE manufacturing orders.

People and setup. CEMPLO employee master and CEMPAY monthly pay results, CMNDIV companies and divisions, CMNUSR users, and CSYTAB, the system table that decodes payment terms, groups, payment methods, buyers and salespersons.

Every field carries its M3 description, so the ad-hoc query builder still talks about "customer number" and "voucher number" rather than cryptic codes, while anyone who knows the codes can use them.

The ledgers keep their transaction codes, so payments and invoices in FPLEDG and FSLEDG can still be told apart the way M3 users always did, and the voucher number links each subledger line back to its FGLEDG postings. Multi-company and multi-division set-ups stay intact, so a group that ran several divisions in one M3 can still report one division at a time.

Explore the demonstration

GL Transactions (GLS200) list in ArchiveHub GL Transactions (GLS200): general ledger transactions by division, year, period and voucher. ArchiveHub demonstration using mock data; not a native ERP screen or customer implementation.

GL Transactions (GLS200) detail page GL Transactions detail: one voucher line with its accounting identity and source program. ArchiveHub demonstration using mock data; not a native ERP screen or customer implementation.

Supplier Aging in ArchiveHub Supplier Aging: open APS200 items by supplier, aged by due date at the archive cut-off. 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

  • Supplier Aging: reference workflow: open supplier invoices aged by due date at the archive cut-off (APS200 open items).
  • Supplier Payments (APS200): reference workflow: supplier ledger payments, transaction code 50 (APS200).
  • Customer Aging: reference workflow: open customer invoices aged by due date at the archive cut-off (ARS200 open items).
  • Customer Payments (ARS200): reference workflow: customer ledger payments, transaction code 20 (ARS200).
  • Bank Statements: reference workflow: bank account statements and lines, tied to the bank GL account (CRS692 bank accounts).
  • Budget vs Actual (BUS100): reference workflow: Budget. Open (BUS100) compared with GL actuals by account and cost centre.
  • Chart of Accounts (CRS630): reference workflow: accounting identities, dimension 1 accounts (CRS630).
  • Customer Ledger (ARS200): reference workflow: Customer ledger. Display (ARS200), invoices and payments.
  • Depreciation Postings (FAS100): reference workflow: FA depreciation account entries by asset and month (FAS100), tied to the accumulated depreciation account.
  • Fixed Assets (FAS001): reference workflow: Fixed asset. Open (FAS001).
  • GL Transactions (GLS200): reference workflow: General ledger transactions. Display (GLS200).
  • Journal Register and Audit Trail: who posted each voucher, when and from which program, in the style of the GLS040 voucher audit trail.
  • Subledger to GL Reconciliation: subledger to general ledger balances by period (GLS200 against ARS200, APS200, FAS001 and bank).
  • Supplier Invoices (APS450): reference workflow: Supplier invoice batch. Open (APS450).
  • Supplier Ledger (APS200): reference workflow: Supplier ledger. Display (APS200), invoices and payments.
  • Trial Balance: trial balance by division, year and period (period 13 = year-end closing).
  • VAT and Sales Tax Report: output VAT / sales tax by quarter, invoices (ODHEAD) against the output VAT account.

HR

  • Employees (CRS530): reference workflow: Employee. Open (CRS530).
  • Payroll Postings: payroll interface by employee and month, tied to the payroll expense accounts (payroll ran outside M3 and was posted through GLS).

Manufacturing

  • Manufacturing Orders (PMS100): reference workflow: Manufacturing order. Open (PMS100).
  • Product Structures (PDS001): reference workflow: Product. Connect structure (PDS001).

Sales & Purchasing

  • Customer Invoices (OIS350): reference workflow: Customer invoice. Display (OIS350).
  • Customer Orders (OIS300): reference workflow: Customer order. Open toolbox (OIS300).
  • Customers (CRS610): reference workflow: Customer. Open (CRS610).
  • Items (MMS001): reference workflow: Item. Open (MMS001).
  • Purchase Orders (PPS200): reference workflow: Purchase order. Open (PPS200).
  • Suppliers (CRS620): reference workflow: Supplier. Open (CRS620).

Supply Chain

  • Deliveries (MWS410): reference workflow: the Delivery toolbox (MWS410), issues reported per customer order.
  • Purchase Order Receipts (PPS300): reference workflow: Purchase order receipt (PPS300).
  • Item Warehouse (MMS002): reference workflow: Item warehouse. Open (MMS002).
  • Balance Identities (MMS060): reference workflow: Balance identity. Open (MMS060), on-hand by location.
  • Stock Transactions (MWS070): reference workflow: Stock transaction history. Display (MWS070).

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.

Supplier invoices, customer invoices and purchase orders keep their PDF documents in the archive, and so do manufacturing orders, customers, suppliers, employees and fixed assets. When a question about a voucher in FPLEDG turns into "can we see the invoice", the answer is on the same screen.

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 M3 tables, with field descriptions and suggested joins (FPLEDG to CIDMAS, OOLINE to MITMAS, FGLEDG to FCHACC).
  • Retention rules and purge with approval, per record type and per company, with sign-off before anything is removed.
  • Legal hold that overrides retention for disputed or investigated records.
  • 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.

How the decommissioning project runs

  1. Extract the M3 tables with their native names, field prefixes and descriptions.
  2. Validate row counts per table, then tie the balances: FPLEDG and FSLEDG against their GL control accounts, fixed assets against the depreciation accounts, bank lines against the bank account, and the trial balance per division and period, including period 13.
  3. Parallel read access. Finance and supply chain users run their M3 inquiries in ArchiveHub while M3 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.

Let the old M3 go

If a legacy M3 environment is still running only to answer questions about past years, let us show you the same GLS200, APS200 and ARS200 history in ArchiveHub.

Questions about Infor M3 retirement

What should an M3 voucher lookup retain?

Retain the agreed voucher identifiers, transaction meanings and company/division context. Test the path from a ledger line to the relevant subledger record and supporting evidence.

Can finance and lot traceability share one retirement scope?

Yes, if both are explicitly included and independently accepted. Finance reconciliation does not prove lot genealogy; test representative receipts, movements and shipments as a separate workflow.

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 Infor M3 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 Infor M3-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.

Use Infor documentation to locate the documentation for the installed release. This is a documentation entry point, not verification of every table or report mapping in this article.

Fixed-price Infor M3 retirement engagement

ArchiveHub offers a fixed-price engagement for Infor M3 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 Infor M3 retirement requirements with ArchiveHub

Infor M3 is a trademark of its respective owner. ArchiveHub is not affiliated with or endorsed by Infor.