Quick answer: VB6 migration is the project of moving a Visual Basic 6 desktop application to a supported stack, most often .NET Framework or .NET Core with Windows Forms, WPF or a new web UI. Successful migrations start with an inventory of forms, reports, COM components and databases, then choose a staged rewrite over a risky big-bang cutover. The goal is continued business capability on OS versions and runtimes you can still patch.
Why VB6 projects resurface in 2020
Visual Basic 6 powered countless line-of-business tools in the late 1990s and 2000s: order entry, shop-floor screens, insurance rating utilities, membership desks. Many still run because they encode years of edge-case rules. The problems show up when:
- New Windows versions break installs or printer drivers
- The last developer who knew the code retires
- Auditors ask about unsupported runtimes
- You need web or remote access the desktop EXE cannot provide
- Integrations require TLS and modern APIs the old stack struggles to call
Ignoring the app is a decision too. It just concentrates risk into an emergency later. A planned VB6 migration costs less than an outage during peak season.
What “migration” can mean
Teams use the word for different strategies:
- Recompile and wrap: Limited. VB6 is not a first-class citizen on modern toolchains. Compatibility shims buy time, not a future.
- Automated translation to VB.NET: Tools can convert syntax. They rarely produce clean, maintainable .NET. Budget heavy cleanup.
- Rewrite in C# or VB.NET on .NET Framework: Common for internal Windows desktop apps that must feel familiar.
- Rebuild as web apps on ASP.NET Core or .NET Framework MVC: Better when remote users and centralized deploy matter.
- Replace with a commercial package: Right when the VB6 app mainly clones commodity workflows (basic CRM screens, simple inventory).
Pick based on uniqueness of business rules, user count and how tightly the UI is coupled to logic. Related reading on older Microsoft stacks includes classic ASP migration and moving from .NET Framework toward .NET Core when you are already in managed code.
Step 1: Inventory before you estimate
Do not price a rewrite from a demo click-through. Catalog:
- Forms and reports (count and complexity)
- Shared modules and circular dependencies
- COM / ActiveX controls and licensing
- Database engines (Access, SQL Server versions, flat files)
- External devices (scanners, scales, label printers)
- Security model (who can do what)
- Batch jobs and scheduled EXEs
- Documented versus tribal business rules
Interview power users. The code often omits why a validation exists. Capture that why in a short software requirements style note even if you are not writing a full waterfall spec.
Step 2: Separate UI from rules when you can
Many VB6 apps bury SQL and business rules inside button click handlers. As you migrate, extract domain logic into testable .NET classes. Even a partial extraction reduces the cost of changing UI technology later (WinForms today, web tomorrow).
If you stay on desktop initially, Windows Forms can feel familiar to VB6 users. WPF helps when you need richer layout. Web UIs help distributed teams. Do not chase novelty. Chase deployability and hiring.
Step 3: Choose a cutover style
Big bang: Build the new system in parallel, switch everyone on one weekend. High drama. Only viable for small apps with few integrations.
Staged by module: Migrate shipping first, then billing, then reporting. Needs temporary integration between VB6 and .NET pieces. More planning, less all-or-nothing risk.
Strangler approach: New features go to .NET only. Old screens fade as usage drops. Works when the app is large and still evolving.
Data migration deserves its own plan: scrub duplicates, define source of truth and rehearse restores. SQL Server performance habits from guides like SQL Server performance tuning for .NET pay off when old Access backends finally move.
Testing that protects the business
Automated unit tests may be thin at first. Compensate with:
- Golden datasets comparing old vs new outputs for rating or pricing routines
- Scripted UI checks on critical paths
- Parallel run periods where supervisors spot-check
- Rollback drills
Add unit testing in .NET as you extract logic. Tests are cheaper than recalling trucks because an invoice rule drifted.
People and change management
Users loved (or at least memorized) the old quirks. Training, side-by-side cheat sheets and a hypercare week after go-live matter as much as code. Keep a triage channel for “this used to work” reports. Some are defects. Some are intentional process changes you forgot to communicate.
Cost drivers executives should expect
- Undocumented COM dependencies discovered mid-project
- Report pixel-parity requests that consume weeks
- Printer and device re-certification
- Dual licensing during coexistence
- Security remediation the old app never had (proper auth, auditing)
Build contingency into the schedule. A fixed-bid quote without discovery is a bet, not a plan.
What not to do
- Promise a perfect one-click converter result
- Freeze all business change for two years while rewriting everything
- Skip inventory because “we know the app”
- Target unsupported preview runtimes for a conservative line-of-business tool
- Confuse VB6 migration with a full digital transformation slogan deck
Stay concrete: which screens, which data, which date, which owner.
FAQ
Is VB6 still supported by Microsoft?
The VB6 runtime has been discussed in support statements over the years, but the development environment and ecosystem are legacy. Planning a move is prudent even if a given EXE still launches today.
Should we move straight to .NET Core?
If you need long-term cross-platform or modern hosting, consider .NET Core 3.1 for new web APIs and apps. For a faithful desktop port under time pressure, .NET Framework remains common in 2020. Choose per module, not by slogan. Avoid waiting on unreleased major versions for a production migration.
Can we keep Access as the database?
You can temporarily. For multi-user reliability and backups, SQL Server (or another managed engine) is usually part of the modernization.
How long will it take?
Small tools might take weeks after discovery. Multi-module systems often take many months in stages. Distrust anyone who quotes a date before counting forms and integrations.
A practical starting checklist
- Appoint a business owner and a technical owner
- Export a form and dependency inventory
- Rank modules by business criticality and pain
- Run a two to four week discovery with a spike rewrite of one thin vertical slice
- Decide staged vs big bang with eyes open
- Fund training and hypercare, not only development hours
Discovery spike: prove the path on one vertical slice
Before staffing a full rewrite, pick one thin path such as “create customer, enter order line, print pick list.” Rebuild that slice in .NET against a copy of production data. Time how long mapping rules took. Note every COM control that blocked progress. The spike turns opinions into a calendar.
Stakeholders see a screen they recognize. Engineers see the real dragons. Quotes written after a spike are boring in the best way: they reflect evidence.
Hybrid coexistence patterns
During staged migration you may need the VB6 app and the .NET app to share a database. Agree on table ownership. Avoid two UIs writing the same rows with different validation. If you must integrate temporarily, prefer clear service boundaries over reading each other’s UI tables casually.
File drops and message queues can bridge batches overnight. Document failure handling: what happens when the nightly sync misses a row? Silent drift is how finance teams lose trust in the project.
If you need help planning or building a VB6 migration onto modern .NET stacks, see our Custom development services.
