Reverse engineering and refactoring legacy systems from source code
Our old system works, but nobody fully understands it
ITLine maps existing business systems from their source code and the running system, with AI: what it does, under which rules, on which screen, with which data. Every finding points to its place in the code, and uncertain ones are marked. Fixes, refactoring or a rewrite build only on that map.
Where you start
The system has run for many years, and it works. Whoever wrote it has left, and the documentation is old or missing. Every fix is a risk, because nobody knows for sure what depends on what they touch. And the rewrite never starts, because nobody can say exactly what should be rewritten.
How we work
Handover. Source code, database schema, the existing documentation and, if there is one, a test environment. We do not touch production.
Inventory. How many modules, screens, tables and stored procedures there are, in which language and version. We read the version from a machine fingerprint.
Structure extraction. Classes, routines, dependencies, and from the screen definitions which button calls which code. That wiring is not visible in the source files.
Running and observing. We run the system in a separate environment and record, per screen action, what changes in the database.
Verification. Every finding gets a code reference and a confidence mark. What two independent sources (code, screen, data, log) do not confirm stays an open question.
Weekly handover. In the first week one chosen function group is done in full depth. That is the sample on which you decide whether the direction and the depth are right.
Fixing only after that. Refactoring, bug fixes or a rewrite build on the map we have checked together by then.
What we hand over is yours: specifications, a rule list, a data map and test scenarios, in searchable form.
What we measured in advance
Before taking on work like this, we measured how well AI can map old Delphi code. On 23 September 2026, on two open-source Delphi code bases (one from the 2000s and one current, 15,522 lines in total), the machine check counted 1,160 symbols. The model missed none and invented none. On the same code, our own checking script turned out to have five bugs.
We wrote our own decoder for the screen definitions. It processed all 1,342 screen definitions of the old library without a crash, and agreed with an independent check on 1,255 of 1,331 files (94%). The remaining 6% is still open, and we say so.
What the code does not tell you
The code shows what is in it. It does not show what it was meant for, or how people use it today. So reverse engineering also needs real data, logs and correspondence, and time from the colleagues who use the system every day.
The measurement does not cover SQL assembled at run time, stored procedures in the database, dead code (only a runtime log separates it from live code), or third-party components without source. We measure those on your system, after the inventory.
What is not included
A fixed price before the inventory. How much work each part of a system developed over many years is comes out of the inventory, and we give no number before it.
Changes to production without your written approval and a backup.
A completeness guarantee. What cannot be traced to the code is listed as an open question, not as a claim.
Common questions
Have you done this before?
We have not yet delivered a reverse engineering project to a client. That is why we measured the method on open-source code in advance, and why we start with one chosen function group: the first week shows whether the direction and the depth are right.
Which languages can you work with?
We measured on Delphi, because it is common among old business systems and modernisation tools rarely cover it. The method carries over to other languages; C# and Java are easier ground for the models. For another language we measure that first, after the inventory.
Do we have to rewrite everything afterwards?
Not necessarily. With the map you can decide: fixes, replacing it part by part, or a rewrite. What works well stays.
What do we need to provide?
The source code, the database schema, the existing documentation, a test environment if possible, and an hour a week from someone who uses the system.