Dynamics GP & NAV · Sage 50 · QuickBooks Desktop · AS/400 — and every system like them
Lumnik reads your existing systems without ever writing to them, brings their data into one place, and gives each team an assistant that answers in plain English — or honestly says it doesn't know.
read-only by construction · runs on your own servers or in the EU cloud · the AI can stay inside your walls too
The problem
Orders, customers, inventory, service calls — it all exists somewhere, inside an aging ERP nobody wants to migrate and nobody is allowed to connect anything to. So two people know how to query it, questions wait until they're back from vacation, and every new report is a billable ticket to the vendor. The data isn't scarce. It's locked up.
Same story with Epicor and JD Edwards, in the folder of 900 CSV exports the last Excel wizard left behind, and one floor up in SAP ECC, Oracle E-Business Suite and Siebel. And the clock is public now: Microsoft has announced the end of support for Dynamics GP — 2029 for the product, 2031 for the last security updates. A migration is a multi-year program. The questions your team has are for this quarter.
How it works
Nobody signs off on an ERP migration. Everybody signs off on a read. That is the whole philosophy: Lumnik comes in read-only, your system of record stays the sole owner of its data, and it will never know we were there.
Declarative connectors built for old iron: the ERP's own SQL database over JDBC, CSV and file drops, REST APIs. No writes, ever — an architecture guarantee, not a promise. Four systems become one place you can actually query.
Each team gets its own assistant, bounded to its own scope. The warehouse checks inventory from a phone; finance can't see what finance shouldn't. Generated SQL runs over a read-only connection, and every answer cites where it came from.
Every ingestion leaves a dated observation behind. After a few weeks your hub knows something the ERP never knew: what hasn't moved — and says so, without anyone having to ask.
Everyone has an AI now. Ours was raised differently: deterministic guards check each answer before it ever reaches you. A confident "there aren't any" that turns out to be wrong is the cardinal sin around here — Lumnik would rather admit it doesn't know. That is what makes an answer usable by someone who has to act on it.
The third thaw
An ERP tells you what is. Never since when. Tonight's export overwrites last night's; the status column reads "open" — it read "open" forty days ago too, but nobody wrote that down. Time is the first thing a legacy system destroys.
Each pass leaves a dated observation. Within weeks your hub knows what no report ever showed you: what stopped moving. A case nobody has touched, an order stuck between two steps, a claim that went quiet on a Friday afternoon. A quote that stopped moving is a decision waiting.
The threshold is declared by you, never guessed: thirty days for an order, forty-eight hours for a claim. Lumnik applies what the business said — and cites the exact observation that fired the alert.
When nothing happens, nothing fires. No system warns you about a non-event. This is the one place where Lumnik doesn't merely show you your data — it finds something in it.
On day one, Lumnik knows nothing about your past — and it says so instead of guessing. This memory starts at the first ingestion and deepens every night: it's the one part of the thaw you can't catch up on later.
The missing socket
Shared calendars, dashboards, metric stores, rule engines — the entire modern stack runs on events. The old system emits none: no webhook, no stream, no socket. Lumnik breathes — reads, compares, timestamps — so every observed change becomes an event your tools consume through ordinary sockets: a webhook into Make, n8n or Power Automate, an export, a SQL query. And every silence too: "unmoved for thirty days" is an alert no event-driven system can send you, precisely because nothing happened.
Every conventional integration asks for an account, a network path, sometimes a write into a fragile ERP — and the admin says no, usually for good reason.
With Lumnik, your modern tools never get access to the old system at all: read-only on one side, standard sockets on the other. Day one's zero-risk posture extends to the whole ecosystem.
Every tool wired straight into the ERP makes that ERP a little harder to remove. The day it is finally replaced, everything downstream is rework.
Your tools plug into Lumnik, not into the ERP. When the old system does go, you swap one connector — and nothing downstream notices. Invest in the modern stack without marrying the legacy one.
A dashboard wants trend lines; the legacy holds only current state, overwritten on every update.
The observation log manufactures the time series the source destroyed — so your BI tools finally chart trends from a system with no memory.
Honesty first: these events beat at the rhythm of ingestion — hours, not milliseconds. Fast enough for a calendar, a dashboard, a business alert; this is not real-time, and Lumnik will never pretend it is. And nothing, ever, writes back to the source.
What we can be held to
None of these are settings. They are properties of how the thing is built — which is why we are comfortable writing them on a marketing page.
Ingestion runs one way. There is no write path back to your ERP — not behind a flag, not for administrators. The SQL an answer generates executes over a separate read-only database connection.
Deterministic guards sit between the model and you: sources cited, scopes enforced, and a plain "I don't know" whenever the ingested data doesn't support an answer. A confidently invented number is worse than no number.
Deploy the whole hub inside your own walls — including the model, running locally — or on European infrastructure. Nothing has to leave your perimeter for Lumnik to work.
One more, for the architects: isolation between organizations is enforced by the database itself, not by application code — the layer that cannot be bypassed by a bug in the layer above.
Go deeper
Connectors, guards, the data model, the one-command self-host — all of it is written down, in English, and open to anyone who wants to verify before believing. No sales call stands between you and the technical truth.
Open-source edition — September 2026
The hub becomes open source in September 2026. There is no link here yet, on purpose: the repository is still private, and a dead link would be worse than a promise. The day it opens, this line becomes the link.
Contact
Name the system that's keeping your data cold, and we'll come back with a concrete thaw scenario — usually one we can demonstrate on a sample of your data rather than ours.
Integrators and consultancies: pick "Integrator / partner" below. The partner program is being built now, and early conversations shape it.