Everyone loves to talk about how AI will “save 50% of development time” or “modernise legacy systems in a week”, but when it comes to real, old, and slightly chaotic projects, the picture looks different.
In this interview, Taras Romanyk shares hands-on experience from a team that tried to use Claude, Copilot, and other AI tools to work with a 20-year-old Delphi project featuring a custom database and less-than-perfect architecture. Learn where AI really helped, where it failed, and what lessons are worth learning for future migrations.
Background & experience:
With over 20 years of experience in software engineering and engineering competency development, Taras is responsible for shaping and scaling technical practices, growing engineering talent, and aligning technical standards with business objectives.
What kind of legacy project was being migrated?
Taras Romanyk: The project was around twenty years old and consisted of Delphi code plus a separate C++ project that interacted with it. It used a custom-built database with unique structure. A large portion of the logic was written in a tightly coupled “spaghetti” style. Even a developer who had spent six to eight years on the project estimated they understood only about sixty percent of the code. Some parts could probably be deleted without anyone noticing.
The original business goal was simply “Migrate the legacy system from Delphi to C#/.NET (WinForms).”
However, after analysis, it became clear that a direct rewrite would not remove the core architectural problems. Those issues would simply reappear in C#. The main takeaway was that migrating a project with artificial intelligence to a modern language is not enough; without a detailed architectural review, the issues remain even after the rewrite.
How has AI influenced migration processes?
TR: AI performed well when translating “clean” business logic. If the code were straightforward, and algorithmic, and avoided messy infrastructure, AI could translate from Delphi/C++ to C# with around eighty to ninety per cent correctness. Developers mainly needed to fix syntax, adjust constructs, and handle edge cases.
AI also handled typical UI forms surprisingly well. Many interfaces were migrated to WinForms, and for simple ones, AI preserved the layout, maintained the core logic, and avoided breaking elements. Buttons, basic fields, and menus translated effectively. Simple UI combined with simple patterns tended to produce good results.
Another strong area was code explanation and documentation. AI was helpful for interpreting old, poorly structured code and generating understandable descriptions of classes, methods, and functionality. This was valuable for a system with minimal existing documentation and helped rebuild understanding before migration.
Where did AI fail or perform poorly?
TR: AI struggled significantly with custom-built database engine and unusual infrastructure. Homegrown databases and unique vector mechanisms lacked standard patterns, making them hard for AI to interpret. Even humans struggled with this part of the system. Automatic migration in such cases made little sense; replacing the custom-built database engine with a proper SQL/ORM solution was a far more logical decision.
Another area of failure was complex UIs. With large interfaces full of elements, the output became nondeterministic: the same prompt might produce a version with menus, another without menus, or even new, invented features. This inconsistency made results unreliable.
Chart-drawing logic exposed another limitation. While the migrated visuals looked similar, the mathematical accuracy was not always preserved, as formulas did not always transfer correctly. Pixel-perfect functionality required substantial manual correction and testing.
What AI models were used, and how did they perform?
TR: The primary tools used were Anthropic Claude and GitHub Copilot’s GPT-based models. Claude generally performed better for code translation, producing fewer errors and hallucinations. However, its smaller context window made it difficult to process large files, which had to be split into chunks.
Among GitHub Copilot’s models, GPT-4 performed reasonably. GPT-5 tended to hallucinate more. Overall, Claude offered strong accuracy for code tasks, though context size and cost remained limiting factors.
Was there an attempt to use AI for automated functional testing?
TR: Yes. The team tried generating Gherkin descriptions of the old Delphi app’s UI using AI and then used Playwright to verify whether the new C# UI conformed to those descriptions. This approach worked decently for simple interfaces but produced too many inaccuracies for complex ones. The prototype resembled a multi-agent workflow; however, inconsistencies across complex forms limited its effectiveness.
What about security concerns when feeding code to AI tools?
TR: In a well-structured architecture, secrets should never be stored inside the codebase; they should reside in environment variables or Docker secrets. If a system contains hardcoded keys, that indicates a development hygiene issue rather than an AI-specific cybersecurity problem.
A notable risk arises when someone asks an AI agent to “just make it work” without understanding what “correct” behaviour should look like.
How important is architectural preparation before migration?
TR: Critically important. If the current system is built as spaghetti code, AI will simply recreate spaghetti code in another language. Before migration, it’s essential to review architecture, check for proper layering, separate business logic, apply standard patterns, and refactor the legacy system into a cleaner structure. AI benefits greatly from standardised, well-organised code and struggles with custom or chaotic solutions.
How effective is AI at testing and maintaining quality?
TR: AI-driven testing sounds promising, but in practice, these tools support quality assurance testers rather than replace them. AI might automatically catch ten to fifteen per cent of basic bugs. Human testers — especially those familiar with the business domain — remain indispensable. Relying solely on AI poses unacceptable risk.
Can AI reliably reduce project budgets or timelines?
TR: Realistically, no. No responsible engineering team would promise that a project costing one hundred per cent by hand becomes ninety per cent with AI. While AI accelerates scaffolding, boilerplate, and certain routine tasks, it also increases code comprehension time because developers must verify every generated result. Debugging unclear AI output can further raise costs. AI is an accelerator for development team efficiency — not an automatic thirty-percent discount.
What tools are recommended for practical use?
TR: Cursor is fast and feature-rich, ideal for projects without heavy enterprise constraints. GitHub Copilot with Agent/Chat and other coding agents integrates effectively with the Microsoft ecosystem and is strong in enterprise environments. Claude Code produces excellent output for coding tasks, though it can be expensive for large repositories. Tool selection should be based on actual project needs — security requirements, scale, and budget — not on hype.
What is the final takeaway about AI in legacy migration?
TR: AI does not replace architectural work in software development. If the existing system is chaotic, AI will reproduce that chaos in another language. AI excels at translating clean business logic, handling simple UIs, explaining and documenting code, and doing basic optimisations. It struggles with custom infrastructure, homemade databases, overly complex UIs, and uncontrolled security cases. Human involvement is essential for asking the right questions, validating outputs, and making architectural decisions.
The best approach is to clean up the legacy system first, use AI as an accelerator rather than a magic wand, and ensure the people who understand the old system are the ones who guide the creation of the new one.
Related insights
The breadth of knowledge and understanding that ELEKS has within its walls allows us to leverage that expertise to make superior deliverables for our customers. When you work with ELEKS, you are working with the top 1% of the aptitude and engineering excellence of the whole country.
Right from the start, we really liked ELEKS’ commitment and engagement. They came to us with their best people to try to understand our context, our business idea, and developed the first prototype with us. They were very professional and very customer oriented. I think, without ELEKS it probably would not have been possible to have such a successful product in such a short period of time.
ELEKS has been involved in the development of a number of our consumer-facing websites and mobile applications that allow our customers to easily track their shipments, get the information they need as well as stay in touch with us. We’ve appreciated the level of ELEKS’ expertise, responsiveness and attention to details.
