Use case · Legacy ERP

Connect AI agents to your legacy ERP — on-prem, no migration

Your ERP holds a decade of orders, invoices, stock, and customer history — locked behind a firewall on an old SQL Server or Firebird instance. CoreBase connects a Model Context Protocol agent to it so your team can ask questions in plain English. On-prem, read-only by default, no migration. Raw rows stay inside your network.

View CoreMCP on GitHub

The problem

The ERP that runs your business was deployed years ago, often on-premise, often on a database version modern tooling has forgotten — SQL Server 2000/2005/2008, or a Firebird file behind a Delphi front end. Every reporting request becomes a ticket: a developer who still knows the schema writes a query, waits, and hands back a spreadsheet. Meanwhile the new generation of AI agents and assistants can't help, because they physically can't reach the database — it's behind a firewall, on a legacy engine, with no public API. The data is there; the path to it is the bottleneck.

How CoreBase handles it

CoreMCP — a single Go binary you run on a machine that can reach the ERP database — exposes it to CoreBase Cloud (or Claude Desktop, or any MCP client) over Model Context Protocol. Connectivity is outbound only: the agent dials out on 443, so there are no inbound ports to open and nothing to expose. You point it at a database connection in YAML and the agent handles schema discovery, query execution, and version-aware SQL rewrites.

coremcp.yaml

server:
  name: "coremcp-agent"
  transport: "stdio"

sources:
  - name: "erp_prod"
    type: "mssql"
    dsn: "sqlserver://core_ro:***@10.0.0.5:1433?database=ERP&encrypt=disable"
    readonly: true            # SELECT + metadata only — mutations rejected
    no_lock: true             # READ UNCOMMITTED — busy OLTP friendly
    normalize_turkish: true   # for Turkish_CI_AS legacy ERP databases

Reaches behind the firewall
Outbound NAT traversal on 443 means the agent connects to an air-gapped or firewalled ERP without inbound ports. This is the hard part most tools skip — and the reason CoreBase fits legacy on-prem deployments others can't.
Legacy-version aware
CoreMCP probes the server version on connect and adapts: sysobjects/sysforeignkeys on SQL Server 2000, OFFSET FETCH→SELECT TOP rewrites on older builds. The same prompts work on a 2003-era ERP and a current one.
Read-only by default
A T-SQL Aware Lexer/Classifier rejects mutating statements before they reach the database, and readonly: true is the source default. Your ERP data is never at risk of a write.
Turkish collation aware
normalize_turkish: true folds İ/i/I/ı variants so 'müşteri' matches MUSTERI, MÜŞTERİ, musteri — essential for Turkish-language legacy ERPs (Logo, Netsis, Mikro and in-house systems).
Query Memory
CoreBase learns your data model from schema relationships and successful query history — so company-specific concepts like 'active customer' or 'pending order' get more accurate over time. It never touches the raw rows to do it.

What it looks like

In the panel, the embedded chat widget, or via the Developer API — same backend, same data, same access policies.

Example prompt

“Which customers have overdue invoices this month, and how much do they owe in total?”

Generated query

SELECT
  c.name,
  COUNT(i.id)       AS overdue_invoices,
  SUM(i.balance)    AS total_owed
FROM customers c WITH (NOLOCK)
JOIN invoices  i WITH (NOLOCK) ON i.customer_id = c.id
WHERE i.status = 'OPEN'
  AND i.due_date < GETDATE()
GROUP BY c.name
ORDER BY total_owed DESC

Executed on your server, against the live ERP database. Returned as a chart and table inline in the chat — no spreadsheet ticket, no data leaving your network.

Why this approach

vs. a cloud BI / data warehouse

BI platforms need the ERP data replicated out first. CoreBase queries in place — no ETL pipeline to build, no warehouse to fund, no second copy of production to secure and govern.

vs. a generic LLM connector

Off-the-shelf SQL connectors break on legacy ERP versions, miss collation handling, and can't traverse a firewall to an on-prem box. CoreBase ships the agent, the protocol, and the policy layer for exactly this surface.

vs. building it in-house

MCP server, schema introspection, query classification, audit logging, RBAC, NAT traversal — a multi-month build. CoreBase is one binary plus a config file.

Frequently asked

Which ERP databases does CoreBase connect to?

Any ERP backed by Microsoft SQL Server (2000 through current) is supported today, which covers the majority of on-prem and legacy ERP deployments. Firebird — the engine behind many Delphi-era accounting and inventory ERPs — is in active development. PostgreSQL and MySQL are on the roadmap. CoreBase connects to the database directly, so it works regardless of the ERP vendor on top of it.

Do we have to migrate or replicate the ERP database?

No. CoreBase queries the database in place. There is no ETL, no data warehouse, and no copy of your production data sitting somewhere else. The on-prem CoreMCP agent reads directly from the ERP database and returns only the rows a given question needs.

Can the AI modify ERP data?

No. The source is read-only by default — only SELECT and metadata statements execute. A T-SQL Aware Lexer/Classifier rejects mutating statements before they ever reach the database, and you should also use a database login with SELECT-only grants for defense in depth.

Our ERP runs on an old SQL Server with Turkish collation. Does that work?

Yes — this is exactly the legacy surface CoreBase is built for. CoreMCP auto-detects the server version (sysobjects on 2000, OFFSET FETCH→SELECT TOP rewrites on older builds) and normalizes Turkish_CI_AS character variants (İ/i/I/ı) so prompts like 'müşteri bakiyeleri' match column and table names regardless of collation.

Will querying our ERP slow down production?

No. Reads can run under READ UNCOMMITTED isolation (the WITH (NOLOCK) equivalent), so AI and reporting queries take zero shared locks and never contend with transactional ERP workloads. The trade-off is potential dirty reads, which is acceptable for analytical questions.

Can we run this fully air-gapped for a regulated ERP?

Yes. The Enterprise Container runs the entire stack — agent, orchestrator, and model access — inside your perimeter with no outbound network. Raw ERP rows never physically leave your environment, which suits defense, finance, healthcare, and other regulated deployments.

See it against your own ERP

Book a demo and we'll connect CoreBase to a database that looks like yours — legacy SQL Server, Firebird, on-prem or air-gapped.