Legacy app refactoring with AI: software modernisation through reverse engineering
In short
Legacy app refactoring with AI means using coding agents to analyse and document legacy applications and move them step by step to a modern architecture. The biggest lever is not rewriting but recovering knowledge: with reverse engineering – widely popularised since October 2026 by the open-source tool Reverse Engineer Anything (REA) – business rules can be reconstructed even where source code or documentation is missing. Backed by characterisation tests, the result is a new application with demonstrably identical behaviour.
01
Why legacy modernisation adds up differently now
Many mid-sized companies run core processes on applications in Delphi, Visual Basic 6, Access, PowerBuilder, .NET Framework or Java 8 – some for more than 20 years. The people who built them are retiring, documentation is patchy, and operating systems and runtimes are falling out of support.
Until now, modernisation often failed on the effort of understanding: before a single line can be rewritten, it must be clear what the old system actually does. That is exactly the part AI agents speed up most – they read code at scale, explain it and generate tests.
02
What AI agents do well in refactoring – and what they don't
The split of work between agent and team is the most important success factor.
| Task | AI agent | Team stays responsible for |
|---|---|---|
| Reading and explaining code | Very good, even in older languages | Checking business plausibility |
| Documentation and diagrams | Drafts in hours instead of weeks | Sign-off |
| Characterisation tests | Many test cases from observed behaviour | Choosing representative cases |
| Translating to a new language | Good for clearly bounded modules | Architecture and interfaces |
| Business decisions | Unsuitable | Entirely |
03
Reverse Engineer Anything: what's behind the hype
Reverse Engineer Anything (REA) is an open-source project under the MIT licence. Through an MCP server it connects coding agents such as Claude Code or Codex to established reverse engineering tools like Ghidra, IDA and Hopper, plus browser and runtime analysis. An agent can then examine native programs, JavaScript and Electron apps or .NET assemblies without knowing the source code.
The repository was created in April 2026 and within a few weeks in October 2026 became one of the most-watched projects on GitHub, with more than 400,000 stars. Perplexity added REA to its Computer agent as the /reverse-engineer skill. A widely cited example from the project: a sound function from the game DX-Ball was reconstructed so that it passes all 3,205 original test cases.
Important context: REA does not recover the original source code. The output is a reconstruction of the logic with evidence and a list of open questions. For modernisation that is exactly what is valuable – but it does not replace a business review.
400,000+
GitHub stars, end of October 2026
MIT
open-source licence
3,205 / 3,205
test cases passed in the DX-Ball example
04
Reverse engineering your own legacy applications
For companies the value lies less in cloning other people's apps than in recovering knowledge about their own. Typical cases: the source code is lost or differs from the production version; custom software came from a vendor that no longer exists; interfaces exist only as compiled libraries; file formats are documented nowhere.
Three perspectives complement each other: static analysis of code or binaries, dynamic analysis of the running program including database queries and network traffic, and a black-box view of inputs and outputs from real cases. The result is a specification of business rules in which every statement points to evidence.
05
Parallels with replacing SaaS
Legacy refactoring and replacing SaaS tools share the same core: derive a specification from existing behaviour, rebuild with coding agents, prove equivalence with tests. The difference is the source of knowledge.
| Step | Replacing SaaS | Legacy refactoring |
|---|---|---|
| Starting point | Third-party product, only the interface is visible | Your own application, often undocumented |
| Source of knowledge | Observable behaviour and your own usage | Code, binaries, database, runtime behaviour |
| Analysis output | Functional specification | Business rules with evidence and characterisation tests |
| Implementation | New build with coding agents | Step-by-step replacement using the strangler fig pattern |
| Acceptance | Pilot with one team | Parallel run with identical results |
06
Six-step approach
How a legacy application gradually becomes a modern solution without interrupting operations.
- 1Inventory and prioritisation: assess business criticality, technical risk and end of support per application.
- 2Isolate the analysis environment: a copy of the system, pseudonymised data, no production access; language models on-premises or via a European gateway.
- 3Capture behaviour: secure inputs and outputs of real cases as a golden master, plus logs and database snapshots.
- 4Reverse engineering and documentation: the agent reconstructs business rules with evidence; the business team reviews and signs off.
- 5Step-by-step replacement: replace module by module behind a facade; the characterisation tests are the acceptance criterion.
- 6Parallel run and shutdown: compare results, migrate data, decommission the legacy system.
07
Cost example: a warehouse application in Delphi
Assumption: an internal warehouse management application with around 150,000 lines of Delphi code and stored procedures; one of the two developers who know the system will retire soon. We compare a classic rewrite with an AI-assisted one. The figures are assumptions for an order of magnitude, not measurements.
| Phase | Classic (PD) | AI-assisted (PD) | Comment |
|---|---|---|---|
| Analysis and documentation | 60 | 20 | Agent reads code and drafts documentation |
| Characterisation tests | 40 | 20 | Tests generated from real cases, selected by the business |
| New development | 220 | 110 | Coding agents with mandatory review |
| Parallel run and migration | 40 | 35 | Little leverage from AI |
| Total | 360 | 185 | at €1,100/PD: €396,000 vs €203,500 |
08
Legal framework in Germany
For your own software with your own usage rights, reverse engineering is unproblematic. For licensed software, Section 69d(3) of the German Copyright Act allows authorised users to observe, study and test how a program functions. Decompilation is only permitted to a limited extent under Section 69e, for example to achieve interoperability with an independently created program. The German Trade Secrets Act (Section 3 GeschGehG) allows examining lawfully acquired products unless this has been effectively excluded by contract.
Check licence and maintenance contracts before analysing third-party components. This is not legal advice.
09
How MAKONIS helps
MAKONIS assesses your legacy applications in a modernisation assessment, sets up isolated analysis environments with sovereignly operated models and modernises with AI software engineering – context engineering, review gates and tests included.
The target is usually a cloud-native application in your Azure landing zone; on request we plan the cloud/Azure migration at a fixed price. Start with a free 30-minute call with our engineers.
Frequently asked questions
Partly. But a one-to-one translation also carries over old design problems. Better: understand the behaviour and pin it down with tests, then rebuild module by module in a clean architecture.
Keep reading
Guide · 7 min read
Running LLMs on-premises: a guide for companies
Running an LLM locally means executing a language model on your own or dedicated infrastructure so prompts and data never leave the company. It requires a suitable open-weight model, enough GPU memory, inference software, a connection to company knowledge (RAG) and access control with logging.
Read moreGuide · 7 min read
AI GDPR checklist and the EU AI Act for mid-sized companies
For GDPR-compliant AI, companies need a legal basis, transparency towards data subjects, a data processing agreement with the AI provider, control over data location and retention, and a data protection impact assessment where risk is high. The EU AI Act adds risk-based obligations; for most mid-sized use cases AI literacy of staff and transparency duties matter most. This article is not legal advice.
Read moreGuide · 9 min read
Replacing SaaS with AI: when building your own pays off – the Calendly example
Replacing SaaS with AI means swapping a narrowly scoped SaaS tool for your own application, built with AI coding agents and running in your own cloud environment. It pays off mainly with per-user pricing, a limited feature set and high security requirements. In our example of a booking tool like Calendly with 60 hosts and mandatory SSO, building your own costs about half over three years – with 10 users it does not pay off.
Read moreInnovation from Munich.Active worldwide.
Talk to us about your cloud, DevOps and AI initiatives — no obligation, directly with our engineers.