When we say we convert legacy applications with more than 90 percent automation, the fair question is: what about the rest, and how much can really be automated in the first place? A number like that is easy to say and hard to trust, so here is what it means in practice.
What automates well
Most of a legacy application is more repetitive than it looks, and repetition is what machines handle well:
- Screen and form structure. The layout of windows, fields, grids, and menus follows consistent patterns. Reading those and generating modern equivalents is reliable, high-volume work.
- Data access. The queries and the code that moves data between the database and the screen are regular enough to translate directly.
- Ordinary business logic. The bulk of the rules in a typical application are plain conditionals and calculations. When they are written in the source, they convert.
- Language and syntax. Translating one language’s syntax into another is exactly the kind of mechanical task automation is good at.
This is why the number is high. In a normal line-of-business application, the parts above are most of the code.
What still needs people
The remaining part is not a rounding error, and pretending it does not exist is how conversion projects lose trust. The manual work concentrates in a few places:
- Architecture decisions. Old applications assume a desktop talking straight to a database. Deciding how that becomes a browser, an API, and a service layer is a judgment call, not a translation.
- Dead ends with no modern equivalent. Some old controls, third-party components, and platform calls have no direct replacement. Someone has to choose the modern substitute and wire it in.
- The genuinely strange code. Every long-lived system has a few areas where the logic is unusual, undocumented, or working around a bug that shipped years ago. These need a person to read, understand, and reproduce carefully.
- Testing and sign-off. Confirming that the new system behaves like the old one is human work, and it is where a lot of the real quality comes from.
Why “mostly automated” is the point
The reason the split matters is risk. A full rewrite treats the whole system as manual: every screen and every rule is rebuilt and re-checked by hand, which is slow, and it is where undocumented behavior gets lost. Automating the large, regular part means the people work goes where it actually helps, which is the architecture, the hard edges, and the testing. You are not paying skilled engineers to retype forms.
So the honest version of the claim is this: the majority of a legacy application can be carried across automatically, and the value is not the percentage itself but where it lets the human effort land. The last stretch is deliberately manual, because that is the part where judgment beats a machine.
If you want a real number for your system rather than a general one, the way to get it is a fixed-scope proof-of-concept on a slice of your actual code. It shows how much converts cleanly and where the manual work sits. Get in touch and we can scope one.