Infor LX (BPCS) Reporting After Migration — Query/400 to OTBI / BI Publisher

Infor LX (BPCS) reporting after migration is the strategic rebuild of the reporting estate that BPCS supported — Query/400 reports, DDS-defined printer files, Crystal Reports against DB2 for i, RPG-program-driven reports, BPCS native reporting, custom IBM i jobstreams that produce monthly / quarterly / annual reports — into the modern reporting estate of the target ERP (Oracle Fusion OTBI / BI Publisher / Smart View) plus the data-warehouse and BI tools that go alongside. It is a distinct workstream because most BPCS customers underestimate how many reports they actually have (typically 100–500 Query/400 reports per customer, plus 20–100 Crystal / Cognos / other BI tool reports), how many are still in active use (typically 40–70%) and how much business judgment is encoded in the report logic that has to be preserved. The Infor LX (BPCS) reporting after migration workstream typically consumes 15–25% of total migration project budget and is the most common cause of post-cutover hypercare extensions when it's deferred.

The Infor LX (BPCS) migration assessment includes a report inventory module that crawls the IBM i for every Query/400 query, every DDS-defined printer file, every RPG program with PRTF output, every CL command that drives a scheduled report job, plus the third-party report inventory from Crystal Reports / Cognos / IBM Showcase / SequelOne servers that point at BPCS. Each report is classified along four axes. Usage: in active production use (run in the last 90 days), occasionally used (run in the last year), or orphaned (no recorded run). Business value: critical (board / regulatory / financial close), important (operational efficiency), nice-to-have. Target replaceability: native Fusion functionality covers it, OTBI dashboard rebuild, BI Publisher pixel-perfect report, Smart View Excel template, or genuinely unique business logic needing custom redevelopment. Migration disposition: rebuild during migration / retire / defer / hybrid (keep on BPCS for now). Most customers find 40–60% of legacy reports are redundant under Fusion's native breadth.

The right Fusion target depends on the report's nature. OTBI (Oracle Transactional Business Intelligence): for operational dashboards and analytical queries on current Fusion data — sales pipeline, AP aging, inventory turnover, work-order WIP, supplier scorecards. OTBI is self-service for power users and embedded directly in Fusion application screens. BI Publisher: for pixel-perfect operational reports — invoices, purchase orders, work-order travelers, shipment documents, regulatory filings. BI Publisher handles templated PDF / Excel / HTML output with data from Fusion or any external data source. Smart View: for finance-led Excel-based reporting — month-end close packs, board reports, multi-dimensional analysis, financial-statement reformulation. Smart View connects Excel directly to Fusion (and Hyperion / EPM if in scope) for live drill. Plus cloud DW + Power BI / Tableau / Looker for cross-system analytics combining BPCS history with Fusion data. The Infor LX (BPCS) reporting after migration rebuild plan assigns the right target per report based on the four classification axes.

Retro-reporting on closed BPCS history (e.g. multi-year trend analysis, year-over-year financial comparison, historical product profitability, 5-year inventory turnover trend) is critical and easily under-scoped. Two patterns. Pattern 1 — Historical loaded to Fusion: closed BPCS GL transactions, AP / AR history, sales / work-order history loaded to Fusion as historical periods with full BPCS audit-trail context preserved. Fusion OTBI and BI Publisher can then query unified history. Pattern 2 — Cloud DW pattern: closed BPCS history loaded to Snowflake / BigQuery / Databricks / Redshift alongside Fusion data; cross-system reporting via Power BI / Tableau / Looker / Sigma against the unified data. Pattern 2 is typically faster (no Fusion load), cheaper (cloud DW storage vs Fusion licence costs) and more flexible (any BI tool, any query) but requires the cloud DW pattern. Most customers run Pattern 1 for last 3 years (immediate Fusion drill) and Pattern 2 for 3–10 years (cloud DW retro-reporting).

Quick wins first. Roughly 30–40% of BPCS Query/400 reports have direct native equivalents in Fusion (standard AP aging, AR aging, trial balance, inventory value, sales-by-customer) — these are configured rather than rebuilt, typically 1–2 hours each. Another 30–40% rebuild as OTBI dashboards or BI Publisher reports with straightforward SQL translation, typically 4–16 hours each depending on complexity. The remaining 20–30% are the genuinely complex reports — multi-source joins, customer-specific business logic encoded in RPG, historical-vs-current comparisons that need both BPCS history and Fusion current data, regulatory reports with country-specific formatting rules. These take 16–80 hours each and need functional-business-user co-development. Total Infor LX (BPCS) reporting after migration effort for a typical mid-market BPCS customer with 200–400 in-use reports: 1,500–4,000 hours of rebuild work — 15–25% of total migration project budget.

Regulatory and SOX reports get priority and the highest rigour. The Syntra Infor LX (BPCS) reporting after migration framework treats regulatory reports as a separate workstream — every regulatory report identified in inventory, validated with compliance and tax leads, rebuilt with full audit-trail context and tested against the BPCS-produced equivalent for at least 1 parallel-run cycle. SOX-relevant reports (financial close pack, internal-control evidence pack, journal-entry audit trail, AP / AR aging for management certification) get the same parallel-run discipline. Regulatory tax reports (US 1099 / 1042, EU VAT returns, Spain SII, Italy SdI, Romania e-Invoicing, Mexico CFDI) rebuild in Fusion Tax with country-specific configuration validated by tax leads. Compliance signs off the reporting workstream as a precondition for cutover sign-off — and customers routinely pass first-quarter SOX testing after cutover without regulatory-report defects.

Yes, and this is the common pattern. During the 1–2 month-end parallel-run cycles between BPCS taking live transactions and Fusion taking over, BPCS users continue running Query/400 reports directly against BPCS for their day-to-day operational needs while the Fusion-target equivalent reports are validated. At each parallel-run month-end, the Fusion-side reports are produced and compared against the BPCS Query/400 output for the same period to confirm the rebuilds reproduce the same numbers (and where differences exist, they are documented with explanation). After cutover, BPCS Query/400 reports continue to be queryable against the read-only-archive BPCS for the hypercare period (typically 4–8 weeks) so users can compare side-by-side, but new operational reports run from Fusion. The Infor LX (BPCS) reporting after migration plan locks the BPCS-vs-Fusion comparison cadence.

Deferring the report rebuild to the last quarter of the migration project. The pattern: migration project focuses on master-data load, transactional load and integration; reporting is treated as 'we'll figure it out after cutover'; cutover happens; finance and operational teams discover they cannot run their day-to-day reports in Fusion; hypercare extends from 4–8 weeks to 4–6 months while the report estate is rebuilt under pressure. The right pattern: Infor LX (BPCS) reporting after migration starts at the migration assessment stage (report inventory and classification), runs in parallel with data-migration work through the build phase (most rebuilds completed by parallel-run start), and produces a complete Fusion-side reporting estate before cutover go / no-go. Cutover goes ahead only when 100% of critical-classified reports are validated against BPCS equivalents at parallel-run month-end.