How to document legacy systems with AI: reverse engineering that works for your company

The system nobody can explain

Almost every company with a few years behind it has one: the custom system built fifteen years ago, the macro-filled spreadsheet that closes the month, the Access database that feeds billing, the script that connects the ERP to the online store. It works, but whoever wrote it has left, documentation never existed and nobody wants to touch it.

That system becomes a silent obstacle. It blocks migration to a new platform, prevents automation and concentrates risk: if it breaks, nobody knows how to fix it. The good news is that the same technology that put reverse engineering with AI in the headlines in October 2026 can work in the company's favor here.

Reverse engineering in the company's favor

Reverse engineering means starting from finished software to understand how it works. When the system belongs to the company, there's none of the legal debate that surrounds analyzing third-party programs: the goal is to recover knowledge that was lost.

There are two scenarios. In the most common, the source code exists but nobody understands it: an AI agent reads the whole repository and explains what each part does. In the hardest, only the compiled program is left: tools such as REA coordinate analysis programs, such as Ghidra, to reconstruct the behavior from the file.

What you can extract from a legacy system

Good AI-generated documentation answers six questions:

• ✓System map: which modules exist, what each one does and how they connect.
• ✓Business rules: commission calculations, discounts, deadlines and validations that only exist in the code.
• ✓Data dictionary: what each table and each field in the database means.
• ✓Integration map: which systems it exchanges data with, in what format and how often.
• ✓Dead code: parts that are no longer used and can be left out of a migration.
• ✓Risks: passwords written in the code, unsupported dependencies and points with no error handling.

Step by step

The path that usually works has six steps:

• ✓Inventory: where the code and database are, who uses the system and for what.
• ✓Extract: an agent reads the code and the database structure and produces a first description of modules, rules and flows.
• ✓Translate into business terms: the rules become plain-language text that people outside IT can read.
• ✓Validate with users: key users confirm or correct each rule. It's the step that separates documentation from fiction.
• ✓Capture current behavior in tests: characterization tests record what the system does today, so a migration can prove nothing changed by accident.
• ✓Plan the next step: migrate, integrate with AI agents, automate or retire.

The main precaution: AI is confidently wrong

A language model describes code fluently, and fluency is no guarantee of accuracy. A study published on arXiv in September 2026, "When LLM Decompilers Recompile More and Preserve Less", showed the problem in code reconstruction: with AI refinement, the rate of functions that compile rose from 75% to 90%, but the rate of functions that behave like the original fell from 74% to 62%.

The same happens with documentation: a plausible description can be wrong exactly in the detail that matters, such as a rounding rule or an exception for one type of customer. There are three defenses:

• ✓Evidence: every statement in the documentation points to the file and code snippet that supports it. REA, for example, returns each conclusion with its evidence and limitations.
• ✓Tests: what was documented becomes an executable test against the real system.
• ✓Human validation: the people who use the system day to day confirm the business rules.

Security and confidentiality

The code of an internal system usually contains sensitive information: commercial rules, credentials and, in the database, customer data. Before you start:

• ✓Use AI plans whose terms guarantee that the data sent isn't used to train models, or models running in your own environment.
• ✓Remove passwords and keys from the code before the analysis, and rotate any that were exposed.
• ✓Work with anonymized samples of the database, in compliance with data protection laws such as LGPD and GDPR.
• ✓If a third party runs the analysis, sign a confidentiality agreement.

When it's worth it

Documenting a legacy system with AI usually pays off at these moments:

• ✓Before migrating to a new ERP or platform.
• ✓Before connecting the system to AI agents or automations.
• ✓When the person who knew the system is leaving.
• ✓In audits and compliance work that require knowing what the system does with data.

How SINOON works

In our AI consulting, process mapping includes these systems: the biggest automation opportunity is often trapped inside one of them. Once documented, the system can be integrated with custom AI agents without having to be replaced all at once.