What to Do About Legacy Software Whose Source Code Is Lost: A Guide to Reverse Engineering, Documentation and Modernisation

In brief: Many businesses run on software with lost source code, no documentation and an author or vendor who can't be reached: an old desktop program, an internal system written by one person, a mobile app left unmaintained. These systems stay invisible while they work; but when a security update, a new operating system, an integration or a data migration is needed, they become a risk. AI-assisted reverse-engineering tools like REA can speed up understanding how compiled applications work, but they do not bring back source code and their output should be treated as a partial map. The right path: first settle ownership and licence, then document the system, verify the critical business rules with users, secure the data and then modernise in stages. This article applies only to software you own or are authorised to examine; for legal limits see this article.

Last updated: 23 October 2026

Why is this problem so common?

• The freelancer or company who built the software disappeared, and the contract had no source code delivery (clause 7 of our contract checklist).
• Backups are missing, or the source code stayed on one person's computer.
• The system grew over the years without documentation.
• The infrastructure (server, database, licence keys) is in one person's head.
• The technology aged: a framework out of support, an old operating system, libraries that aren't updated (the riskiest case for security).

This is a sibling of a stalled project rescue: a system that works but nobody knows how.

First: legal and ownership checks

Before any analysis:

1. Who owns the software? Contracts and invoices: did you only buy a right of use, or were the code rights transferred to you?
2. Does the licence prohibit reverse engineering? It may also apply to third-party components (commercial libraries).
3. Can the vendor still be reached? Getting the source code delivered is often cheaper and safer than reverse engineering; try to make contact first.
4. Is there personal data? Be careful about where you send data during analysis (AI use policy).

If in doubt, consult a lawyer.

What does reverse engineering help with here?

Tools like REA (see what is REA?) let AI agents look inside a compiled application, trace relevant code paths and report findings with evidence. According to the official documentation, the targets include native binaries, JavaScript/Electron, .NET, Android apps, websites and firmware. Practical uses for a legacy system:

• Finding where the application talks to the outside: which servers, APIs, files and databases does it connect to?
• Finding where important business rules are calculated (pricing, discounts, tax, reporting logic).
• Understanding data formats: file and database structures.
• Extracting dependencies: which libraries and versions does it run on, and which carry security risk?

Setting the right expectations

• Source code does not come back. The tool shows behaviour and relevant code paths; the original project structure, comments and variable names are not recovered.
• The output may be incomplete. In an independent test, REA gave the correct locations for all 30 communication operations it found in an Electron app; but it did not show some reply-sending places, most of the windows the code creates and some security settings that had been left open. The author's advice: use the output as a partial map and verify the gaps by hand (test summary).
• The type of application matters. Static analysis is easier on JavaScript-based (Electron) and .NET applications; compiled native code needs extra tools (Ghidra, IDA, Hopper) and expertise.
• Business rule ≠ code. Code doesn't tell you why a calculation is done that way; that has to be verified with users and old data.

Step-by-step plan

1. Inventory and risk map

What does the system do, who uses it, what data does it access, where does it run (server, PC, cloud)? Is it critical for security? What would it cost the business if it stopped working?

2. Back up and protect

Take independent copies of the program files, databases, configuration and licence information. Above all, back up without changing anything. (Work on copies; don't touch the production system.)

3. Document the behaviour

Document screens, flows, reports, integrations and user roles together with users. Ask the user “what do you do on this screen, and based on what?”; starting with observation before code analysis often gives the most valuable information.

4. Technical analysis (authorised and controlled)

If needed, use reverse-engineering tools on a copy, in an isolated environment: external connections, data structures, dependencies, critical calculations. Match and verify the outputs: take real inputs and expected results from the system and test whether the findings are right.

5. Secure the data

The real value is often in the data rather than the code. Understanding the data structure and exporting it cleanly is the precondition for modernisation. For the detailed plan, see our data migration guide.

6. Decide: keep, rewrite or replace

7. Set up the new system properly

Prevent this problem from recurring in the new system: source code and accounts in your name, documentation and a test infrastructure, regular backups and a maintenance plan. See our delivery and acceptance testing guide and maintenance and SLA guide.

Red flags

• “Only one person knows this system.”
• The server or operating system is out of support.
• Licence keys or accounts are in personal emails.
• No backups are taken, or restoring has never been tried.
• Critical data is in a single file with no copy.
• A “don't touch it, it works” attitude. (A system that works but that nobody understands is a time bomb that could go off at any moment.)

Modernisation with Aktaş Digital

To understand and document an old system and replace it in stages with a new architecture, we plan the process with authority, data security and business continuity in mind. To get a scope and cost breakdown, you can use our quote form. Related services: web applications, CRM, ERP and inventory tracking systems.

Frequently Asked Questions

Can I have AI rewrite a program that has no source code?

AI tools can speed up analysis, but the output shouldn't be trusted without verification. Source code is not recovered; you need to rewrite while verifying behaviour with users, old data and tests.

The company that built the software won't give me the source code; what should I do?

First review your contract and the invoice/licence terms; the code rights may have been transferred. Assess the legal options with a lawyer. This is the route to try before reverse engineering.

Is reverse engineering legal?

It depends on purpose, authority and licence. Understanding your own software is usually the lowest-risk scenario. For details see our article on legal limits and consult a lawyer.

The system is old but it works; why should I replace it?

Systems that can't receive security updates, can't be maintained and depend on one person can suddenly become a business continuity risk. Replacing may not be mandatory; but backups, isolation and a modernisation plan are the minimum.

How long will it take and how much will it cost?

It varies greatly with the system's size, complexity and documentation status; a single figure would be misleading. Starting with a small discovery and documentation phase makes the scope clear.

Conclusion

Legacy software without source code is an invisible risk “as long as it works.” AI-assisted reverse-engineering tools speed up understanding but do not bring back source code, and their outputs need verification. The right order: ownership and licence, backup, documentation by observation, controlled analysis, securing the data and phased modernisation. The first thing you can do today: list your systems that have no source code and write down, for each, a single backup and the person who knows the system.