There is a scene in Braveheart that kept coming back to me while I was preparing to modernize VisualNEO Win.

William Wallace stands in front of his soldiers as the enemy cavalry charges towards them. Everything in the scene tells you to act. The horses are getting closer, the ground is shaking and waiting any longer seems increasingly unreasonable.

But Wallace keeps signalling to his men: hold.

Not yet.

Not yet.

Then, at the last possible moment: now.

That is roughly how I felt about migrating VisualNEO Win from Delphi 7 to Delphi 11.

I had known for years that it needed to happen. Delphi 7 had served the product extraordinarily well, but the distance between the development environment and the modern Windows ecosystem was becoming impossible to ignore.

And yet, every time I looked seriously at the migration, the answer was the same.

Not yet.

A migration team of one

VisualNEO Win has a history stretching back to 1993, when it was released as NeoBook for DOS. I wrote about that history in a previous article.

I did not create NeoBook. That was David Riley of NeoSoft. But since taking over its development in 2018, I have inherited something of the same working model: this is primarily a product maintained by one developer.

There was no migration department waiting to take the project on. There was no team of ten Delphi specialists, no large modernization budget and no possibility of stopping normal development for a year while we rebuilt everything from scratch.

In fact, I did not even buy the Delphi 11 licence used for the migration.

I won it in an Embarcadero competition, with invaluable help from the VisualNEO community, whose members supported the project with their votes.

That detail later became strangely appropriate. The community helped provide the tool that made the migration possible, and the same community would eventually help us find the bugs that no automated process could anticipate.

Why not simply leave it alone?

There is always a temptation to leave mature software alone if it still works.

VisualNEO Win was compiling applications, existing users were productive and old projects could still be opened. From the outside, continuing with Delphi 7 might have looked like the conservative and therefore safer decision.

But two limitations had become particularly urgent.

The first was Unicode.

A development tool that cannot comfortably handle modern international text is not merely missing a convenient feature. It is increasingly disconnected from the world in which its users are trying to build software.

The second was WebView2.

Modern Windows applications increasingly combine native interfaces with web content. VisualNEO Win needed a current browser component and a proper bridge between that component and NeoScript. Without it, an entire category of modern application development was becoming unnecessarily difficult.

Those were the most visible pressures, but they were not the only ones. We also needed modern HTTP and JSON support, WebP images, better editors, improved Windows integration and replacements for ageing internal components.

The problem was no longer whether the migration was desirable. The problem was how a single developer could perform it without breaking three decades of accumulated behaviour.

Waiting for the tools to catch up

I had been experimenting with large language models for development long before beginning the migration.

They were useful for isolated functions, explanations and small refactorings, but this was a different kind of problem. Migrating VisualNEO Win required understanding relationships across a large codebase, recognizing obsolete components, tracking compiler differences, preserving undocumented behaviour and making hundreds of changes without losing sight of the whole system.

A model that produced convincing code for ten minutes and then forgot the architectural context was not enough.

So again: not yet.

By the summer of 2026, however, something had changed. The models had become better at working across larger bodies of code, following long plans, investigating errors and maintaining context over an extended engineering task.

For the first time, I felt that an AI system might not merely assist with individual fragments of the migration. It might make the migration itself feasible.

Now.

The migration did not begin with code

The first phase was analysis and preparation.

Before changing anything, we had to understand what we were dealing with: the project structure, third-party components, obsolete units, Windows API calls, string handling, binary formats, plug-in interfaces and areas where apparently harmless changes could affect old projects.

We also had to decide what modernization meant.

The objective was not to produce the cleanest possible new architecture at any cost. It was to move the application forward while preserving the contracts on which users depended: project files, scripts, compiled applications and classic plug-ins.

That distinction shaped almost every decision that followed.

What the AI actually did

The code migration itself was carried out through ChatGPT Sol under my direction.

That sentence sounds much simpler than the process really was.

I supplied the project, the historical context and the constraints. I decided what behaviour had to be preserved, evaluated proposed changes, compiled and ran the application, described failures and chose how far each modernization should go. The model analysed units, rewrote incompatible code, replaced obsolete approaches, followed compiler errors across the project and helped implement the new capabilities.

This was not a single prompt followed by a successful build.

It was a long conversation with a codebase.

Some changes exposed problems elsewhere. Some apparently correct replacements altered behaviour in subtle ways. Some parts of the application carried assumptions that made perfect sense in Delphi 7 but no longer held in Delphi 11. Each solved problem revealed the next layer.

The work occupied more than a month: first analysis and preparation, then implementation, and finally the phase that is easy to underestimate when discussing AI-generated code.

Testing.

Compiling was only the beginning

Eventually, the application compiled.

That was an important moment, but it was not the finish line. For software with decades of compatibility requirements, a successful build proves surprisingly little.

VisualNEO Win contains many features that interact in ways no test plan can completely reproduce. More importantly, its users have projects created over many years, using combinations of commands, objects and third-party plug-ins that I could never reconstruct in advance.

When the new version reached users, the bug reports began.

For several weeks they found problems, and we corrected them one by one. Some were obvious regressions. Others only appeared in a particular project, Windows configuration or sequence of operations. A change could look completely correct in the development environment and still conflict with an application somebody had maintained for fifteen years.

This part of the story matters because it is where the usual narrative about AI development breaks down.

The AI made the migration possible, but it did not make validation optional.

The model could transform code at a scale that would have been extremely difficult for me to tackle alone. But product knowledge, judgement, real-world testing and the experience of the user community were still essential.

At the time of writing, bug reports have slowed to almost nothing. A small number of known issues remain scheduled for the next version, but the migrated application has settled into normal daily use.

That quiet is one of the most satisfying results of the entire project.

What we gained

The most immediate result was much broader Unicode support.

VisualNEO Win can now work far more naturally with international text throughout the development environment and the applications it produces.

WebView2 integration was another major step. Applications can incorporate a modern browser engine and communicate with it through NeoScript, allowing native VisualNEO projects to make practical use of modern web interfaces and content.

The migration also enabled modern HTTP and JSON capabilities, WebP support, improved editors, better Windows integration and numerous internal changes that are less visible but necessary for future development.

However, one of the most important advances was not simply a replacement for something old.

It was the new plug-in architecture.

A new plug-in system without destroying the old one

The classic VisualNEO and NeoBook plug-in system has accumulated decades of useful extensions. Those plug-ins add databases, communications, multimedia, reporting, hardware control and many other capabilities.

They also explain one decision that can appear strange in 2026: VisualNEO Win remains a Win32 application.

Compiling the main application for 64-bit Windows is not the central difficulty. The problem is that a 64-bit process cannot directly load the large collection of existing 32-bit plug-ins. Some of them are closed-source, and some were created by developers who are no longer active.

A switch to 64-bit made purely for the sake of appearing modern would remove something of genuine value from the product.

So we created a new plug-in architecture without removing the classic one.

The modern system can add visual controls, actions, properties and events directly to the development environment. It provides a foundation for extending VisualNEO Win in ways that the original plug-in model was never designed to support.

At the same time, existing .nbp plug-ins continue to work.

That is not the cleanest possible architecture. It is, however, the architecture that respects both the future and the past.

Old is not the same as deprecated

Before this work, it was easy for somebody encountering VisualNEO Win for the first time to see only its history.

A development environment descended from software released in 1993, still compiled as Win32 and still supporting plug-ins created many years ago certainly sounds like a legacy product.

But legacy and obsolete are not synonyms.

VisualNEO Win is not simply an old program that we have managed to keep running. It is once again an actively modernized Windows development environment, capable of building contemporary applications while retaining a workflow that remains unusually approachable.

It belongs in the same conversation as automation and rapid-development tools such as AutoIt, but approaches the problem differently. VisualNEO Win provides a visual interface designer, an accessible scripting language and a direct path from arranging objects on a page to compiling a standalone Windows application.

That combination matters for people who know exactly what software they need but do not want to construct an entire conventional development stack before they can create it.

It also has an increasingly important advantage: its visual model, action-based structure and relatively compact language are well suited to AI-assisted development.

The environment can export its command documentation for use by AI systems. An assistant can understand the available actions, generate NeoScript and help construct application logic without first navigating a large collection of frameworks and dependencies.

In other words, a development model designed to make programming accessible to humans may also turn out to be unusually accessible to machines.

What I learned

The obvious lesson is that AI can give a solo developer capabilities that previously would have required a team.

That does not mean the developer disappears.

The model did not inherit responsibility for the product. It did not know which historical behaviours users depended on unless I explained them. It could not decide what compatibility was worth preserving or judge the cost of breaking a plug-in whose original developer disappeared ten years ago.

AI supplied an extraordinary amount of analysis and implementation capacity. My role shifted towards providing context, defining constraints, evaluating decisions, testing outcomes and accepting responsibility for the result.

The community completed the process. First, its votes helped me obtain the Delphi 11 licence. Later, its projects and bug reports provided the real-world test suite that no single developer could create.

So the migration was not performed by AI alone, and it was not performed by me alone.

It was performed by an unusual team: one developer, one increasingly capable AI and a community with more than thirty years of accumulated experience.

The right moment

Could this migration have been attempted earlier?

Probably.

Could I have completed it alone, manually, with enough time?

Perhaps.

But for a small independent product, technical possibility is not the only consideration. Time, risk and resources determine whether a project is realistic at all.

In the summer of 2026, the equation finally changed.

The Delphi 11 licence was available. The community was behind the product. The need had become urgent. And, for the first time, the AI tools were capable enough to help carry the weight of the migration without losing sight of the larger objective.

After years of looking at the problem and thinking not yet, the moment had arrived.

Now.

The migration did not erase thirty years of history.

It gave that history somewhere new to go.

---

I would be interested to hear from other developers who have used AI to modernize a large legacy application. What could the model handle reliably? Where did human knowledge become essential? And how much work remained after the first successful build?