I Can Probably Recreate Your 25-Year-Old Legacy System in 20 Minutes

I Can Probably Recreate Your 25-Year-Old Legacy System in 20 Minutes

Yes, that headline is bait. It is also, probably, true — and the word "probably" is doing real work, so the rest of this article is spent defending it honestly.

Here is the anchor. The ERP in the screenshots below — orders with a proper lifecycle, ledgered stock movements, reorder alerting, customers, suppliers, a role-secured API behind a JWT login — came out of a single Claude conversation over Magic's MCP server. I budgeted twenty minutes for it.

It took ten.

What your legacy system actually is

Before you object, look closely at what your 25-year-old system is made of.

The software rotted. The Delphi client nobody can compile anymore, the VB6 forms, the WinForms app pinned to a runtime three EOLs deep — that layer is dead weight, and everyone in the building knows it. But the schema did not rot. The schema got better every year: every column rename, every foreign key, every constraint added after an incident is a business rule that survived contact with reality. Twenty-five years of institutional knowledge, encoded in the one artifact that outlives every rewrite.

Legacy means load-bearing, not obsolete — I made that argument at length in Turn Your Legacy SQL Server Database into a Modern Full Stack App in Minutes. This article is that argument taken one step further: the part of your system worth keeping is the part the machinery reads automatically, and the part worth throwing away is the part it regenerates in minutes.

The demo: a working ERP in ten minutes

One conversation produced the application below. JWT authentication against the platform's built-in auth, generated CRUD endpoints gated on roles before any logic runs, and a dashboard that answers "how is the business doing" in one glance — paid revenue, open orders, stock below reorder level, top products by units sold.

The ERP dashboard — paid revenue, open orders, below-reorder alerting, orders by status and top products by units sold

The part that makes it not a toy

CRUD demos are cheap, and sceptics rightly ignore them. What separates an ERP from a table editor is invariants — the rules that hold when someone does something inconvenient. So that is where this build spent its ten minutes.

Orders move through a lifecycle: draft → confirmed → shipped → paid. Cancelling an order restores its stock. Not as a comment in a wiki — as behaviour, visible in the second row of this table:

The Orders screen — lifecycle draft to confirmed to shipped to paid, with a cancelled order whose stock was restored

And stock never changes by assignment. It changes only through orders, restocks and adjustments, and every movement lands in a ledger with a reason attached: -10 sale · order:1, +4 cancellation · order:2, +50 restock · PO-1001, -2 adjustment · damaged units. If you have ever audited an inventory discrepancy at quarter-end, you know this ledger is the difference between a system of record and a spreadsheet with opinions.

The Products screen with the stock ledger — every movement recorded with a signed quantity and a reason

That cancellation row is my favourite thing in all three screenshots. Order #2 was cancelled, and four bearings walked back into stock, ledgered, automatically. That is a business rule most rewrites get wrong on the first attempt — and it was described in plain English and generated, not implemented.

How the ten minutes were spent

The recipe is the same one from the SQL Server article, and it has four moves.

Define the schema — or in your case, don't, because your DBA finished that job years ago. Magic connects to Microsoft SQL Server, MySQL and PostgreSQL through standard providers; nothing is installed inside the database, and you can connect through a scoped, read-only user on day one.

Wrap the tables. The CRUD generator reads metadata — tables, columns, types, keys — and emits the entire secured API surface: read, create, update, delete, count, with role-based access control enforced before any endpoint logic runs. This is the part that takes seconds, and it is the part vendors quote in years.

Describe what CRUD cannot do. "Cancelling an order restores its stock and records the movement in the ledger" is one English sentence. The Hyperlambda Generator turns sentences like it into working, role-gated endpoints. The business rules that make an ERP an ERP are exactly the kind of rules that fit in sentences.

Serve the frontend from the same system that serves the API. One host, no CORS, no separate deployment — the screens above went live the moment they were written.

And because the whole thing was built through MCP, the same connection works the other way: the finished system is an AI agent surface. Every endpoint the build produced is a tool an agent can discover and invoke, inside the same role boundaries. Your rebuilt ERP and your company's AI agent are the same artifact — that walkthrough is in Create an AI Agent From Your SQL Server or MySQL Database, Step by Step.

Defending "probably"

Now the fine print, because the hedge in the headline is load-bearing too.

Twenty minutes recreates the structure of your system: the schema wrap, the secured API, the lifecycle rules you can state in sentences, the screens. It does not recreate the four hundred reports accounting depends on, the edge-case behaviours nobody documented because Karl handles those, the integration that talks to a label printer over a protocol from 1998, or your data migration. Those take real work — days and weeks, not minutes.

But notice what kind of work they are. They were never rebuild problems; they are discovery problems. Nobody knows the full behaviour of a 25-year-old system — the rewrite was always going to be archaeology, whether it took two years or an afternoon per artifact. What changed is the cost of each shovel: every behaviour you unearth is one English sentence and a regeneration away from being real again, instead of a sprint.

And the demo above ran on a fresh schema, because demos need reproducibility. Your schema is bigger — and better. It has real constraints, real history, real foreign keys that encode how your business actually works. The machinery only ever sees metadata, and your ERP's metadata is richer than anything I can invent for a screenshot.

The question worth asking

For twenty-five years, "replace the legacy system" has been the project that eats budgets and careers, which is why it never happens and the VB6 app outlives its third maintainer. If the structural rebuild costs twenty minutes, the calculus inverts: you no longer need permission, a committee and a seven-figure line item to find out what a modern replacement would look like. You need an afternoon, a scoped read-only database user, and the willingness to be surprised.

I can probably recreate your 25-year-old legacy system in twenty minutes. The parts I can't are the parts you can't either — until you start digging. The difference is that now the shovel is free.

Magic is MIT-licensed and open source at github.com/polterguy/magic, with documentation at docs.ainiro.io.