Pre-built QAD data conversion for every Financials, Manufacturing, and Distribution module. Native Progress OpenEdge extraction, domain/site crosswalks, FBDI emitters, row-level reconciliation. Audit-ready evidence at every load — IATF 16949, PPAP, 21 CFR Part 11.
The hard part isn't extracting rows from Progress OpenEdge. It's translating QAD's manufacturing data model into the target system's data model without losing meaning.
QAD and Oracle Fusion both serve manufacturers, but their data models diverged from the start. QAD uses domain/entity/site as its organisational backbone, packs lots of attributes into pt_mstr arrays and code_mstr lookups, treats work-order lifecycle as a status-code state machine, and stores everything in Progress OpenEdge — a database most enterprise ETL tools handle only via a brittle ODBC bridge. Fusion uses Enterprise/Legal Entity/Business Unit/Inventory Organization, has a richer item-class and category structure, treats work-order lifecycle through a more formal status model, and accepts data via FBDI/HDL/REST.
Every QAD data migration has to bridge these gaps — and the bridging is where projects slip from quarters into years. Custom SQL and hand-rolled Progress 4GL .p export scripts written by hand can do it, but each table is a multi-week negotiation between functional, technical, and audit teams. Syntra ETL replaces that with pre-built crosswalks refined across dozens of QAD migrations, especially for automotive, life sciences, and industrial verticals.
The same engine handles three deployment scenarios: full QAD replacement (Financials + Manufacturing + Distribution → Fusion), single-pillar migration (Financials-only), and the multi-plant consolidation pattern where dozens of regional QAD instances converge into a single Fusion deployment after M&A.
The transformations Syntra ETL ships pre-built. No custom Progress 4GL, no multi-month bespoke development.
QAD's flat account model with sub-accounts and cost-centers collapsed into Fusion's fixed 6-segment COA. Account-usage analyser identifies material splits; non-material attributes route to DFFs or PPM dimensions.
Multi-domain, multi-site QAD instances mapped to Fusion's Enterprise/LE/BU/Inv-Org hierarchy. Inter-company eliminations and multi-plant rollups preserved, regional consolidation patterns retained.
Cross-domain item-code de-duplication, QAD product line → Fusion item category translation, lot/serial flags preserved, planner/buyer codes converted to Fusion buyer-planner records.
Fuzzy-match de-duplication across vd_mstr, vd_addr, cm_mstr, cm_addr. Hierarchical relationships preserved, payment terms migrated, supplier sites and customer ship-to addresses remapped to Fusion's TCA party model.
ps_mstr (BOMs) and ro_det (routings) walked structurally per item, level-by-level, with quantity-per and operation-time fidelity preserved. Engineering-change history flattened where target ECN model differs from QAD.
Lot and serial records from in_mstr, ld_det, and tr_hist preserved across migration so PPAP genealogy queries and pharma 21 CFR Part 11 audit chains remain reproducible post-migration.
A repeatable load order that respects Fusion's data dependencies. Skip a step and your work-order load fails on missing items, BOMs, or routings.
Fusion enterprise structures, ledgers, BUs, inventory orgs, COA segments, value sets, calendars configured. Loaded via FSM tasks or migration utility — not user-facing data, but everything downstream depends on it.
Chart of Accounts segment values, value sets, account hierarchies loaded via FBDI ChartOfAccounts and Value Set templates. Validated against QAD ac_mstr trial balance for parent-child integrity.
Suppliers (FBDI Supplier Import from vd_mstr), customers (FBDI Customer Import from cm_mstr), items (FBDI Item Import from pt_mstr), BOMs (ps_mstr → Fusion BOM Open Interface), routings (ro_det → Fusion Routing Open Interface), work centers (wc_mstr). Loaded in dependency order — items before BOMs before routings before work orders.
GL period balances (FBDI Journal Import from gl_hist closing balances), AP open vouchers (FBDI AP Invoice Import from ap_mstr), AR open invoices (FBDI AutoInvoice from ar_mstr), open POs (po_mstr/pod_det), open work orders (wo_mstr/wod_det), on-hand inventory snapshot (in_mstr/ld_det). Each load reconciled to QAD before next stage.
Closed-period historical data (gl_hist, tr_hist, wod_det closed) loaded if Fusion is the target archive, or routed to Syntra archive if cold-data lifecycle dictates. Either way, queryable for audit and PPAP during full retention window.
Final delta replay, parallel-close reconciliation, sign-off pack generation (trial balance, AP/AR aging, on-hand inventory, open WO list — QAD vs Fusion to the cent and to the unit). Production cut to Fusion.
Every QAD data migration load produces signed, drill-downable reconciliation reports — manufacturing-specific.
Source QAD row count vs Fusion-loaded row count per table, per period, per domain, per site. Variance threshold zero for GL; configurable for archival-only domains.
Debit, credit, amount, quantity, and on-hand sums reconciled per period per ledger per inventory org. Variance flags surfaced before any subsequent load is allowed to proceed.
Each record content-hashed at QAD source and re-hashed post-Fusion-load. Hash drift indicates transformation bug or corruption — surfaced with row-level diff.
QAD ac_mstr/gl_hist trial balance per entity per period vs Fusion trial balance, drillable to journal line, sub-ledger source, and originating voucher/invoice/inventory transaction.
QAD in_mstr / ld_det quantity-on-hand by item by location by lot/serial vs Fusion inventory by item by sub-inventory by lot/serial. Reconciliation by inventory org with full lot-genealogy preservation.
QAD open wo_mstr list with status and remaining quantity vs Fusion open work-order list. Lot/serial traceability chains preserved end-to-end for IATF 16949 and 21 CFR Part 11 evidence.
QAD data migration is the process of moving master data (items, customers, suppliers, BOMs, routings, GL accounts), open transactional records (POs, sales orders, work orders, AP, AR), and historical archives out of QAD Adaptive ERP (or older QAD Enterprise Applications / MFG/PRO) into a target system — typically Oracle Fusion, SAP S/4HANA, or a modern cloud ERP. The technical heart of the work is two-layered: first, extracting from Progress OpenEdge (which most generic ETL tools handle poorly), then transforming QAD's domain/site/entity model into the target system's data model. Syntra ETL handles both layers natively, with pre-built extractors for every QAD module and governed crosswalks tuned for manufacturing verticals — automotive, life sciences, consumer products, industrial.
The terms are used interchangeably in practice, but the technical distinction is useful: migration is the end-to-end project (extract + transform + load + reconcile + cutover), while conversion is the transformation layer specifically — the rules that turn QAD data structures into target-system-shaped data. Syntra ETL's QAD data conversion engine ships with pre-built rules for ac_mstr → Fusion COA collapse, vd_mstr/cm_mstr de-duplication, pt_mstr → Fusion item-class translation, wo_mstr lifecycle-state mapping, and domain/site → enterprise-structure translation. These are the rules that, on a consultant-led project, would otherwise consume 5–7 months of bespoke Progress 4GL and SQL development.
QAD's pt_mstr is the heart of any manufacturer's master data — it carries item code, description, product line, item type, ABC class, planner code, buyer code, lead time, safety stock, lot control, serial control, and dozens of vertical-specific attributes. Multi-domain QAD instances often have item-code overlaps where the same code means different items in different domains. Syntra ETL's pt_mstr converter analyses cross-domain item identity, applies fuzzy-match de-duplication, maps QAD product lines to Fusion item categories, translates planner/buyer codes to Fusion buyer-planner records, and emits Fusion Item Open Interface (FBDI) loads with full attribute fidelity. Lot and serial control flags map to Fusion lot/serial enabled flags, preserving traceability for automotive PPAP and pharma 21 CFR Part 11 contexts.
Yes — with the standard Fusion caveat. Fusion Manufacturing Cloud's open-work-order load accepts in-flight WOs (released, in-process, completed-not-closed) with their components, operations, and resource usage. It does not accept arbitrary historical closed work orders directly into operational tables. Syntra ETL's approach: load open and recently-closed WOs into Fusion Manufacturing for operational continuity, and route the full historical wo_mstr / wod_det / ro_det / tr_hist detail to Syntra's QAD archive where it remains queryable for PPAP traceability (15 years post-EOP under IATF 16949), 21 CFR Part 11 (up to 30 years for some pharma classes), and tax purposes. This satisfies both Fusion's operational scope and historical compliance without paying Fusion storage for cold data.
Syntra ETL emits all three Fusion-native load formats: FBDI (File-Based Data Import) ZIPs for Financials, SCM, and Manufacturing (GL_INTERFACE, AP_INVOICES_INTERFACE, AR_INTERFACE_LINES, EGP_ITEM_OPEN_INTF, INV_TXN_INTERFACE, WIE_WO_OPEN_INTERFACE, etc.); HDL (HCM Data Loader) bundles where the QAD migration includes the HR/payroll add-on; and REST API payloads for incremental delta loads, supplier portal updates, and real-time integration. Each format is validated against the current Oracle Fusion 26x release schema before submission, so validation errors are caught locally — not in a 4-hour Fusion ESS job that fails on row 47,000 with an unhelpful error.
Every record extracted from QAD is hashed at the source. Every record loaded into Fusion is re-hashed post-load. The reconciliation engine compares counts, sum totals (debits, credits, amounts, quantities, on-hand), and hash signatures per table, per period, per domain, per site. Any record that fails Fusion validation is captured in an error report with the exact field-level reason — ready for bulk fix or escalation. The output is a signed, timestamped reconciliation pack: QAD trial balance vs Fusion trial balance to the cent, AP aging vs AP aging, on-hand inventory vs Fusion inventory by item by location, open WO count vs open WO count. Internal audit signs off on the pack directly; no rebuild needed.
Yes. After the initial bulk load, Syntra ETL captures QAD deltas via LAST_UPDATE_DTTM watermarks on the source tables (or optionally via Progress OpenEdge After-Imaging or OpenEdge Replication for high-velocity tables like tr_hist and gl_hist) and replays them into Fusion through REST APIs and incremental FBDI. This supports the standard parallel-run pattern: QAD continues taking production traffic for 1–2 close cycles while Fusion is validated against QAD to the cent. Once finance, manufacturing, and audit are comfortable, traffic cuts to Fusion and QAD moves to archive-only mode.
QAD supports multi-currency at the entity and transaction level (ac_mstr has currency code, gl_hist carries both transaction and base currency amounts), and multi-language via QAD's translation tables (mfc_ctrl and the language-specific msg_det records). Syntra ETL's converter preserves the original transaction currency on every migrated record, maps QAD's currency-rate-type model to Fusion's daily/spot/corporate rate types, and translates QAD language codes to Fusion's locale model. Item, customer, and supplier descriptions are migrated in all configured QAD languages so multi-region users see their localised data in Fusion from day one.
30-minute call. Walk through your QAD data volumes, domain/site structure, item-master complexity, manufacturing history depth, and target Fusion pillars — leave with a concrete data-migration plan.