Legacy ERP Integration

The reality of legacy ERPs in manufacturing

A large share of manufacturing — particularly in industrial, automotive supply, and process industries — still runs on ERPs that are 15+ years old. AS/400 (now IBM i) systems from the 1990s remain in production. Heavily customized JDE World installations from before EnterpriseOne. In-house mainframe systems that the company's IT team has maintained for decades. These systems work, but they're not getting modernized any time soon.

For these customers, the question isn't whether to integrate modern planning with legacy ERP — the legacy system isn't going away in the planning horizon. The question is whether the integration can be practical without forcing modernization first.

Three practical integration paths for legacy ERPs

1. Direct database extraction

Most legacy ERPs run on documented databases — DB2 on AS/400, Oracle 11g on older Unix systems, SQL Server 2008 or earlier on Windows. The data is accessible, the schema is documented (even if internally), and customer DBA teams can provision read-only access to relevant views or replicated tables.

This is the most common path for AS/400-based JDE World, older Infor (Baan, Symix), older QAD MFG/PRO, and in-house mainframe systems. The customer's DBA team creates views that expose the data Horizon needs; Horizon's integration reads those views on a scheduled cadence.

2. Scheduled file exchange

For systems where direct database access isn't practical — regulatory environments, air-gapped systems, vendor-managed legacy systems — scheduled file exchange remains effective. The legacy ERP exports data on a defined schedule (typically nightly) to a secured location; Horizon ingests the files.

The pattern is well-understood, well-tested, and works reliably across decades of enterprise integration. File-based exchange has been the backbone of enterprise data movement for 40 years and remains the standard mechanism in many production environments.

3. Middleware as translation layer

Some customers have invested in middleware platforms — TIBCO, IBM MQ, Boomi, MuleSoft — that already translate between their legacy systems and modern applications. Horizon connects to the middleware layer; the middleware handles the legacy system's specific interfaces.

When middleware exists, this is often the fastest integration path because the customer's middleware team has already solved the legacy-system-specific problems.

What legacy ERP integration realistically takes

For a typical legacy ERP integration, the timeline is heavier than modern ERP integration:

• Week 1-3: Discovery — understanding the specific legacy system, its data model, what data is accessible, what customizations exist. This often involves multiple conversations with the customer's long-tenured IT staff who hold the institutional knowledge.
• Week 3-6: Data access setup — DBA team provisions views, IT team configures scheduled extracts, or middleware team configures the translation layer.
• Week 6-10: Master data load and validation. Legacy systems often have data quality issues that surface during this phase — duplicate records, inconsistent product hierarchies, dead items still marked active. Cleanup happens during integration.
• Week 10-14: Forecast generation, parallel run, validation against existing planning approaches.
• Week 14-18: Cutover. First operational cycle in Horizon.

The total is typically 14-20 weeks versus 8-12 weeks for modern ERP integration. The extra time goes to discovery and data quality work, not the technical integration itself.

Common legacy ERP patterns

AS/400 / IBM i based systems

Including legacy JDE World, older Infor products (Baan, Symix), and in-house systems built on RPG/COBOL. DB2 database access through ODBC or JDBC. Files often have well-known names (F4101 for item master in JDE, etc.) that integration teams recognize.

Mainframe-hosted systems

For customers running ERPs on IBM z/OS mainframes (less common in pure manufacturing but still present in conglomerates), integration is typically through scheduled file exchange. Direct database access is technically possible but usually not preferred by the customer's mainframe team.

Older Unix-based systems

SAP R/3, older Oracle E-Business Suite, BPCS, MAPICS — many of these run on Unix/AIX/Solaris infrastructure with Oracle or DB2 databases. Direct database access works well; the data models are documented.

In-house ERPs

Some manufacturers have built and maintained their own ERP over 20-30 years — typically because no commercial ERP fit their unique manufacturing process. Integration is a discovery exercise: the data model is whatever the customer built. We work with the customer's IT team to map their data to Horizon's planning model.

Why this matters for legacy ERP customers

Planning improvement doesn't have to wait for ERP modernization. Companies running 25-year-old ERPs can deploy modern planning capability without the multi-year, multi-million-dollar ERP replacement project that would otherwise be a prerequisite. For many manufacturers, this is the practical path to planning improvement — keep the legacy ERP as the system of record and add Horizon as the planning layer on top.

Master data quality is the dominant risk

Legacy ERPs accumulate data quality issues over decades — duplicate items, abandoned product hierarchies, lead times that haven't been updated since the original supplier went out of business in 2008, BOMs that don't match what the shop floor actually does. These issues are usually invisible in the legacy system itself (because nobody runs the queries that would surface them) and become visible during integration.

Plan for 2-6 weeks of data cleanup work during integration. This isn't optional — Horizon's planning math will produce wrong answers from bad data. The cleanup happens with the customer's IT and operations teams; Horizon's implementation team identifies issues but doesn't fix them unilaterally.