InforERP PlatformEurope

Baan legacy + on-prem AI

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

Short answer

Baan IV and Baan V installations still run manufacturing operations across Europe, typically supported by a shrinking group of specialists who know the 4GL sessions, tables, and undocumented customisations by memory rather than by documentation. AI grounded on the Baan database and on 4GL source can capture that knowledge before it retires with the people who hold it, answer routine questions without a Baan specialist, and produce documentation that materially reduces risk and cost in an eventual migration to LN, CloudSuite, or another platform.

ERP: Baan IV, Baan V, Infor LN (early releases)
Industries: Manufacturing, Discrete Manufacturing, Industrial Equipment
Written for: CIO

Discuss your Baan IV environment See use cases

If you are still running Baan IV or Baan V, you are managing two risks simultaneously: keeping a genuinely stable manufacturing system running today, and knowing that the people who understand its customisations are not getting younger. Most Baan shops in Europe reached this point not through neglect but because the system works, migrations are expensive and disruptive, and 'we'll deal with it next year' has been true for several years running.

The practical problem this creates is knowledge concentration. A handful of people, sometimes one, understand why a given 4GL session was customised, what a particular table field is actually used for versus its documented purpose, and how a specific integration was patched together fifteen years ago to solve a problem nobody remembers the origin of. When that person is on holiday, retires, or leaves, the organisation's actual operating knowledge of its own ERP leaves with them.

AI is a reasonable tool against exactly this problem, independent of any eventual migration decision. A model grounded on the Baan database schema, session definitions, and 4GL source can answer 'what does this session actually do', 'which tables does this customisation touch', and 'has this error happened before and how was it resolved', turning undocumented tribal knowledge into a searchable, explainable resource. That is valuable whether you keep running Baan for another five years or start a migration next quarter.

It also changes the economics of an eventual migration. The single biggest cost driver in a Baan to LN or Baan to CloudSuite migration project is usually not the technical conversion, it is the discovery phase where consultants try to reconstruct what the current system actually does and why. If that discovery work has already been done, continuously, by an AI system that has been documenting the environment for a year or two before the migration project starts, the project itself gets materially cheaper and less risky.

What usually gets in the way

The problems we hear most from cio teams running Baan IV.

Specialist knowledge is concentrated in very few people

One or two people understand the customised sessions, the reasons behind them, and the workarounds built up over years. There is no realistic succession plan if they leave.

Documentation does not match reality

Whatever documentation exists from the original implementation is decades old and describes a system that has since been customised repeatedly without the documentation being updated to match.

Every migration estimate balloons in discovery

Migration proposals routinely underestimate the discovery phase because nobody outside the organisation, and often nobody inside it either, fully knows what the current Baan environment actually does.

4GL customisations are a black box to newer staff

Younger IT staff, if you can hire them at all for a Baan environment, have no path into understanding legacy 4GL customisations without leaning entirely on the one or two remaining specialists.

Business users route around the system instead of through it

When getting an answer out of Baan requires finding the right specialist, business users build spreadsheets and side processes instead, which quietly erodes the ERP's authority as the single source of truth.

Where AI earns its place in Baan IV

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

4GL session and customisation documentation

An agent reads 4GL session source and table definitions and produces plain-language documentation of what a given session or customisation actually does, for review by a Baan specialist.

Touches: 4GL session source, table definitions, DLL customisations

Outcome: Converts undocumented customisation logic into reviewed, searchable documentation over a period of months, rather than losing it entirely at the next departure.

Natural-language question answering over Baan data

Planners and buyers ask routine operational questions (order status, inventory, open purchase commitments) without navigating Baan sessions directly.

Touches: Order, inventory, and purchasing tables in the Baan database

Outcome: Reduces daily dependence on the one or two Baan power users for routine lookups.

Historical issue and workaround capture

An interview-style process, supported by the AI system, captures known issues, their root causes, and the workarounds developed for them, tied to the specific sessions and tables involved.

Touches: Incident records where they exist, session and table references from interviews

Outcome: Builds an institutional memory of recurring issues that survives staff turnover instead of being rediscovered from scratch each time.

Migration discovery acceleration

For organisations planning an eventual move to LN or CloudSuite, the accumulated documentation and Q&A history becomes a structured input to the migration discovery phase.

Touches: Full schema and session documentation built up over the AI system's operating life

Outcome: Shortens the discovery phase of a future migration project because the 'what does the current system actually do' question is already substantially answered.

Customisation impact assessment before changes

Before modifying a session or table, IT asks what else depends on it, based on documented relationships built from source analysis.

Touches: 4GL session cross-references, table dependency mapping

Outcome: Reduces the chance a change breaks an unrelated process nobody remembered was connected to it.

Onboarding accelerator for new IT staff

A new hire or contractor asks questions about the Baan environment and gets grounded, documented answers instead of relying entirely on the departing specialist's availability.

Touches: Full accumulated documentation base

Outcome: Cuts the ramp-up time for a new Baan-literate hire from many months of shadowing to a faster, self-directed start.

Vendor and partner cross-referencing

For decisions about consolidating vendors or suppliers, an agent pulls historical transaction and quality data spanning years from the Baan database.

Touches: Purchase order history, receiving and quality tables

Outcome: Gives procurement a longer, more reliable historical view than manual spreadsheet reconstruction typically achieves.

Reference architecture

The architecture reads the Baan database directly and, with appropriate access controls, 4GL session source, building a documented and queryable knowledge base over time. Everything runs on infrastructure you control, so a legacy system that has never been exposed to the internet stays that way.

1
Baan connectors
Direct database access (Baan typically runs on Oracle or Informix) for structured data, plus controlled read access to 4GL session source for documentation generation.
2
Data and semantic layer
A living map between Baan's table and session naming conventions and the business vocabulary your team uses, built and refined as questions are asked and answered.
3
Model serving
An open-weight model served with vLLM or Ollama on a modest on-prem GPU server, no different in scale from what a mid-sized manufacturer already runs for other purposes.
4
Retrieval and agents
Retrieval-augmented generation for operational Q&A, plus a documentation-generation agent that reads 4GL source and produces reviewed, plain-language explanations of what it does.
5
Governance and audit
Every generated document is marked as AI-drafted until a specialist reviews and signs off on it, and every operational answer is traceable to the source table or session it came from.

Integration notes for your ERP team

Baan IV/V typically runs on Oracle or Informix; direct database access for read use cases is usually the simplest and lowest-risk integration path.
4GL session source access requires coordination with whoever administers the Baan environment; treat this as a controlled, logged activity rather than open access.
Expect significant naming inconsistency across tables and sessions accumulated over years of customisation; budget real discovery time to build an accurate semantic layer rather than assuming standard Baan documentation still applies.
Documentation generated by the AI system should be explicitly marked as unreviewed until a Baan specialist signs off, to avoid it being treated as authoritative before validation.
If a migration to LN or CloudSuite is already planned, coordinate the AI documentation effort directly with the migration project team so the output feeds discovery rather than becoming a parallel, disconnected exercise.
Baan's session-based structure means cross-references between sessions are often implicit rather than declared; static source analysis alone will miss some dependencies that interviews with specialists can surface.

Deployment options

Air-gapped on-prem

Baan shops where the underlying manufacturing is defence-adjacent or otherwise sensitive, or where IT policy simply prohibits any external data path for a core system.

Model and connector run entirely inside your network, reading the Baan database and 4GL source with no outbound dependency required.

Private or sovereign cloud

Organisations that want the documentation and Q&A system to run in a private tenancy rather than adding hardware to an already aged data centre footprint.

AI infrastructure runs in a dedicated private cloud tenancy, with the Baan connector reaching back over a secured network path to the on-prem database.

Hybrid

A pragmatic starting point for many Baan shops: pilot on-prem against a database replica, with a private cloud option available for scale-out later.

Core model serving stays local to the network hosting Baan for latency and simplicity; documentation storage and search can run in a private cloud if preferred.

Compliance and data control

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

GDPR

Documentation and Q&A processing stays on infrastructure you control, so personal data present in customer, vendor, or HR-adjacent Baan tables never leaves EU jurisdiction or your own network.

Change control for legacy systems

The system is read-only against Baan by default; documentation generation and Q&A do not modify the production system, so existing change-control processes for Baan itself are unaffected.

Business continuity and knowledge risk

Formalising undocumented knowledge into a reviewed, versioned documentation base is itself a business-continuity control against key-person risk, worth noting explicitly in continuity planning.

Data residency

Running the model on-prem or in an EU-based private cloud keeps data processing within the jurisdiction, relevant for manufacturers with customers in regulated sectors who ask about data handling.

Where Netray fits

Custom build

Legacy 4GL source analysis and documentation generation, plus interview-driven knowledge capture, is specialised enough work to be a custom build rather than a standard product deployment.

ERPray

Once the semantic layer is built, day-to-day operational question answering over Baan data fits ERPray's read-only, query-transparent model directly.

How an engagement runs

Phase 1 . 3-4 weeks

Discovery

-Inventory of the Baan environment: version, database platform, known customisations
-Interviews with the current Baan specialists to capture what is not written down anywhere
-Assessment of database and 4GL source access options
-Prioritised list of the highest-risk, least-documented areas to tackle first

Phase 2 . 8-10 weeks

Pilot

-Working database connector and initial semantic layer
-First batch of AI-generated session documentation, reviewed by a Baan specialist
-Operational Q&A available to a pilot group of planners or buyers
-Accuracy review against known-answer questions

Phase 3 . 6-10 weeks

Production

-Documentation process running continuously across the remaining undocumented customisations
-Q&A rolled out to the wider operational team
-Governance process for reviewing and approving AI-generated documentation established
-Runbook for maintaining the system as Baan itself is patched or changed

Phase 4 . Ongoing

Scale

-Documentation base kept current as customisations change
-Output packaged as a direct input to migration discovery, if and when a migration project starts
-Periodic knowledge-risk review identifying remaining undocumented areas

Questions to ask any vendor, including us

A short list that separates real Baan IV AI work from a chatbot demo.

Does this require any change to the Baan production system, or is it strictly read-only?
How is AI-generated documentation reviewed and approved before anyone relies on it?
Where does the model run, and does any Baan data leave our network at any point?
How do you handle 4GL session cross-references that are not explicitly declared in the source?
If we later migrate to LN or CloudSuite, how directly does this documentation feed that project?
What happens to the documentation base if we change AI vendors later; do we retain it?
How do you prioritise which undocumented customisations to tackle first?
What is the realistic ongoing cost to keep this running for a mid-sized Baan environment?

Frequently asked questions

Is it worth investing in AI for a Baan system we plan to eventually replace?

Yes, particularly because it directly reduces the cost and risk of that eventual replacement. The documentation and knowledge capture work an AI system does while Baan is still running becomes the discovery input for a migration project, so it is not a sunk cost, it is preparation you would otherwise pay a migration consultancy to redo from scratch.

Can AI actually read and understand Baan's 4GL customisations?

A model can read 4GL source and table definitions and produce a reasonable plain-language explanation of what a session does, which a Baan specialist then reviews and corrects. It is a drafting and acceleration tool for documentation, not a fully autonomous substitute for someone who understands the business context.

How does this reduce key-person risk specifically?

By converting knowledge that currently exists only in a specialist's memory into reviewed, searchable documentation, so that if that person is unavailable, on leave, or leaves the organisation, the knowledge is still accessible rather than lost. It does not eliminate the value of experienced specialists, but it removes the single point of failure.

Does this work if our Baan environment has years of undocumented custom code?

That is precisely the scenario this is built for. The starting point assumes documentation does not match reality, and the process is designed to build accurate documentation from the actual source and database, validated against what specialists confirm, rather than relying on outdated original documentation.

Is our data safe given how old and potentially unpatched the Baan environment is?

The AI connector is read-only against the Baan database and source by default, and runs on separate infrastructure, so it does not increase the Baan system's own exposure. Running everything on-prem or in a private tenancy under your control keeps data from ever reaching a third-party cloud API.

How long does it take to see value from this?

Operational Q&A on core tables (orders, inventory, purchasing) can be usable within the pilot phase, roughly eight to ten weeks. Full documentation of a legacy customisation base built up over many years is necessarily a longer, ongoing process measured in months, prioritised toward the highest-risk areas first.

Can this help even if we have no current plan to migrate off Baan?

Yes. Reducing dependence on one or two specialists for daily operational questions, and building documentation as a continuity safeguard, has value independent of any migration decision. Many organisations run this for years before a migration is even on the roadmap.

Related guides

Infor LN + AI

AI for Infor LN: Sessions, BODs, and Engineer-to-Order Work

Add grounded AI to Infor LN 10.x or CloudSuite: natural-language answers over sessions and BODs, agents for project and engineer-to-order work, on-prem options.

Infor XA on IBM i + on-prem AI

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

Add AI to Infor XA on IBM i (AS/400) without a migration project. Read DB2 for i directly, ground answers in live XA data, keep everything on-prem.

ERP migration + on-prem AI

AI-assisted data migration for ERP implementations

AI speeds ERP data migration by profiling legacy data, proposing field mappings, and flagging cleansing issues before cutover, with a human validating every rule.

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.

ERP AI Buyer Guide

How to Choose an ERP AI Implementation Partner

A CIO checklist for picking an ERP AI implementation partner: the architecture questions to ask, red flags, pricing models, and what to demand in the SOW.

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.

Plan it with numbers

Free Tool

Talk it through with an engineer who knows Baan IV

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