InforERP PlatformUnited States

Infor XA on IBM i + on-prem AI

AI for Infor XA on IBM i: On-Prem, No Replatforming Required

Short answer

Infor XA still runs core manufacturing for a meaningful number of shops on IBM i, and none of them need to replatform to get value from AI. DB2 for i is a mature, well-understood database with SQL access, ODBC drivers, and years of tooling built around it, which is exactly what a retrieval-augmented question-answering system needs. The practical path is a connector that reads DB2 for i views on a schedule or via change data capture, paired with a model running on a small on-prem GPU server, so nothing about your XA environment has to change.

ERP: Infor XA, Infor XA on IBM i
Industries: Manufacturing, Discrete Manufacturing, Electronics
Written for: IT Director

Discuss your Infor XA environment See use cases

Infor XA on IBM i is one of the more durable ERP platforms in manufacturing, and one of the most frequently written off by vendors who assume everything has to move to a browser-based cloud product before it can be modernized. That assumption is wrong for AI specifically. DB2 for i supports standard SQL, has mature ODBC and JDBC drivers, and has been queryable by reporting tools for decades. A model that needs to answer 'which open orders reference this part' does not care whether the database sits on IBM i or SQL Server, it cares whether it can run a query against it.

The real friction in XA shops is usually organizational, not technical: a small IT team that keeps the green-screen and its RPG customizations running reliably, understandably cautious about anything that touches the production LPAR. That caution is well placed for changes to XA itself. It does not need to extend to a read-only connector that pulls from DB2 for i into a separate AI system running on its own hardware, with no changes to XA's application code.

For an IT director under pressure to show a modernization roadmap without a multi-year, multi-million-dollar replatforming project, AI grounded on the existing XA database is a credible interim step. It gives the business (planners, buyers, customer service) a faster way to get answers out of a system that is otherwise still running fine, and it buys time to make the ERP replacement decision deliberately instead of under deadline pressure from an unrelated AI mandate.

It also produces something a future migration project will need anyway: a documented, queried, and validated map of what the XA schema actually contains and how the business uses it, which is exactly the kind of asset that makes a later migration to SyteLine, CloudSuite, or another platform cheaper and less risky.

What usually gets in the way

The problems we hear most from it director teams running Infor XA.

Institutional knowledge is tied to the green screen

The handful of people who know which XA screen and field to check for a given question are also the people closest to retirement. New hires take months to get comfortable navigating XA menus for routine lookups.

IT is asked for AI with no replatform budget

Leadership wants generative AI, but there is no appetite for a multi-year ERP replacement project right now. Vendor pitches that assume a cloud migration first do not fit the actual budget or timeline.

Reporting is batch and after the fact

Most reporting against DB2 for i runs overnight or on a fixed schedule. Questions that need a current answer, like today's late orders, mean someone running an RPG program or query manually.

Custom RPG programs hold undocumented business logic

Years of customization mean the 'real' rule for how a field is calculated lives inside an RPG program, not in any documentation, making it hard for anyone outside IT to trust a number without checking with a developer.

Skills to maintain IBM i and RPG are shrinking

The pool of people who can competently support DB2 for i and RPG customizations is smaller every year, which raises the stakes on anything that could disrupt the existing system.

Where AI earns its place in Infor XA

Each use case names the ERP objects it reads or writes, so your ERP team can judge the integration effort before anyone commits budget.

Order and shipment status Q&A

Customer service asks about the status of a specific order, expected ship date, and whether anything is on hold, without opening XA screens.

Touches: Order header and line files, shipment and allocation files in DB2 for i

Outcome: Cuts the time to answer a customer status call from a multi-screen XA lookup to an immediate, cited answer.

Open purchase order and receipt tracking

A buyer asks which purchase orders are past due, which have partial receipts, and which vendors are consistently late.

Touches: Purchase order header/detail files, receiving transaction files

Outcome: Surfaces the vendors and lines actually driving expedite work instead of a flat report the buyer has to scan manually.

Inventory and item lookup

Planners ask on-hand quantity, allocated quantity, and where-used information for a part across warehouses.

Touches: Item master, inventory balance, and where-used files

Outcome: Removes a step that used to require navigating three or four XA menus to assemble one answer.

RPG business-rule documentation

An agent reads through RPG source (with IT oversight) and produces plain-language documentation of what a given program or calculation actually does.

Touches: RPG source members, copybooks, program documentation where it exists

Outcome: Builds a documentation base for logic that previously existed only in code, reducing risk when the one developer who understands it is unavailable.

Engineering change and BOM impact

Engineering asks which open jobs and orders reference a part or routing before making a change.

Touches: Bill of material and routing files, open order and job files

Outcome: Reduces the chance a change goes out against the wrong revision because nobody checked what was still open against the old one.

Demand and backlog summary for management

Operations leadership asks for a plain-language summary of backlog by product line or customer, without waiting for the weekly report cycle.

Touches: Order files, product/item classification files

Outcome: Gives leadership a current answer between report cycles instead of working from data that is a week old.

Vendor and quality history lookup

Quality asks about a vendor's rejection history for a specific part before approving a new lot.

Touches: Receiving inspection files, vendor master, nonconformance records if tracked in XA

Outcome: Turns a lookup that used to require a developer or power user's help into a self-service answer for the quality team.

Reference architecture

The connector reads DB2 for i through SQL/ODBC or journal-based change data capture, without modifying XA's application layer. A semantic layer translates IBM i file and field names into plain business terms, and the model runs on a dedicated GPU server that never has to touch the IBM i LPAR directly.

1
IBM i / DB2 for i connectors
SQL access to DB2 for i physical and logical files via ODBC/JDBC, or journal-based change data capture for near-real-time updates without polling.
2
Data and semantic layer
A translation layer mapping cryptic IBM i file and field names to the business vocabulary planners, buyers, and customer service actually use.
3
Model serving
An open-weight model served with vLLM or Ollama on x86 GPU hardware separate from the IBM i LPAR, sized to concurrent user load.
4
Retrieval and agents
Retrieval-augmented generation for lookups and status questions, plus narrowly scoped agents for tasks like RPG documentation generation, reviewed by IT before publishing.
5
Governance and audit
Access checks against the requesting user's role, a query log for every answer, and no write access back into XA files by default.

Integration notes for your ERP team

DB2 for i is reachable via standard SQL over ODBC/JDBC; most read use cases do not require touching RPG programs at all.
For fields whose real value depends on business logic buried in an RPG program (a calculated status, for example), plan a short discovery pass with a developer who knows the program before trusting the field.
Journal-based change data capture (using IBM i journaling) gives near-real-time updates without repeated full-table polling, which matters for status questions that need to be current.
Keep the AI stack on separate x86 GPU hardware; there is no need and generally no practical way to run model inference on the IBM i LPAR itself.
Where XA has been customized, expect field and file names that diverge from stock documentation; budget discovery time to validate the semantic layer against a few known-answer questions before going live.
Write-back is rarely worth the risk on XA; most pilots stay read-only, with any action items (an email, a documentation draft) handled outside the IBM i system entirely.

Deployment options

Air-gapped on-prem

Shops running XA for defense, government, or otherwise sensitive manufacturing that do not want data leaving the building.

GPU server and connector run inside your network, reading DB2 for i over your internal network with no outbound dependency.

Private or sovereign cloud

IT teams that want to avoid buying and racking new GPU hardware but still need control over where data and models run.

The AI stack runs in a private tenancy while the connector reaches back to your on-prem IBM i over a site-to-site VPN or dedicated link.

Hybrid

Teams piloting on one department before committing budget, or wanting DR options separate from the primary IBM i environment.

Core model serving stays close to the data for latency; ancillary functions like document indexing can run off the same network if convenient.

Compliance and data control

How the architecture supports your obligations. Certification and accountability stay with your organisation; the design keeps the evidence straightforward.

CMMC 2.0 / DFARS 252.204-7012

For XA shops supplying the DoD, keeping the model and connector inside the same network boundary as the IBM i system avoids sending CUI-adjacent order and part data to an external API.

Change control for regulated manufacturing

Because the connector is read-only against DB2 for i by default, it does not introduce a new change-control burden on the validated XA application itself.

Data residency

Running the model on infrastructure you control keeps order, customer, and part data inside whatever jurisdiction your compliance requirements specify.

Access control continuity

Queries are scoped by the requesting user's existing role, so someone without visibility into a plant's data in XA does not gain it through the AI layer.

Where Netray fits

ERPray

Grounded question answering over XA's order, inventory, and purchasing data through DB2 for i is a direct fit, with the underlying SQL shown for every answer.

Custom build

RPG documentation generation and other IBM-i-specific tasks are specialized enough to warrant a purpose-built agent rather than a general-purpose chat interface.

How an engagement runs

Phase 1 . 2-3 weeks

Discovery

-Review of DB2 for i schema, key files, and any relevant RPG customizations
-Assessment of ODBC/JDBC access and change data capture options
-Shortlist of pilot use cases, typically order status and inventory lookup first
-Hosting decision: air-gapped, private cloud, or hybrid

Phase 2 . 6-8 weeks

Pilot

-Working connector and semantic layer for the pilot use cases
-Model serving stood up on dedicated GPU hardware
-Pilot group of customer service, planning, or buying staff using it against live data
-Accuracy review against a set of known-answer questions drawn from real XA lookups

Phase 3 . 4-6 weeks

Production

-Access control and audit logging hardened for production use
-Rollout to the broader team beyond the pilot group
-Documentation of the semantic layer handed to your IT team
-Runbook for monitoring and incident response

Phase 4 . Ongoing

Scale

-Additional use cases (RPG documentation, engineering change impact) added from the backlog
-Periodic review of open-weight model options as they improve
-Optional extension into a future migration-readiness assessment if a replatform is eventually planned

Questions to ask any vendor, including us

A short list that separates real Infor XA AI work from a chatbot demo.

Does this require any change to our IBM i LPAR, RPG programs, or XA application code?
How does the connector read DB2 for i: direct SQL, journal-based change capture, or something else?
Can you show me the exact SQL behind an answer, not just the generated text?
What happens to data in transit between the IBM i system and the GPU server?
Do you require us to migrate off XA or onto a cloud platform before this works?
How is access scoped to match what a given user can already see in XA?
What is the ongoing cost to run this once the pilot ends, in hardware and support?
Can your team read and document RPG, or does that require our own developer's involvement throughout?

Frequently asked questions

Do we need to move off Infor XA or IBM i to use AI?

No. DB2 for i is a standard SQL-accessible database, and AI can be built to read it directly through ODBC/JDBC or journal-based change capture, with no changes to XA itself or the IBM i platform. Replatforming is a separate decision that is not a prerequisite for adding AI.

Is IBM i too old a platform for modern AI tooling?

No. The database layer (DB2 for i) has decades of mature SQL tooling built around it. The AI model itself runs on separate x86 GPU hardware, so the age of the IBM i platform is not a limiting factor for model performance, only for how the connector reads data out of it.

How do you handle business logic that lives inside RPG programs rather than the database?

For fields whose true value depends on RPG calculations rather than a straightforward column, we work with your developer during discovery to either replicate the logic in the semantic layer or have the agent read the RPG source directly to document and validate the rule before it is trusted.

Will this disrupt our production IBM i environment?

The connector is read-only against DB2 for i in the vast majority of deployments, running from separate hardware and querying on a schedule or via journal capture. It does not modify XA's application code, database structures, or the IBM i LPAR configuration.

What is a realistic first use case for an XA shop?

Order and shipment status lookup for customer service, and inventory or purchase order status for planners and buyers, are the most common starting points. Both are read-only, self-contained within a small set of DB2 for i files, and produce a daily time saving that is easy to measure.

Does this help if we eventually plan to migrate off XA?

Yes, indirectly. Building the semantic layer to answer questions accurately requires documenting what the XA schema actually contains and how fields are really used, which is exactly the kind of discovery work a future migration project needs, so it is not wasted effort either way.

Can this run fully on-prem for a defense-adjacent XA shop?

Yes. The model, connector, and application can run entirely inside your network on hardware you control, with DB2 for i accessed over your internal network and no outbound API dependency required for normal operation.

Related guides

Infor SyteLine / CSI + AI

AI for Infor SyteLine and CloudSuite Industrial

Add grounded AI to Infor SyteLine or CloudSuite Industrial: natural-language answers, agents over IDOs and ION, on-prem or CloudSuite deployment.

Infor VISUAL + on-prem AI

AI for Infor VISUAL ERP: Answers and Agents for Job Shops

Add AI to Infor VISUAL ERP for make-to-order and job shop manufacturers: quoting, scheduling, and shop floor answers grounded in live VISUAL data, on-prem.

Baan legacy + on-prem AI

AI for Legacy Baan IV/V: Capture the Knowledge Before It Walks Out the Door

Use AI to capture knowledge from ageing Baan IV/V systems, document undocumented customisations, and de-risk a future migration to LN or CloudSuite.

ERP AI Cost Guide

What ERP AI Actually Costs: A CFO's Guide

A CFO's guide to what ERP AI actually costs: GPU hardware, model licensing, integration and connector work, and realistic ongoing run-rate ranges.

On-prem AI, any ERP, A&D

On-Prem AI for ERP in Aerospace, Defense, and Electronics Manufacturing

A hub guide to on-prem AI across SAP, Infor LN, Costpoint, IFS, and Oracle EBS for aerospace, defense, and electronics manufacturers under ITAR, CMMC, and AS9100.

CSI, kept on-prem

On-Prem AI for CloudSuite Industrial, Without the Multi-Tenant Cloud Move

Add generative AI to CloudSuite Industrial without moving to Infor's multi-tenant cloud. On-prem private LLM options for CSI, with governance and audit built in.

Plan it with numbers

Free Tool

Talk it through with an engineer who knows Infor XA

Bring one real question your team cannot answer from the ERP today. We will map the data path, the model, and where it runs, and tell you honestly if AI is the wrong tool for it.

Start the conversation See ERPray

All AI for ERP guides