VB6 to .NET Migration: A Manufacturer's Guide to Modernizing Legacy Shop Floor Software
- 2 days ago
- 9 min read
Updated: 13 hours ago
The scheduling tool, the inventory tracker, the app that moves parts down your line. If it was written in Visual Basic 6, the ground underneath it is shifting. Here is what the move to modern .NET really takes, what it costs, and how to do it without stopping the line.
TL;DR
VB6 is unsupported, its ecosystem is decaying, and the developers who can maintain it are retiring, so the cost of waiting is starting to outrun the cost of acting. Discovery comes before code: mapping dependencies and extracting business rules is what prevents these projects from failing. You have three paths, replatform, automated conversion, or full rewrite, and the right one depends on your codebase, not a template answer. Timelines run from a couple of months for a single tool to several quarters for a business-critical platform. The lowest-risk first step is an operational discovery conversation, not a commitment to rebuild.
Introduction
There is a good chance your plant still runs on something written in Visual Basic 6. It works, mostly. But the person who built it left years ago, the source code lives on one machine in the corner, and every Windows update makes IT hold its breath.
You are not behind for still running it. VB6 software has kept manufacturers productive for two decades, and a tool that does its job is not automatically a problem. What has changed is the ground underneath the tool. The operating system, the talent market, and the security expectations around it have all moved, and the cost of waiting has started to outrun the cost of acting.
This guide walks through the whole decision on one page: why VB6 to .NET migration has become urgent, what the work actually involves on a manufacturing system, the three paths you can take and how to choose, honest cost and timeline ranges, the failure modes that sink these projects, and a real before-and-after from the plant floor. By the end you will know enough to decide what your next move should be.
01 / The case for acting
Why VB6 modernization is urgent now
For years the safe move was to leave a working VB6 application alone. The risk of touching it felt larger than the risk of running it. That calculus has quietly flipped, and four forces are behind the change.
The Windows lifecycle is the forcing function
The biggest pressure is the operating system underneath your tools. As older Windows versions reach end of life, they stop receiving security updates. A frozen VB6 application running on an unsupported OS is exactly the kind of exposure that surfaces in a customer audit, an ISO review, or a cyber insurance renewal. For manufacturers who supply automotive, aerospace, defense, or medical customers, that exposure is not theoretical. It shows up as a line item on a supplier scorecard.
VB6 itself is frozen, and the ecosystem around it is decaying
The VB6 development environment has been unsupported by Microsoft for well over a decade. The runtime still executes on current Windows, which fools a lot of teams into thinking they are safe. But the ecosystem around the runtime is what fails first: the third-party ActiveX controls, the OCX components, the drivers, and the database connectors your application depends on receive no updates and no support. The application keeps running right up until one dependency breaks against a new Windows patch, and then it does not, usually at the worst possible time.
The talent pool is shrinking and getting expensive
This force is quieter but more dangerous. The developers who can confidently maintain VB6 are retiring, and the pool gets smaller every year. Their rates reflect the scarcity. More importantly, every year of delay means more of the business logic that lives only inside that codebase, and inside the heads of the people who wrote it, walks out the door for good. You are not just maintaining software. You are racing the retirement of the only people who understand it.
The cost of doing nothing compounds
None of these forces triggers a single deadline. They compound. Each year the maintenance gets pricier, the talent gets scarcer, the security gap widens, and more undocumented knowledge is lost. The window where doing nothing is the cheapest option is closing, and planning now beats scrambling after a failure.
The economics of delay: the risk of running an aging VB6 system rises sharply, while the cost of a planned modernization rises only gradually as the codebase grows and knowledge is lost. The shaded area marks where waiting has become more expensive than acting.
02 / Under the hood
What a VB6 to .NET migration actually involves
The word migration makes it sound like moving files from one folder to another. It is closer to renovating a building while people keep working inside it. To plan it well, you have to understand why VB6 is uniquely hard to move and why the first real step is not writing code.
The hard part is not the language. It is everything tangled around it
VB6 applications lean heavily on COM and ActiveX components, and over two decades of features and hotfixes, the business logic tends to scatter into places it should never live. The most notorious is the user interface itself. In a typical VB6 desktop application, a large share of the rules that actually govern how the system behaves are buried inside button-click handlers and form events, not in any clean, separate layer. On top of that, most VB6 systems were never fully documented, and a meaningful number have lost their original source code entirely.
The first step is discovery, not development
This is the single most important thing to understand about VB6 modernization, and the place most failed projects went wrong. Before anything gets rebuilt, the dependencies have to be mapped and the business rules have to be extracted and written down, because the running application is often the only specification that exists. Teams that skip this and start translating code immediately discover the missing rules the hard way: as production failures, months later, when a customer's order calculates wrong or a part gets routed to the wrong cell.
Disciplined discovery is not overhead. It is the thing that turns the legacy system's own behavior into a written specification you can build against and test against.
A proper discovery phase produces a dependency map, a catalog of business rules with each rule turned into a test case, a risk assessment, and a recommended modernization path with effort and timeline ranges. Only then does writing code make sense.
A phased modernization sequence. Comprehension comes before code, and validation against the original behavior closes every phase.
The target stack for most VB6 applications today
Once the system is understood, the modern target is almost always .NET using C#. Where remote access or multiple sites would help your operation, the old desktop window is often replaced with a web-based interface, backed by SQL Server or PostgreSQL. Because the VB6 tool is rarely an island, the rebuild has to account for how it connects to your ERP, your label printers, your scanners, and the rest of the shop floor from day one.
03 / Choosing a path
Rewrite, replatform, or automated conversion
There is no single correct path. The right one depends on how tangled your code is and how much the underlying process needs to change. Most engagements land on one of three approaches, and some combine them.
Replatforming is the lift-and-improve move. You get off aging infrastructure and reduce the immediate risk without touching the core logic. It is fast, but it does not fix bad code. It buys time, which is sometimes exactly what you need before a larger effort.
Automated, AI-assisted conversion has matured considerably. Modern tooling can translate a large share of a codebase and generate documentation and tests far faster than a manual rewrite. The catch is that it is not a hands-off button. The tools do the heavy lifting on analysis and translation; engineers still validate the business logic, the integrations, and anything performance critical. Treated as automation with human review, it is genuinely powerful. Treated as magic, it reintroduces the exact undocumented-rule risk that sinks these projects.
A full rewrite costs the most and takes the longest, but it is the only path that lets you improve the workflow rather than just preserve it. If your VB6 tool encodes a process that has frustrated the floor for years, modernization is your one good chance to fix it instead of faithfully reproducing the frustration in a new language.
The real answer to which path is right is that it depends, and it depends on things only a look at your actual codebase can settle. Any vendor who quotes you a path before seeing the code is guessing.
04 / The numbers
What it costs and how long it takes
Most vendors hide this, so here are honest ranges, with the standard caveat that your system is the only thing that truly sets the number.
Automated conversion compresses these timelines meaningfully compared to a from-scratch manual rewrite, but the discovery and validation work is not optional and does take real time. The more useful number is not the project cost. It is the cost of doing nothing.
The real comparison: modernize vs. maintain
Add up what you actually spend keeping the old tool alive, and the business case usually makes itself.
The premium you pay for the rare talent who can still touch VB6
The productivity lost to a tool that cannot keep up with how you work today
The risk you carry every day the system runs on unsupported software
The institutional knowledge you lose each time a maintainer retires
For most manufacturers, that running total is what eventually makes the migration pay for itself, often faster than expected.
05 / Avoiding failure
The risks, and how a good partner manages them
Modernization projects do fail, and they tend to fail in predictable ways. Knowing the failure modes is how you avoid them.
The common thread is that disciplined discovery and phased delivery are not project overhead. They are the difference between a migration that works and one that becomes a cautionary tale told at the next industry conference.
06 / Proof
A manufacturer who modernized
A custom countertop manufacturer was running order processing through a system that was already 15 years old. Every incoming order had to be manually processed through the aging tool, and it took around four minutes to process a single order, a cost that multiplied across every order the business took in.
After the system was modernized, with the discovery work done first so the rebuild matched how the business actually operated, that same order processing task dropped to roughly 25 seconds.
The point is not the specific numbers. It is the pattern. A legacy operational tool, once modernized with the process in mind rather than just the code translated line for line, stopped being a tax on the team and started giving time back. That is the outcome a VB6 migration is supposed to produce, and it is the one a process-first approach is built to deliver.
Frequently asked questions
Can VB6 applications run on Windows 11?
The VB6 runtime still executes on Windows 11 for now, but that is not the same as being safe. The development environment is unsupported, third-party components receive no updates, and the application is running on borrowed time. Continued execution is not a substitute for a plan, and it does nothing to address the talent and security exposure that grows every year.
What happens if we lost the original VB6 source code?
This is common and not a dead end. When source is missing, the modernization starts by analyzing the compiled application and observing its behavior to reconstruct what it does, then rebuilds from that understanding. It adds work to the discovery phase, but lost source code is a well-understood, solvable situation, not a reason to give up on modernizing.
How long does a VB6 to .NET migration take?
A small, single-purpose tool can take a couple of months. A large, business-critical system with deep integrations is typically a phased effort over several quarters. The discovery phase is what lets anyone give you a real estimate, which is why a credible answer comes after a look at the codebase, not before.
Can we modernize one module at a time instead of all at once?
Yes, and for most manufacturers that is the safer path. Phased modernization lets you start with the highest-risk or highest-value piece, validate it against the original, and keep production running while you go. It also spreads the cost over time rather than concentrating it in one large project.
What VB6 to .NET migration tools do you use?
The right tooling depends on the codebase. Automated conversion tools (including AI) handle a large share of the translation and accelerate the work, but the dependency mapping, business-rule validation, and integration testing are done with engineers in the loop. Tools speed the work; they do not replace the judgment that keeps the modernized system behaving correctly.
Will the modernized application still connect to our ERP?
Yes! That is a core part of the plan, not an afterthought. A manufacturer's VB6 tool almost always talks to an ERP, scanners, printers, or the shop floor, and preserving those connections is part of the discovery and design work from the very start. The goal is a system that fits your operation better than the original, not one that breaks the integrations you depend on.
Start by understanding what you are sitting on
The lowest-risk first move is not committing to a rewrite. It is an operational discovery conversation that gives you a clear picture of your VB6 application's dependencies, risks, and realistic modernization paths, so you can decide with the facts in front of you.
Not ready to talk yet? Read our Legacy System Modernization overview.