Infor LX (BPCS) Migration Reconciliation Framework — Cutover-Ready

Infor LX (BPCS) migration reconciliation is the structured discipline of proving — at every stage from initial extract through parallel-run sign-off — that the data leaving IBM i / DB2 for i and arriving in Oracle Fusion is complete, accurate and audit-trail-preserved. It is distinct from generic post-load validation in that it spans the full migration lifecycle (master-data load, open-transactional load, historical-transactional load, parallel-run delta replay, final cutover, post-cutover delta replay) rather than just a single load run. It produces a versioned reconciliation register that internal audit, external audit, SOX testers, FDA Part 11 reviewers and the migration steering committee can all sign off against. Without an Infor LX (BPCS) migration reconciliation discipline, the migration ships with hidden drift that surfaces months later as restated financials or failed compliance attestation.

The Syntra ETL framework has four mandatory control points and several optional ones. Control Point 1 (Source baseline): BPCS source counts, sums and hashes captured at extract time, signed and timestamped — this is the contractual source of truth for the migration. Control Point 2 (Staged transform): post-transform counts, sums and hashes captured in the staging layer (Parquet) before FBDI / HDL emission — proves transformations are deterministic. Control Point 3 (Fusion post-load): counts, sums and hashes captured from Fusion directly post-load — proves the load was complete and accurate. Control Point 4 (Parallel-run delta): delta records captured from BPCS via IBM i journal during the parallel-run window, replayed into Fusion, reconciled against BPCS parallel-run figures — proves the cutover moment is clean. Optional: per-month-end-close reconciliation during parallel run, per-quarterly-tax-filing reconciliation, per-physical-inventory reconciliation.

Phased migrations (Financials first, Manufacturing later, Order Management last) are the most common BPCS pattern because the modules have less cross-dependency than they look. The Infor LX (BPCS) migration reconciliation framework runs phase-scoped reconciliation registers — Phase 1 (Financials) produces its own register reconciling GL, AP, AR, Fixed Assets, supplier master, customer master across source BPCS and target Fusion, signed and locked at Phase 1 cutover. Phase 2 (Manufacturing) produces its own register reconciling item master, BOMs, routings, work orders, MRP. Phase 3 (Order Management) reconciles sales orders, pricing, shipments. Each phase signs off independently, and a final consolidated reconciliation register at end-of-all-phases proves the cumulative cutover. The phased pattern is especially common for customers running BPCS shop-floor for 12–18 months after BPCS Financials has moved to Fusion.

BPCS audit-trail files (GLAT, APAT, RAAT, IIAT, MHAT) and IBM i database journals carry the SOX / FDA-relevant evidence chain — every Fusion GL journal must trace back through Fusion Journal → BPCS GLT → BPCS GLAT → IBM i journal → original RPG program execution timestamp, user profile and terminal on the AS/400. The Syntra Infor LX (BPCS) migration reconciliation framework preserves and proves the chain at every control point. The reconciliation register includes per-period audit-trail record-count reconciliation (BPCS GLAT count for period X vs BPCS long-term archive count for period X), per-period IBM i journal entry count reconciliation, and a per-quarter spot-audit drill (random sample of 50 Fusion GL journals drilled back to originating BPCS RPG program execution, signed by internal audit). Pharma customers under FDA 21 CFR Part 11 routinely pass the chain-of-custody review on first attempt.

Yes — at the cent, per company, per period, per currency. The cutover reconciliation pack includes BPCS trial balance per company per period per currency vs Fusion trial balance to the cent, BPCS AP open balance per supplier per currency vs Fusion equivalent, BPCS AR open balance per customer per currency vs Fusion equivalent, BPCS inventory value per warehouse per item per period vs Fusion equivalent, BPCS work-order WIP per Inventory Org vs Fusion equivalent, and BPCS open-PO accrual per supplier vs Fusion equivalent. The variance threshold for cutover sign-off is zero. Where rounding differences are mathematically unavoidable (typically sub-$1 per currency per period from currency-conversion rounding rules differing between BPCS and Fusion) the rounding pattern is documented and signed off in the cutover reconciliation pack.

BPCS multi-company configurations (CCM company master with intercompany journal-rule definitions) produce intercompany balances that must net to zero per intercompany pair per period. The Infor LX (BPCS) migration reconciliation framework includes an intercompany reconciliation control that runs per intercompany pair: BPCS net intercompany balance for Pair X (Company A → Company B) for Period Y vs Fusion net intercompany balance for the equivalent Legal Entity pair for the equivalent period. Variance threshold is zero. Where BPCS intercompany journals are mid-cycle (entered in one company, not yet matched in the other) the reconciliation surfaces them as 'in-flight' and tracks them through to settlement. The reconciliation handles 10+ intercompany pairs across 5+ companies without issue — customers with complex multi-entity manufacturing operations routinely pass intercompany reconciliation at first parallel-run month-end.

Discovery → diagnosis → bulk fix → re-reconciliation → sign-off, typically within 24–48 hours per variance class. The framework surfaces variance at row level with the specific BPCS source record, the specific Fusion target record (or absence), the specific field-level variance, and the suggested fix (CCSID adjustment, COMP-3 precision fix, transformation rule patch, mapping table update, manual exception flag). Bulk fixes are scoped to the variance set — not full reload. Re-reconciliation runs against the fixed scope and produces a delta reconciliation report showing the variance closed. The variance, the fix and the re-reconciliation are all captured in the reconciliation register with a clear audit trail. Customers routinely close 90% of variances within 48 hours and the remaining 10% (usually genuine business-rule edge cases) get documented exception flags for sign-off by finance and internal audit.

1–2 month-end close cycles is the standard parallel-run reconciliation window for BPCS to Fusion. During parallel run, BPCS continues taking live transactions and the Infor LX (BPCS) migration reconciliation framework captures BPCS deltas via the IBM i database journal, replays them into Fusion through REST APIs, and runs daily / weekly reconciliation throughout the window. At each parallel-run month-end close, both BPCS and Fusion run their full month-end procedures and the reconciliation framework produces a full trial-balance, AP aging, AR aging, inventory-value, work-order-WIP and intercompany-balance reconciliation pack signed by finance, manufacturing ops and internal audit. After 1–2 successful parallel-run cycles with zero unexplained variance, the steering committee signs off cutover. The BPCS / AS/400 then moves to read-only archive mode and new transactions cut to Fusion only.