Introduction
Legacy .NET systems are not going anywhere.
Despite years of evolution in the Microsoft ecosystem, many organisations still rely heavily on applications built with VB6, VB.NET, WinForms and early versions of ASP.NET. These systems often sit at the heart of critical business processes. They generate revenue, support operations, and, in many cases, have been running reliably for over a decade.
The problem is not that they exist. The problem is that they are increasingly difficult to evolve.
Modern expectations demand scalable APIs, cloud-native deployments, strong security boundaries and rapid iteration. Legacy systems, by contrast, tend to be tightly coupled, poorly documented and fragile under change. Even small modifications can introduce risk and over time, teams become hesitant to touch them at all.
For years, the industry has debated whether to rewrite or refactor these systems. In reality, neither approach on its own is sufficient. Rewrites are high risk and often fail to deliver, while refactoring without a clear strategy can lead to slow and unfocused progress.
What has changed recently is the introduction of AI-assisted development. Not as a replacement for engineers, but as a practical tool to help navigate complexity. Used correctly, AI can reduce the uncertainty that makes legacy modernisation so difficult. It can accelerate understanding, support refactoring and help build confidence in changes that would otherwise feel risky.
This article is a practical playbook for modernising VB.NET systems into modern .NET architectures, with a grounded and realistic use of AI along the way.
The Reality of Legacy Systems
Anyone who has worked with legacy .NET applications will recognise a familiar set of characteristics. Business logic is often intertwined with the user interface, database access is scattered throughout the codebase and shared global state is used in place of clear boundaries. Over time, fixes and enhancements are layered on top of each other, creating a system that works but is difficult to reason about.
Documentation, if it exists at all, is usually outdated. Knowledge is often held by a small number of individuals and when they leave, understanding of the system leaves with them. What remains is a codebase that is both critical and opaque.
This is where most migration efforts struggle. The challenge is not simply rewriting code in a newer language. The real challenge is understanding what the system actually does before attempting to change it.
Without that understanding, every modification becomes a risk.
Moving Beyond the Rewrite vs Refactor Debate
The idea of a complete rewrite is appealing. Starting fresh with modern technologies, clean architecture and well-defined boundaries sounds like the ideal solution. In practice, however, large rewrites are rarely successful. They take longer than expected, struggle to replicate complex business rules and often lose stakeholder confidence before completion.
At the other end of the spectrum, incremental refactoring can feel safer but lacks direction if not guided by a clear strategy. Changes are made in isolation, progress is slow and the overall system remains largely unchanged.
A more effective approach is to combine incremental change with architectural intent. This is often described using the strangler pattern, where new functionality is built alongside the existing system and gradually replaces it over time. Rather than attempting to modernise everything at once, the system evolves in controlled steps.
In reality, most organisations operate in a hybrid state for an extended period. Legacy VB.NET components coexist with newer C# services, shared databases remain in place and APIs are introduced gradually. While this may not be architecturally perfect, it is practical and allows progress without unnecessary disruption.
Where AI Fits in Practice
AI has introduced a new capability into this process, but its value is often misunderstood. It does not remove the need for design decisions and it does not replace engineering experience. What it does provide is a way to reduce the time and effort required to understand and work with complex legacy systems.
One of the most immediate benefits is in code comprehension. Legacy code that would normally take hours to analyse can be explained quickly, with key behaviours and dependencies highlighted. This is particularly useful in systems where documentation is missing or incomplete. Instead of manually tracing through multiple layers of code, you can build a mental model much faster.
AI also proves useful during refactoring. Converting VB.NET to C# is a good example. While the conversion itself is relatively straightforward, ensuring that the resulting code follows modern patterns is more challenging. AI can suggest improvements, highlight opportunities to introduce dependency injection and simplify overly complex methods. These suggestions are not always perfect, but they provide a strong starting point.
Testing is another area where AI adds significant value. Many legacy systems lack meaningful test coverage, which makes change inherently risky. AI can generate test scaffolding and suggest edge cases, allowing teams to build a safety net before making modifications. This alone can transform the confidence with which a system can be evolved.
There is also a role for AI in shaping modernisation efforts. When introducing APIs around legacy functionality, AI can assist in defining contracts and mapping inputs and outputs. It can help structure controllers, suggest data models and accelerate the creation of service layers that decouple the old system from new consumers.
Perhaps one of the more interesting applications is in error handling and diagnostics. Instead of presenting generic errors, AI can be used to interpret logs and suggest likely causes or remediation steps. This has the potential to improve both developer experience and operational support.
A Practical Migration Workflow
Turning these ideas into action requires a structured approach. Attempting to modernise an entire system at once is rarely effective, so the process should begin by identifying a suitable candidate for migration. Ideally, this is a component that is relatively self-contained, delivers clear value and is actively used or modified.
Once identified, the first step is to build understanding. This is where AI can be used to analyse the existing code, generate summaries and highlight dependencies. The goal is to create a clear picture of how the component behaves and how it interacts with the rest of the system.
Before making any changes, it is important to introduce tests. Even partial coverage can significantly reduce risk. By validating current behaviour, you create a baseline that allows you to detect unintended changes during refactoring.
With that safety net in place, the component can be modernised. This may involve rewriting it in C#, introducing clearer separation of concerns and removing reliance on shared global state. AI can assist during this phase, but the overall design should be driven by architectural intent rather than generated output.
Once the logic has been modernised, it should be exposed through an API. This creates a clear boundary and allows other parts of the system to interact with it in a consistent way. It also enables future scalability and integration with newer platforms.
At this stage, the new component should be deployed alongside the legacy system rather than replacing it immediately. Running both versions in parallel allows for comparison and validation. Traffic can then be gradually shifted to the new implementation, reducing risk and allowing issues to be identified early.
Over time, as more components are migrated using this approach, the legacy system naturally shrinks. What remains can then be addressed with greater confidence and less complexity.
The Challenges That Still Exist
While AI introduces clear benefits, it does not eliminate the challenges associated with legacy systems. One of the most important limitations to understand is that AI can be wrong. It may misinterpret business logic, overlook edge cases, or suggest changes that are not appropriate for a given context. Every output must be validated and critical thinking remains essential.
Legacy systems also tend to have hidden dependencies that are not immediately obvious. Shared state, side effects and implicit behaviours can lead to unexpected issues when changes are introduced. These are not always detectable through automated analysis and require careful investigation.
Performance is another consideration. Modernising code does not automatically improve efficiency. In some cases, introducing abstraction or additional layers can have a negative impact if not implemented carefully. Profiling and monitoring should remain part of the process.
There is also a risk of over-reliance on AI. If teams begin to accept generated output without proper review, they may introduce new problems into the system. AI should be treated as an assistant, not an authority.
Evolving the Architecture
As components are modernised, the architecture of the system begins to change. What was once a monolithic application with tightly coupled layers gradually becomes a collection of services with clear boundaries. APIs replace direct database access and responsibilities are more clearly defined.
This evolution also creates opportunities to introduce more advanced patterns. Multi-tenant design, event-driven communication and improved observability become more achievable as the system becomes more modular. Rather than attempting to impose these patterns on a legacy system all at once, they emerge naturally as part of the migration process.
Knowing When Not to Use AI
Despite its usefulness, there are situations where AI should be used with caution. Critical financial logic, complex regulatory rules and performance-sensitive components all require a high degree of accuracy and control. In these areas, AI can assist with understanding, but final decisions should remain firmly in the hands of experienced engineers.
Final Thoughts
Modernising legacy .NET systems has always been a complex and often uncomfortable process. The introduction of AI does not change that fundamental reality, but it does shift the balance.
Where teams previously struggled with understanding and uncertainty, they now have tools that can accelerate insight and reduce risk. Where refactoring once felt daunting, it can now be approached with greater confidence.
The key is not to chase hype or rely blindly on new tools. Success comes from combining experience, architectural thinking and the practical use of AI to support, not replace, engineering judgement.
The organisations that modernise successfully will not be those that attempt to rewrite everything overnight. They will be the ones that move deliberately, validate continuously and use every available tool to make better decisions along the way.
AI is simply one of those tools.
Used well, it has the potential to significantly amplify the effectiveness of the teams already doing this work.
Leave a comment