HyperlambdaStep 1
Connect the database you have
Point a Magic cloudlet at the SQL Server, MySQL, or PostgreSQL database under your legacy system. The schema is read as-is — decades of accumulated structure included.
For systems older than the people maintaining them
Legacy Modernization Without the Two-Year Rewrite
Your 25-year-old system is not the problem — the assumption that replacing it takes years and millions is. Magic Cloud wraps the databases you already run — SQL Server, MySQL, PostgreSQL — with generated APIs, modern auth, and new frontends, while AI agents do the generation under runtime-enforced permissions. The data stays where it is. The rewrite becomes a wrap.
46,000 lines of Angular replaced in a weekend — documented, timestamped
Your schema wraps in place — no migration, no parallel platform
Every generated endpoint gated by roles the runtime enforces
The approach
Wrap, don’t rewrite
Step 2
Generate the modern layer
Secured CRUD endpoints per table, custom business logic described in plain language, OpenAPI specs, JWT auth with OIDC and roles — generated, not hand-built.
Step 3
Ship new frontends beside the old
SPAs served from the same cloudlet consume the generated APIs. The legacy application keeps running until nothing depends on it — retirement by attrition, not by cutover weekend.
The part that changed in 2026: the generation is done by AI agents — and on Magic they do it inside runtime-enforced permission boundaries, which is what makes letting an agent loose on a production-adjacent schema defensible in front of your security team.
Where step one happens
SQL Studio: your legacy schema, first-class
SQL Studio is where a modernization starts — connect the SQL Server, MySQL, or PostgreSQL database under your legacy system and browse decades of accumulated schema like it was designed yesterday. Query with autocomplete, inspect relationships, and let the agent write the SQL you describe in plain language.
From here, generation takes over: the same schema SQL Studio displays is what the platform crudifies into secured endpoints — which is why there is no import step, no schema translation, and no migration. The database you see is the database that gets wrapped.
Where step two happens
The Generator: point and click, get an API
This is the step that replaces months of backend work. Pick the database SQL Studio just connected, tick the tables you want exposed, choose which roles may read, create, update, and delete — and click. The Generator emits one secured REST endpoint per table and verb: paging, filtering, and sorting included, JWT-authenticated, role-gated, documented with an OpenAPI spec.
The output is not scaffolding to finish later — it is readable Hyperlambda you can open, extend with custom business logic, and hand to an AI agent as MCP tools. Your twenty-year-old schema becomes a modern, documented, secured API in the time it takes to read this section.
Where the last 20% happens
The Hyperlambda Generator: natural language in, API out
Point-and-click CRUD covers most of a legacy system — but every old system has the other endpoints: the discount rule nobody dares touch, the nightly reconciliation, the report only one department understands. Those you do not port line by line. You describe them in plain English, and the Hyperlambda Generator compiles the description into a working endpoint — saved as a readable file, secured by the same role gates, live in production without a compile step or a deploy cycle.
The reason this is safe enough for a production-adjacent schema: the Generator does not emit free-form code. It emits Hyperlambda — an AST with a closed vocabulary where every node must bind to a whitelisted capability. A hallucinated invocation does not become a bug in your modernization; it fails, structurally, before it executes.
Proof, in writing
Read the receipts
The rewrite
46,000 lines of Angular, gone in a weekend
The Magic dashboard itself, rebuilt — the case study in what agent-driven replacement actually costs.
The claim
I can probably recreate your 25-year-old legacy system in 20 minutes
Why decades-old line-of-business systems are mostly CRUD over a schema — and what that means now.
The walkthrough
Turn your legacy SQL Server database into a modern full-stack app
Step by step: from an old SQL Server schema to generated APIs and a working frontend.
Frequently asked questions
Do we have to migrate our data to modernize?
No — that is the point of the approach. Magic connects to your existing SQL Server, MySQL, or PostgreSQL database and generates the modern layer on top of the schema in place. Nothing moves unless you later decide it should.
What about the business logic buried in the old application?
Generated CRUD covers the majority of a typical line-of-business system; the rest is described in plain language and generated as custom endpoints, or injected directly into the generated code — which is readable, editable Hyperlambda, not a black box.
Is it safe to let an AI agent generate against our production schema?
On Magic, generation runs inside runtime-enforced permission boundaries: generated code can only bind to whitelisted capabilities, and endpoints are gated by roles. The agent cannot generate its way past its permissions — a bad generation fails before it executes.
Can the old system keep running during the transition?
Yes, and it should. New frontends and APIs run beside the legacy application against the same database, so retirement happens by attrition — screen by screen — rather than a big-bang cutover.
Try it
Five minutes to a running cloudlet
The whole platform — database, generated APIs, auth, frontend hosting, and the MCP server — on your own hardware, MIT-licensed.
# When it’s up: log in at http://localhost:5555 with root/root.
$ curl -fsSL https://hyperlambda.dev/docker-compose.yaml | docker compose -f - up