Retiring QAD MFG/PRO means preserving agreed historical records and usable access before removing the source application dependency. For this scenario, prioritise financial history, manufacturing records and local extensions. 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 MFG/PRO 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.

A "read-only" MFG/PRO environment is still an MFG/PRO environment:

  • The Progress OpenEdge stack. Database and runtime licences, on an older release that may no longer be supported, on an older server operating system that has to stay compatible with it.
  • The people. Someone has to know how to start the databases, run the backups, and fix a broken index. Progress 4GL skills and MFG/PRO administration knowledge are getting harder to find every year.
  • Custom code. Most sites added xx programs and tables over the years (payroll interfaces, custom reports). Those have to keep working on the frozen system, or the data they hold becomes unreachable.
  • Security and patching on a server that nobody wants to touch, but that holds supplier bank details, employee pay and customer pricing.
  • Audit access. Every external auditor or tax inspector needs a user in usr_mstr, a terminal session, and someone to sit next to them to explain which menu shows what.

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 QAD MFG/PRO

ArchiveHub archives the MFG/PRO database as MFG/PRO designed it. Tables keep their native names, and every field keeps its QAD name with a description, so a query against gltr_hist or tr_hist in the ad-hoc query builder reads the way it did in MFG/PRO. Nobody has to learn a new data model.

The archive includes the core of each module:

  • General ledger: gltr_hist (posted GL transaction history), glt_det (unposted transactions), acd_det (account balances by entity, account, cost center and period), ac_mstr, cc_mstr, en_mstr (entities and their base currency), the GL calendar in glc_cal and glcd_det, and ba_mstr batch control. Budgets come with them in bg_mstr and bgd_det.
  • Payables: ap_mstr, vo_mstr and vod_det vouchers with their distributions, ck_mstr and ckd_det checks, vph_hist voucher-to-receipt matching, and vd_mstr suppliers with ad_mstr addresses.
  • Receivables: ar_mstr invoices, memos and payments, ard_det payment applications, and cm_mstr customers.
  • Sales and shipping: so_mstr and sod_det (including scheduled orders), sch_mstr and schd_det customer schedule releases, abs_mstr shippers and ASNs, and ih_hist / idh_hist invoice history.
  • Purchasing: po_mstr, pod_det, prh_hist receipts, and vp_mstr supplier items.
  • Inventory and costing: pt_mstr, in_mstr, ptp_det, ld_det location detail, tr_hist inventory transactions, and trgl_det, which links each inventory transaction to its GL entry. Costs are in sct_det and spt_det by cost set (cs_mstr), with product lines and their default accounts in pl_mstr.
  • Manufacturing: wo_mstr, wod_det, wr_route, op_hist labor feedback, ps_mstr product structures, ro_det routings, and wc_mstr work centers.
  • Fixed assets and tax: fa_mstr, fab_det, fabd_det and faloc_mstr, with tx2_mstr and tx2d_det from Global Tax Management.

Site-custom tables are kept too. If payroll came in from an outside service through xxpyh_hist and xxpyd_det, those records come into the archive with everything else.

Explore the demonstration

Transaction by Account Inquiry list in ArchiveHub Transaction by Account Inquiry: posted GL lines from gltr_hist, filterable by entity, account, cost center and period. ArchiveHub demonstration using mock data; not a native ERP screen or customer implementation.

Transaction by Account Inquiry detail page in ArchiveHub Transaction by Account Inquiry detail: a single GL transaction with its reference, source and amounts. ArchiveHub demonstration using mock data; not a native ERP screen or customer implementation.

AP Aging Report list in ArchiveHub AP Aging Report: open vouchers 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

  • Transaction by Account Inquiry: reference workflow: the Transaction by Account Inquiry (gltr_hist).
  • Trial Balance: reference workflow: the Trial Balance and Account Balance Inquiry by entity and period, with period 13 as the year-end close (acd_det).
  • Budget Report: reference workflow: the Budget Report, budget versus actual by account and cost center (bg_mstr, bgd_det, acd_det).

Audit

  • Batch and Unposted GL Audit: reference workflow: the Batch Report and Unposted Transaction Register: who posted what, plus journals never posted (ba_mstr, gltr_hist, glt_det).
  • Subledger to GL Reconciliation: reference workflow: the GL reconciliation at the archive cut-off, with tax and wages as cumulative activity and the other accounts as closing balances.

Accounts Payable

  • AP Aging Report: reference workflow: the AP Aging Report by due date at the archive cut-off, tied to the AP control account (ap_mstr, vo_mstr).
  • Voucher Inquiry: reference workflow: the Voucher Inquiry (ap_mstr, vo_mstr, vod_det).
  • Check Register: reference workflow: the Check Register and Check Status Inquiry (ap_mstr, ck_mstr, ckd_det).

Accounts Receivable

  • AR Aging Report: reference workflow: the AR Aging Report by due date at the archive cut-off, tied to the AR control account (ar_mstr).
  • Customer Activity Inquiry: reference workflow: the AR Transaction and Customer Payment Inquiries (ar_mstr, ard_det).

Cash and Bank

  • Bank Account Activity: reference workflow: the bank reconciliation activity of the cash account by bank (gltr_hist, ck_mstr, ar_mstr).

Sales

  • Sales Order Inquiry: reference workflow: the Sales Order Inquiry (so_mstr, sod_det).
  • Scheduled Order Inquiry: reference workflow: the Customer Scheduled Order Inquiry (so_mstr, sod_det with sod_sched).
  • Customer Schedule Inquiry: reference workflow: the Customer Schedule Inquiry for planning, shipping and required ship schedules (sch_mstr, schd_det).
  • Shipper Inquiry: reference workflow: the Shipper / ASN Inquiry (abs_mstr).
  • Invoice History Inquiry: reference workflow: the Invoice History Inquiry (ih_hist, idh_hist).

Purchasing

  • Purchase Order Inquiry: reference workflow: the Purchase Order Inquiry (po_mstr, pod_det, prh_hist).
  • Receipts Not Vouchered: reference workflow: the Unvouchered Receipts / Receiver Accrual Report, tied to the receipts accrual account (prh_hist, vph_hist).

Inventory

  • Inventory Detail by Location: reference workflow: the Inventory Detail Inquiry (ld_det).
  • Inventory Valuation Report: reference workflow: the Inventory Valuation Report (in_mstr, sct_det).
  • Item Cost Report: reference workflow: the Item Cost Report by cost set (sct_det, spt_det).
  • Transactions Detail Inquiry: reference workflow: the Transactions Detail Inquiry (tr_hist, trgl_det).

Manufacturing

  • Work Order Status Inquiry: reference workflow: the Work Order Status Inquiry with component, routing and labor feedback (wo_mstr, wod_det, wr_route, op_hist).
  • Work Order Cost Report: reference workflow: the Work Order Cost Report and WIP Report, with open balances tied to the WIP account (wo_mstr).
  • Product Structure Inquiry: reference workflow: the Product Structure Inquiry and Routing Report (ps_mstr, ro_det).

Master Data

  • Item Master Inquiry: reference workflow: the Item Master Inquiry (pt_mstr).
  • Customer Master Inquiry: reference workflow: the Customer Inquiry (cm_mstr, ad_mstr).
  • Supplier Master Inquiry: reference workflow: the Supplier Inquiry (vd_mstr, ad_mstr).

Fixed Assets

  • Fixed Asset Inquiry: reference workflow: the Fixed Asset Inquiry and Depreciation Report (fa_mstr, fab_det, fabd_det).

Tax

  • Tax Transaction Report: reference workflow: the Global Tax Management Tax Transaction Report, with IVA and VAT by document (tx2d_det, tx2_mstr).

HR and Payroll

  • Employee and Payroll Inquiry: reference workflow: the Employee Inquiry with the payroll register. Payroll is a site-custom interface table, and gross pay ties to the GL by department (emp_mstr, xxpyh_hist).

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 records they belong to. For MFG/PRO that covers customer invoices, supplier vouchers, purchase orders, shippers, work orders, fixed assets, employee records, suppliers and customers. When a customer disputes a shipment, the shipper record and its paperwork are 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 over the configured archived tables, showing the native QAD field descriptions and suggesting joins such as tr_hist to trgl_det to gltr_hist, or vo_mstr to vph_hist to prh_hist.
  • Retention rules and purge with approval, applied by table and record age.
  • Legal hold on records involved in a warranty, product liability or tax case.
  • 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 every MFG/PRO table, including the site-custom xx tables, from the Progress database.
  2. Validate. Row counts are compared per table. Balances must tie out: acd_det must agree with the trial balance MFG/PRO produced, and AR, AP, receipts accrual, inventory, WIP and fixed assets must reconcile to their GL control accounts.
  3. Parallel read access. Finance, purchasing, sales and plant users run their usual inquiries in ArchiveHub while MFG/PRO 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.

Keep the history, not the server

Your plants have moved on. The MFG/PRO history still matters, but the Progress server and its upkeep no longer need to.

Questions about QAD MFG/PRO retirement

What should happen to local MFG/PRO extensions?

Inventory local tables, scripts and report logic with the people who understand them. Include required fields and meanings in the archive scope instead of relying only on a standard product dictionary.

Can a Progress backup replace historical user access?

A backup can support recovery, but users still need interpretable records, permissions and reporting. Prove the agreed business questions in the archive before removing the source application dependency.

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 QAD MFG/PRO 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 QAD MFG/PRO-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 QAD MFG/PRO retirement engagement

ArchiveHub offers a fixed-price engagement for QAD MFG/PRO 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 QAD MFG/PRO retirement requirements with ArchiveHub

QAD and MFG/PRO are trademarks of their respective owner. ArchiveHub is not affiliated with or endorsed by QAD.