A purpose-built ETL platform for QAD to Oracle Fusion migration — Financials, Manufacturing, Distribution. Native Progress OpenEdge extraction, domain/site → Fusion enterprise structure crosswalks, FBDI emitters. Built for automotive, life sciences, and industrial manufacturers.
Most QAD to Oracle Fusion migrations fail in the Progress OpenEdge extraction layer, the domain/site translation, and the .p file customization inventory — not in load.
QAD customers, especially those with MFG/PRO roots stretching back 20–30 years, carry an enormous customization footprint: hundreds of .p Progress procedure files, custom triggers on pt_mstr and wo_mstr, QAD Reporting Framework reports tailored to each plant, QXtend interfaces hand-wired to EDI brokers and shop-floor systems. Consultant-led migrations spend the first 4–6 months just cataloguing what exists — and even longer fighting the ODBC bridge to OpenEdge that bespoke ETL scripts depend on. By the time real ETL work starts, budget and timeline are already half-gone.
Syntra ETL inverts that sequence. Pre-built QAD extractors read Progress OpenEdge natively via JDBC, with parallel partition reads keyed on domain, site, and year. A discovery engine that crawls the QAD schema, .p file directories, QXtend metadata, and reportlist catalog produces a complete customization inventory in 5–10 working days. The conversation that consumed the first six months of every traditional QAD migration now happens in week three, with hard evidence on the table.
Whether you're migrating Financials only, both Financials and Manufacturing, or running a multi-site automotive consolidation where dozens of QAD plants converge into Fusion Manufacturing Cloud, the same engine handles the workflow — with the same reconciliation rigor and the same audit trail required for IATF 16949 and 21 CFR Part 11 contexts.
And how the Syntra ETL platform addresses each one — before they consume your timeline.
Most ETL tools speak SQL Server and Oracle natively but choke on Progress OpenEdge. Syntra ETL reads OpenEdge natively via Progress JDBC with parallel partition reads — no ODBC bridge, no hand-rolled .p export scripts, no fragile flat-file intermediates.
QAD's domain/entity/site model collides with Fusion's Enterprise/LE/BU/Inv-Org hierarchy. Syntra ETL's analyser maps multi-plant rollups, inter-company eliminations, and regional consolidations into a Fusion structure operations can actually live with.
Discovery crawls the .p file directory tree, QXtend metadata, trigger registry, and reportlist catalog. Every custom procedure gets a Fusion-equivalence recommendation: native, Page Composer, VBCS, OIC, BI Publisher, or retire. Typical outcome: 50–65% retired outright.
Legacy report inventory, business-value classification, and Fusion-equivalent rebuild plan (OTBI, BI Publisher, FRS, Smart View). 60–75% of legacy QAD reports retired during the cleanup; only critical PPAP travelers, shop packets, and management dashboards get rebuilt.
Automotive customers carry IATF 16949 / PPAP retention obligations — 15 years post-end-of-production. Syntra ETL preserves wo_mstr/wod_det lot/serial traceability through migration and into archive so PPAP packages remain reproducible.
Every QXtend interface to EDI brokers, MES, WMS, and supplier portals gets re-pointed to Oracle Integration Cloud (OIC) connections, REST endpoints, or ESS-scheduled file feeds — with cut-over orchestration so upstream/downstream systems never lose a beat.
A repeatable, governed workflow built for QAD's particular complexity. Typical multi-pillar timeline: 10–16 weeks.
Discovery engine crawls the QAD schema, .p file tree, QXtend metadata, trigger registry, and QAD Reporting Framework catalog. Output: a complete customization inventory, domain/site usage analysis, and a sized migration assessment with risk register specific to your verticals (automotive, life sciences, industrial).
QAD domain/site → Fusion Enterprise/LE/BU/Inv-Org mapping, ac_mstr → COA segment design, vendor/customer de-duplication across vd_mstr and cm_mstr, item master rationalisation across pt_mstr. Reviewed and signed off by finance, manufacturing, and SCM functional leads. .p file retire/replace decisions logged.
Pre-built QAD extractors pull pt_mstr, cm_mstr, vd_mstr, wo_mstr, so_mstr, po_mstr, ac_mstr, gl_hist, in_mstr, ld_det and all dependent tables in parallel via Progress JDBC. Output staged as Parquet partitioned by domain, site, and fiscal year with row hashes and manifest files.
Crosswalks applied, ChartFields collapsed to Fusion 6-segment COA, item master remapped to Fusion category structure, work-order lifecycle states translated, FBDI payloads generated and validated against Fusion 26x release templates. Errors surfaced locally with row-level diagnostics.
FBDI ZIPs submitted to Fusion ESS in dependency order, monitored to completion, reconciled at row, sum, and hash level. In parallel, critical OTBI dashboards, BI Publisher work-order travelers, and PPAP shop packets rebuilt and validated against QAD equivalents.
1–2 close cycles in parallel (QAD + Fusion), deltas captured via LAST_UPDATE_DTTM and replayed, reconciled to the cent and to the unit, sign-off pack issued. QAD moves to archive-only; production traffic now flows to Fusion.
No more bespoke ODBC scripts or .p file exports. Just configure scope, run, reconcile.
ac_mstr (account master), gl_hist (history detail), gl_ctrl (controls), gl_sum (summary), entity_mstr, domain_mstr. Full domain/entity context preserved, period-by-period reconciliation built in.
ap_mstr, ap_hist, vd_mstr (vendor master), vd_addr (vendor address), po_mstr (PO header), pod_det (PO detail). Open-voucher migration with full approval and payment-status context.
ar_mstr, ar_hist, cm_mstr (customer master), cm_addr, so_mstr (sales order header), sod_det. Open-invoice aging preserved, AR cleanup rules applied during extract.
wo_mstr (work order header), wod_det (WO detail), ro_det (routings), ps_mstr (BOM / product structure), in_mstr (item inventory), ld_det (location detail). Full lot/serial traceability preserved for PPAP and 21 CFR Part 11 contexts.
pt_mstr (item master), pt_xref (cross-reference), pl_mstr (price list), code_mstr (master codes), tr_hist (transaction history). Item rationalisation and category remapping applied during extract.
.p file inventory with source code, QXtend interface catalog, QAD Reporting Framework report library, trigger registry, sequence-number routines — exported to archive with retention policy matching the data.
A typical QAD to Oracle Fusion migration (Financials + Manufacturing + Distribution, 10–15 years of history, 500GB–1.5TB Progress OpenEdge source) runs 10–16 weeks with Syntra ETL versus 12–18 months with consultant-led approaches. Single-pillar projects (Financials-only) complete in 6–9 weeks. The acceleration comes from pre-built QAD extractors that read Progress OpenEdge directly (no ODBC-bridge fragility), governed crosswalks for QAD's domain/site structure to Fusion legal-entity/business-unit translation, and FBDI emitters validated against the current Oracle Fusion 26x release. Manufacturing-heavy migrations (extensive BOMs, routings, work-order history) typically add 2–3 weeks for the wo_mstr / wod_det / ro_det reconciliation against Fusion Manufacturing Cloud, especially for automotive customers carrying PPAP traceability obligations.
QAD Adaptive ERP remains a capable manufacturing platform, but customers move to Oracle Fusion for four reasons. First, global standardization — when a multinational acquires a QAD-running division, they consolidate on Oracle or SAP. Second, Progress OpenEdge skills shortage — the developer pool is shrinking faster than the COBOL pool, and replacement hires for Progress 4GL .p file maintenance command premium rates. Third, modernization — Fusion ships embedded AI/ML, Redwood UX, and continuous quarterly updates that QAD's slower release cadence cannot match. Fourth, integration consolidation — customers tired of stitching QXtend, EDI brokers, and bespoke .p file integrations together prefer Fusion's native OIC + REST API model. The migration locks in lower TCO while Progress talent is still available; customers waiting until 2030+ will face a developer-supply crunch.
Syntra ETL supports QAD to Oracle Fusion migration across the full Adaptive ERP footprint. Financials: General Ledger (ac_mstr, gl_hist), Accounts Payable (ap_mstr, ap_hist), Accounts Receivable (ar_mstr, ar_hist), Fixed Assets (fa_mstr), Multi-currency. Manufacturing: Work Orders (wo_mstr, wod_det), Routings (ro_det), BOMs (ps_mstr), MRP, Shop Floor Control, Production Scheduling. Distribution & SCM: Sales Orders (so_mstr, sod_det), Purchase Orders (po_mstr, pod_det), Inventory (in_mstr, ld_det), Item Master (pt_mstr), Customer (cm_mstr) and Supplier (vd_mstr) master data. Service: Service Orders, Field Service. Customer-specific .p file customizations and QXtend integration patterns are inventoried for re-implementation in Fusion-native tooling (OIC, VBCS, ESS).
QAD's data model is anchored on Domain (a multi-company logical container), Entity (essentially a legal entity within a domain), and Site (a physical plant or warehouse). Most master and transactional tables carry a domain code and site code as part of the natural key. Oracle Fusion uses a different model: Enterprise → Legal Entity → Business Unit → Inventory Organization. Syntra ETL's crosswalk engine analyses QAD domain/entity/site usage across pt_mstr, in_mstr, wo_mstr, so_mstr and other key tables, then proposes a Fusion enterprise structure that preserves the operational distinctions QAD customers actually depend on — multi-plant rollups, inter-company eliminations, regional consolidation. Every mapping is reviewed and signed off by finance and operations leads before any FBDI load runs.
The .p files themselves don't migrate — Oracle Fusion has no Progress 4GL runtime. Syntra ETL inventories every custom .p file, QAD Reporting Framework report, QXtend interface, and trigger procedure in the source QAD instance, classifies each by business purpose, and produces a Fusion-equivalent recommendation: native Fusion functionality, Fusion Page Composer extension, Visual Builder Cloud Service (VBCS) page, Oracle Integration Cloud (OIC) flow, or BI Publisher report. Customers typically find 50–65% of .p customizations are redundant under Fusion's native capabilities — particularly approval workflows, sequence-numbering routines, and email-notification triggers that Fusion ships natively. The remaining 35–50% get re-implemented in Fusion-native tooling, not translated line-by-line.
QAD Reporting Framework reports, legacy character-mode Progress 4GL reports, and Crystal Reports built against the QAD OpenEdge database do not carry over to Fusion. The Syntra ETL assessment inventories every report in production use (via the QAD reportlist table, file-system scans for .p reports, and Crystal report repositories), classifies by business value, and proposes Fusion replacements: OTBI dashboards for ad-hoc manufacturing analytics, BI Publisher for pixel-perfect operational reports (work-order travelers, PPAP packages, shop packets), Fusion Financial Reporting Studio for management consolidation, and Smart View for Excel-tethered analysis. About 60–75% of legacy QAD reports turn out to be duplicates or obsolete and get retired. The remaining critical reports are rebuilt in Fusion-native tooling during the migration, not after — so go-live includes the reporting layer too.
Syntra ETL's QAD extractors read Progress OpenEdge natively — not via the flaky ODBC bridge that bespoke approaches typically rely on. The extractor uses the Progress JDBC driver with parallel partition reads keyed on domain, site, and year, restarts cleanly on failure, and stages output to cloud object storage as Parquet with hash signatures and manifest files. The largest gl_hist extract our customers run is 1.4 billion rows; the largest wod_det (work-order detail) is 2.6 billion. A typical billion-row extract completes in 5–8 hours on a modest QAD Progress OpenEdge source. Because we read OpenEdge natively, we get correct handling of Progress decimals, BLOBs, denormalized arrays, and the OpenEdge-specific NULL semantics that trip up ODBC-based tools.
No. Syntra ETL's QAD extractors connect with a read-only Progress user account (or via a CAN-READ grant on specific tables), throttled to avoid contention with online manufacturing users and the nightly MRP and batch windows. For the largest tables — gl_hist, wod_det, sod_det, tr_hist — extracts can be scheduled during the QAD batch window, or pulled from a Progress After-Imaging replica or OpenEdge Replication target to eliminate production impact entirely. No QAD application changes, OpenEdge upgrades, or .p file modifications are required. Shop-floor terminals, MRP runs, EDI feeds, and QXtend interfaces continue running normally throughout the extract window.
Book a 30-minute discovery call. We'll walk through your QAD modules, domain/site structure, .p file customization profile, and target Fusion pillars — and give you a concrete timeline and budget before the call ends.