Planned, governed shutdown of QAD Adaptive ERP — with full data archival, customization preservation, integration teardown, and audit-ready sign-off. SOX, IRS, IATF 16949, 21 CFR Part 11, ITAR-compliant. 70–90% TCO reduction begins week 8.
QAD decommissioning fails most often not from missing data, but from missing customizations, broken integrations, and unsigned audit evidence.
QAD instances accumulate operational gravity over 15–30 years. By the time decommissioning is on the agenda, the system holds hundreds of .p file customizations developed by Progress 4GL specialists (most of whom have moved on), dozens of QXtend integrations to suppliers and customers, undocumented trigger procedures on critical master tables, custom QAD Reporting Framework reports embedded into period-close routines, and EDI flows tier-1 OEMs depend on for daily production. Ripping out QAD without addressing every one of these is how decommissioning projects fail.
Syntra ETL's QAD decommissioning workflow front-loads the discovery work. In the first two weeks the discovery engine catalogs every .p file, every QAD Reporting Framework report, every QXtend interface, every trigger procedure, every active integration. Compliance and operations leads see the complete operational dependency footprint before any teardown work starts — no surprises during cutover, no urgent rebuilds at 2 AM on go-live weekend.
Most importantly, decommissioning starts with archival, not shutdown. The complete operational dataset — every pt_mstr, gl_hist, wod_det, tr_hist row, every customization artifact, every security configuration — moves to queryable cloud archive before any infrastructure component is touched. Validation queries prove parity. Only then does QAD move read-only, then offline, then shut down. The archive becomes the system of record for the full retention window.
Each workstream runs in parallel with clear acceptance criteria. None can be skipped without breaking audit evidence.
Complete extract of every pt_mstr, gl_hist, wod_det, tr_hist, ap_hist, ar_hist, in_mstr record to queryable cloud archive in Parquet. Hash-signed at row level with completeness manifests.
Discovery crawls .p file directory tree, QAD Reporting Framework catalog, trigger registry, QXtend metadata. Every custom artifact catalogued with source, version, business purpose, retention policy.
User and group state at decommission date, permission-list rules, domain-level access controls, USER_FILE security setup — preserved as evidence layer for the full retention window.
Every QXtend interface, EDI feed, supplier portal, shop-floor MES, WMS, payroll, banking integration inventoried, classified, and re-pointed to new endpoint before QAD goes read-only.
App tier, DB tier, web tier, reporting tier, dev/test environments retired in sequence. Progress OpenEdge licenses surrendered. Infrastructure cost line items zeroed out.
Formal evidence package — completeness report, customization catalog, integration log, security snapshot, validation results, sign-offs from finance, operations, IT, compliance, and (where applicable) tier-1 OEM and FDA.
Typical mid-size decommission: 8–14 weeks end to end. Global multi-domain: 14–24 weeks.
Discovery engine catalogs every .p file customization, QAD Reporting Framework report, QXtend interface, trigger procedure, integration endpoint, and security configuration. Output: complete operational dependency map signed by IT, operations, and compliance.
Pre-built QAD extractors pull every in-scope PS_* equivalent — pt_mstr, cm_mstr, vd_mstr, gl_hist, wod_det, tr_hist, ap_hist, ar_hist — via native Progress JDBC. Output staged as Parquet partitioned by fiscal year, domain, site, item-class. Hash-signed at row level with manifest files.
All .p file source code, QAD Reporting Framework definitions, Crystal Reports, QXtend metadata, trigger procedures, security model state preserved alongside archive with matching retention policy.
Each QXtend interface, EDI feed, supplier portal, MES/WMS connection re-pointed to new endpoint (Fusion OIC, REST APIs, ESS file feeds). Cut-over orchestrated so downstream systems experience zero outage. Validation pass per integration.
Sample auditor, OEM-PPAP, FDA Part 11 queries run archive vs live QAD to prove parity. Sign-off pack issued. QAD moves to read-only — operational traffic ceases. Cost savings begin: most line items zero out from this point.
App tier, DB tier, web tier, reporting tier retired in sequence. Progress OpenEdge licenses surrendered. Backups encrypted and stored to retention policy. Final sign-off pack issued. Archive becomes system of record.
The TCO components that disappear when QAD shuts down — and the manufacturer-specific ones often missed.
QAD Adaptive ERP annual support at 18–22% of original license fee — $80K–$400K/year for mid-to-large manufacturers. Recovers from next renewal cycle post-decom.
OpenEdge RDBMS, 4GL development, AppServer, OpenEdge Management, After-Imaging — $40K–$200K/year for multi-domain instances. Fully recovered post-decom.
App tier, DB tier, web tier, reporting tier, multiple dev/test/sandbox environments — $80K–$400K/year on cloud or on-prem. Reduced to single-digit-thousands archive storage cost.
Even a 'lights-on' QAD instance needs Progress 4GL developer time, QAD admin time, OpenEdge DBA time — typically $250K–$600K/year fully loaded. Reduces to occasional auditor-query support.
QAD service packs, OpenEdge CPU patches, QXtend updates, regression testing — 6–10 person-weeks per year. Zero post-decom.
Attack-surface elimination, compliance-dependency removal, single-point-of-skill-failure mitigation. Cyber-insurance premiums often reduce post-decom; audit findings drop.
QAD decommissioning is the planned, governed shutdown of a QAD Adaptive ERP (or MFG/PRO / QAD Enterprise Applications) instance after migration to a successor system, with full retention of historical data, customizations, and audit evidence to satisfy SOX, IRS, IATF 16949 PPAP, FDA 21 CFR Part 11, and ITAR requirements. It involves five workstreams: (1) data archival of every pt_mstr, gl_hist, wod_det, tr_hist record to queryable cloud storage; (2) customization preservation — .p files, QAD Reporting Framework reports, QXtend integrations, trigger procedures catalogued; (3) security-model snapshot capturing user/group/permission state at decommission date; (4) integration teardown — QXtend interfaces, EDI feeds, supplier portals re-pointed away from QAD; (5) infrastructure shutdown — app/DB/web tiers retired, Progress OpenEdge licenses surrendered.
By archiving first, decommissioning second — never the other way around. Syntra ETL's QAD decommissioning workflow starts with a complete data extract from Progress OpenEdge to Parquet in cloud object storage, hash-signed at row level, with manifests proving completeness. Before any infrastructure is shut down, a validation pass runs sample auditor, OEM-PPAP, and FDA Part 11 queries against the archive vs the live QAD instance to prove parity. Only after validation sign-off does QAD move to read-only, then offline, then to infrastructure shutdown. The archive becomes the system of record for retention — and the cost savings begin from the moment the archive is validated, not after teardown is complete.
Every custom artifact in the QAD application directory tree: .p Progress procedure files (with source code, last-modified date, file-system path, business purpose where derivable), QAD Reporting Framework definitions, custom Crystal Report templates, QXtend interface configurations, trigger procedures registered against pt_mstr/wo_mstr/so_mstr/cm_mstr/vd_mstr, sequence-number routines, custom code_mstr lookups, and the mfg_ctrl + sys_ctrl + domain_ctrl configuration snapshots. Syntra ETL's discovery engine catalogs all of this in 5–10 working days, signs and timestamps the catalog, and stores it alongside the data archive with matching retention policy — typically the 15-year PPAP or 30-year pharma window.
Only if not planned carefully. Most QAD instances have dozens to hundreds of integrations: EDI brokers (Sterling, GXS/OpenText, IBM Sterling B2B), QXtend interfaces, supplier portals, shop-floor MES, WMS, customer-facing order portals, BI tools, payroll, banking. Syntra ETL's decommissioning workflow inventories every integration via QXtend metadata and network-flow analysis, classifies by criticality, and produces a per-integration cut-over plan. Each integration is re-pointed to its new endpoint (Fusion OIC, REST APIs, ESS file feeds) before QAD goes read-only, validated, and only then does QAD shut down. Done right, downstream systems experience zero outage.
Typical timeline for a mid-size QAD instance (1–3 plants, 1TB Progress data, 50+ integrations, 200+ .p file customizations) is 8–14 weeks. Larger global multi-domain instances take 14–24 weeks. The work is dominated by archival (4–7 weeks), customization inventory (3–5 weeks running in parallel), integration teardown (4–8 weeks running in parallel), and validation/cutover (2–4 weeks). Infrastructure shutdown itself is days, not weeks. Customers typically start saving 70–90% of QAD TCO from week 8–10 onwards as systems move read-only, even before final shutdown.
Yes. QAD decommissioning is independent of the migration target — Syntra ETL supports decommission scenarios that target Oracle Fusion, SAP S/4HANA, Microsoft Dynamics 365, NetSuite, Plex, or any modern cloud ERP. The decommissioning workflow archives QAD data and customizations regardless of where operational workloads move next. For organizations that wind down QAD operations entirely (e.g., a divested business unit, a closed product line, or a strategic exit from a manufacturing vertical), the decommission can stand alone with no migration target — the archive serves the full retention window and QAD shuts down.
Progress OpenEdge licensing for QAD typically runs $40K–$200K/year in support, and the licenses are tied to the specific hardware/cloud instance. As part of decommissioning, Syntra ETL coordinates with the Progress vendor and your procurement team to surrender the OpenEdge RDBMS license, the 4GL development license, the AppServer license, and any add-on licenses (After-Imaging, OpenEdge Replication, OpenEdge Management) — typically yielding the full OpenEdge support cost recovery from the next renewal cycle. The archive itself runs entirely on cloud-native technology (Parquet on object storage) with no Progress dependency.
The QAD decommissioning sign-off pack is the formal evidence package that QAD has been retired correctly. It includes: (1) Data completeness report — row counts, hash totals, sum totals per table proving every operational record is in archive; (2) Customization catalog — full .p file inventory with source, business purpose, retention policy; (3) Integration teardown log — every interface re-pointed, with cut-over timestamps; (4) Security snapshot — user/group/permission state at decommission date; (5) Validation results — sample auditor, OEM-PPAP, and FDA Part 11 queries reconciled archive vs source; (6) Infrastructure shutdown evidence; (7) Sign-offs from finance, operations, IT, compliance, and (where applicable) tier-1 OEM quality and FDA. The pack is signed, timestamped, and retained for the full data retention window.
30-minute call. Walk through your QAD footprint, .p file customization profile, integration inventory, and retention obligations — and leave with a concrete decommissioning plan and TCO recovery model.