Pre-built Infor LX (BPCS) data conversion for Financials, Manufacturing, Inventory and Order Management. DB2 for i extractors, EBCDIC translation, COMP-3 packed-decimal handling, UDF-to-DFF crosswalks, FBDI / HDL emitters, row-level reconciliation. Audit-ready evidence at every load.
The hard part isn't running SELECT against DB2 for i. It's translating a 1980s IBM midrange data model — packed-decimal numerics, EBCDIC character sets, file-based normalisation, RPG-bound business rules — into Fusion's modern shape without losing precision or audit-trail context.
Infor LX (BPCS) presents a DB2-for-i data model built around physical files (PF) and logical files (LF) with names like GLM, GLT, IIM, IIH, ECH, MHM, ACL, CIM. Numeric fields are typically COMP-3 packed-decimal or zoned-decimal for storage efficiency on the original IBM System/38 / AS/400 hardware. Character fields are stored in EBCDIC (CCSID 037 for US, 285 for UK, 1140 / 1148 for Euro-enabled). Business logic lives in RPG IV / III programs that read and update these files directly, with referential integrity often enforced in code rather than at the database layer.
Oracle Fusion uses a wholly different shape — Cloud-native ERP with normalised relational tables, Unicode character storage, separate API / FBDI / HDL ingestion layers, and business rules expressed in Visual Builder, AMX and BI Publisher. Every Infor LX (BPCS) data migration to Oracle Fusion has to bridge those gaps without breaking the audit chain that links a GL journal line back to its originating BPCS transaction, the RPG program that wrote it, and the IBM i user profile that ran the program. Custom RPG export programs and one-off SQL transforms can do it — but every domain becomes a multi-month negotiation between functional, technical and compliance teams, and finding an RPG developer who remembers what a 1996 customisation does is its own multi-week problem.
Syntra ETL replaces that with pre-built crosswalks refined across dozens of BPCS conversions. The same engine handles three deployment scenarios: full BPCS replacement (Financials + Manufacturing + Inventory + Order Management → Fusion), Financials-first migration with Manufacturing and Order Management following in a later phase, and the consolidation pattern where BPCS continues running for shop-floor while Financials moves to Fusion ahead of the full cutover.
The transformations Syntra ETL ships pre-built. No custom RPG export programs, no multi-month bespoke SQL development, no AS/400 expert required from your team.
CCSID-aware translation handling 037, 285, 1140, 1148 and the long tail of regional code pages. COMP-3 packed-decimal and zoned-decimal numeric fields preserved with full precision through round-trip into Fusion.
BPCS UDFs walked, classified by reporting materiality, and routed: required UDFs collapse to Fusion COA segments, optional UDFs route to Fusion DFFs on the matching entity, analytical UDFs go to OTBI dimensions or archive.
PSM / PSC bills of material and RTM / RTO routings translated to Fusion Manufacturing's item-structure-routing-work-definition model with full effectivity-date and engineering-change history preserved.
Historical translation rates stamped on each GLT / APH / RAH transaction preserved through to Fusion so retro-reporting reproduces the exact functional-currency amount BPCS originally posted, per-currency, per-period.
BPCS audit-trail files and IBM i database journals captured as evidence metadata, preserving the original SOX / FDA-relevant chain from GL journal back to RPG program execution on the AS/400.
BPCS Company (CCM), Warehouse (WHM) and Location (LOC) configurations mapped to Fusion Legal Entities, Ledgers and Inventory Organizations with transaction-level traceability preserved.
A repeatable load order that respects Fusion's data dependencies. Skip a step and your AP voucher load fails on missing suppliers, or your inventory balance load fails on missing items.
Fusion enterprise structures, ledgers, BUs, COA segments, calendars, currencies, conversion-rate types, Inventory Organizations configured. Loaded via FSM tasks — not user-facing data, but everything downstream depends on it. BPCS Company / Warehouse mapping locked here.
Suppliers (FBDI Supplier Import from ACL), customers (FBDI Customer Import from CIM), items (FBDI Item Import from IIM), GL chart segments and account combinations (FSM Chart of Accounts setup from GLM). Loaded in dependency order — items before BOMs, suppliers before vouchers.
Item structures / BOMs (FBDI Item Structure Import from PSM / PSC), routings and operations (FBDI Routing Import from RTM / RTO), work definitions (FBDI Work Definition Import) — loaded into Fusion Manufacturing with effectivity-date and ECO history preserved.
Open AP vouchers (FBDI AP Invoice Import from APO), open AR invoices (FBDI Receivables Invoice Import from RAO), open sales orders, open purchase orders, open work orders, inventory balances (FBDI Inventory Balance Import from IIH). Approval / aging / hold context preserved.
Closed GL transactions (FBDI Journal Import from GLT) for retro reporting, closed AP / AR history, closed work-order history, shipment history — loaded if Fusion is the target archive; older history routed to long-term BPCS archive. Either way, queryable for SOX / FDA retention.
Final delta replay via IBM i journal, parallel-month-end reconciliation, sign-off pack (trial balance, AP aging, AR aging, inventory value per warehouse — BPCS vs Fusion to the cent). Production cut to Fusion. IBM i moves to read-only archive.
Every Infor LX (BPCS) data migration load produces signed drill-downable reconciliation reports.
Source BPCS GL line count, AP voucher count, AR invoice count, item count, BOM count, work-order count, sales-order count, PO line count vs Fusion-loaded counts per company per period. Variance threshold zero.
Functional-currency debits / credits, AP balance, AR balance, inventory value per warehouse, work-order WIP balance reconciled per period per company. Variance flags surface before any subsequent load is allowed.
Each BPCS record content-hashed at source and re-hashed post-Fusion-load. Hash drift indicates transformation bug, EBCDIC mistranslation or COMP-3 precision loss — surfaced with row-level diff.
BPCS trial balance per period per company vs Fusion trial balance, drillable to GL line, AP voucher, AR invoice and originating BPCS audit-trail record.
Inventory value per warehouse per item per period reconciled between BPCS IIH and Fusion Inventory. Lot / serial detail spot-checked at item level.
BPCS audit-trail record counts and IBM i journal entry counts per period reconciled between source archive and target evidence pack. SOX / FDA chain provably intact after IBM i decommissioning.
Infor LX (BPCS) data migration is the process of moving GL transactions (GLT), AP vouchers (APH/APT/APO), AR invoices (RAH/RAT/RAO), item master (IIM), item balance (IIH), bills of material (PSM/PSC), routings (RTM/RTO), work orders (MHM/MHD), sales orders (ECH/ECL), purchase orders (HPO/HPL), supplier master (ACL), customer master (CIM) and the full BPCS audit-trail history out of the IBM i / DB2 for i source and into Oracle Fusion Financials, Manufacturing, Inventory and SCM. The technical heart is twofold: streaming structured data through DB2 for i via JDBC with EBCDIC-to-UTF-8 conversion and COMP-3 packed-decimal handling, and emitting Oracle-validated FBDI / HDL payloads ready for Fusion ESS submission. Syntra ETL handles both with pre-built extractors and governed crosswalks — no RPG, COBOL or CL code is required on the source side.
The terms get used interchangeably but the distinction matters in scoping. Migration is the end-to-end project (extract + transform + load + reconcile + cutover); conversion is the transformation layer specifically. Syntra ETL's Infor LX (BPCS) data conversion engine ships pre-built rules for BPCS Company → Fusion Legal Entity / Ledger mapping, ChartField → COA segment translation, BPCS Warehouse → Fusion Inventory Organization, item master rationalisation (purging the duplicate-item long tail), BOM and routing translation to Fusion's work-definition model, customer / supplier deduplication, AP / AR open-item carry-over and historical-rate currency carry-over. These are rules that on a consultant-led project would otherwise eat 4–6 months of bespoke RPG / SQL / mapping-document development.
BPCS retains transaction-level audit trails in dedicated audit files (GLAT for GL, APAT for AP, RAAT for AR, IIAT for inventory, MHAT for manufacturing) plus IBM i journals at the database layer. SOX requires 7-year retention with auditable trace from GL journal back to originating transaction; in pharma (FDA 21 CFR Part 11) the chain must include the original user, terminal and timestamp on the source AS/400. Syntra ETL preserves the full chain: every BPCS audit-trail record is extracted, hash-signed and either migrated to Fusion (where Fusion has equivalent native audit) or routed to the long-term BPCS archive with signed evidence and read-access logging. The Infor LX (BPCS) data migration leaves the SOX / FDA chain intact even after the IBM i is decommissioned — auditors can still drill from a Fusion GL journal back to the originating RPG program execution timestamp.
Yes. BPCS UDFs (User-Defined Fields added through the LX customisation framework) are the equivalent of EBS DFFs or PeopleSoft ChartFields. Syntra ETL's Infor LX converter walks every active UDF on every BPCS file, identifies which fields drive material reporting splits in Fusion's 6-segment COA, and proposes routing: required UDFs collapse into Fusion COA segments, optional UDFs route to Fusion DFFs on the matching entity (Item, Supplier, Customer, Project), and analytical-only UDFs route to OTBI dimensions or to the long-term BPCS archive. Custom RPG-bound business rules attached to UDFs are inventoried and re-implemented in Visual Builder, AMX approval flow or BI Publisher logic during the Infor LX (BPCS) data migration.
Syntra ETL emits Fusion-native load formats for every BPCS data domain: FBDI Journal Import for historical GL, FBDI Supplier / Customer / Item Import for masters, FBDI AP Invoice Import for open vouchers, FBDI Receivables Invoice Import for open AR, FBDI Item Structure / Routing / Work Definition for Manufacturing, FBDI Inventory Balance Import for stock, HCM Data Loader (HDL) for any worker-side context, and REST API payloads for incremental delta loads during parallel-run and post-cutover. Every payload is validated against the current Oracle Fusion 26x release schema before submission, so validation errors surface locally on your desktop or build server — not in a 4-hour Fusion ESS job that fails on row 47,000 and forces a full re-run.
Every BPCS record extracted is hashed at the source (header hash + line hashes + audit-trail hash). Every record loaded into Fusion is re-hashed post-load. The reconciliation engine compares counts (GL lines, AP vouchers, AR invoices, items, BOMs, work orders, sales orders, PO lines), sum totals (functional-currency debits / credits, AP balance, AR balance, inventory value per warehouse per period) and hash signatures per company per period. Any record that fails Fusion validation is captured with the exact field-level reason ready for bulk fix. Output is a signed timestamped reconciliation pack: BPCS trial balance vs Fusion trial balance to the cent, AP aging vs aging, AR aging vs aging, inventory value vs value per warehouse. Internal audit signs off on the pack directly — no rebuilding the reconciliation from scratch in Excel.
Yes. After the initial bulk load, Syntra ETL captures BPCS deltas via the IBM i database journal (which records every insert / update / delete with timestamp and user) or via a timestamp-watermark on each file (LST-UPD-DATE / LST-UPD-TIME fields BPCS already maintains on most master and transactional files) and replays them into Fusion through REST APIs. This supports the standard parallel-run pattern: BPCS continues taking transactions for 1–2 month-end close cycles while Fusion is validated to the cent. Once finance, manufacturing ops and compliance sign off, new transactions cut to Fusion and the IBM i / BPCS moves to read-only archive mode. No transactions are lost, no double-postings occur.
BPCS multi-currency is held in the MCM currency master plus the in-flight currency rate in each GLT, APH and RAH transaction. Syntra ETL preserves both the historical translation rate stamped on each transaction (so retro-reporting reproduces the exact functional-currency amount BPCS originally posted) and the period-end rates needed for Fusion's currency translation. Customers with 10+ currencies and 20+ years of history routinely carry millions of historical rates through the migration without loss of precision — and the Fusion trial balance reconciles to the BPCS trial balance to the cent on a per-currency, per-period basis. The Infor LX (BPCS) data migration also preserves the original BPCS currency code on each record for retro-audit traceability.
30-minute call. Walk through your BPCS volumes, UDF design, multi-company / multi-warehouse layout and IBM i landscape — leave with a concrete Infor LX (BPCS) data migration plan. No RPG expert required on your side.