The legacy code and its old guide come in. Step by step they get their knowledge back — a clean guide, screenshots, tests, a spec, a plan. Then the line builds the backend and the front-end, one phase at a time.
Do you have legacy applications that are hard to maintain and even harder to evolve? No time — or nobody left who knows the code — to migrate them? We rebuild them as Java, Go or Rust services with a React front-end. AI does the heavy lifting at every step, your business keeps running throughout, and nothing reaches production without an engineer signing it off.
Most rewrites fail on the rules nobody wrote down. The first five steps exist to get those rules out of the old system and into documents and tests you own — before a single line of the new code is generated.
Whatever exists — Word files, PDFs, a wiki export, the help file shipped with the app — is gathered, de-duplicated and converted to Markdown. AI handles the conversion and strips the formatting noise; nothing is rewritten yet.
Deliverable ·user-guide.md, versioned in Git
Every screen, dialog and report of the running application is captured and named. The screenshots tie the guide to what users actually see, and later serve as the reference for the new React screens.
Deliverable · a named screenshot library, linked from the guideWith the screenshots side by side, AI flags what the guide describes that the application no longer does — and what the application does that the guide never mentioned. Someone who knows the business validates each correction.
Deliverable · user guide v3, checked against the real applicationAll of the code goes into Git, history included: application sources, stored procedures, batch scripts, report definitions. Anything living outside version control — a shared drive, the database itself — is brought in first. AI then maps modules and dependencies.
Deliverable · complete repositories and a module mapBefore anything moves, AI writes integration tests against the existing application, driven by the corrected guide: inputs, outputs, effects on the database. They pin down what the system does today, including the quirks users rely on. The same suite later runs against the new code — that is how equivalence is proven rather than claimed.
Deliverable · a green test suite describing current behaviourThe target is written down before it is coded: services and boundaries, API contracts, data model, and the right language for each component — Java, Go or Rust according to its constraints, React for the interface. Every decision is reviewed and approved by an engineer.
Deliverable ·SPEC.md — architecture, contracts and decisions
The system is cut into phases that can each go live on their own. For each one: scope, order, the tests that must stay green, how traffic switches over and how to roll back. Old and new run side by side; there is no big-bang date.
Deliverable · a phased plan with switch-over and rollback criteriaEach phase follows the AI SDD loop: spec, AI-generated code and tests, human review, integration. Backend services and React screens come off the same line. A phase is done when the legacy test suite passes on the new code and the traffic has moved — then the next one starts, until the legacy can be switched off.
Deliverable · working backend and front-end, one phase after anotherEverything is in your repositories, in plain formats, readable without any tool of mine.
Markdown, corrected against the application, illustrated with its real screens.
Written on the legacy, run on the new system — and kept for every change after it.
Architecture, contracts and the reasons behind each decision, versioned with the code.
Tell me what it is written in, roughly how big it is, and what worries you most about touching it. The first conversation is about scope, not a sales pitch.