TL;DR
- Four executor categories can run a VB6 modernization, and none of them is complete by itself. In-house teams, general-purpose AI coding tools, specialized conversion platforms, and SI outsourcing firms each cover a different slice of the work, and most real estates end up combining more than one.
- General AI coding tools are not built for VB6 today. GitHub Copilot’s own app modernization documentation does not list VB6 among its supported languages, and neither does Microsoft’s .NET Upgrade Assistant.
- Specialized platforms automate conversion, not the whole lifecycle. Tools built specifically for VB6 claim 70 to 95 percent automation on code conversion, but assessment, validation, and deployment governance are frequently left for the buyer to arrange separately.
- In-house is still the default, by inertia more than evaluation. 68 percent of US organizations rely on internal IT for legacy software maintenance, which makes it the most common answer, not automatically the right one for a VB6-specific estate.
Visual Basic 6 shipped in 1998. Its IDE has been unsupported since April 2008. Microsoft’s own support statement ties ongoing runtime support to whatever Windows version it runs on. Coverage is limited to serious regressions and critical security issues, not new features or fixes for third-party ActiveX and OCX controls [1]. Windows 10 support ended in October 2025.
Most VB6 shops that are reading this have already settled whether to modernize. What is still open, and what most vendor content skips past, is who or what becomes the actual VB6 modernization partner running it. That decision gets harder to defer once the Extended Security Update costs that follow mainstream Windows support start escalating.
VB6 Modernization Vendor Types Compared
| Category | Best For | Automation on VB6 | Typical Cost Driver | Biggest Limitation |
| In-House Team | Small, well-documented estates with time to spare | None built in, manual work | Opportunity cost of pulled roadmap capacity | VB6 and current .NET-target skills rarely coexist on one team |
| AI Coding Tools (Copilot, Cursor, Claude Code, ChatGPT) | Ad hoc code reading, explanation, and small isolated conversions | Low for VB6 specifically, not purpose-built | Developer time to prompt and verify, plus subscription cost | No persistent whole-codebase understanding, no VB6-aware pipeline |
| Specialized Modernization Platforms | Bulk mechanical conversion of VB6 to .NET or C# | 70 to 95 percent claimed, varies by tool and codebase | Per-line licensing or a fixed-scope project fee | Most cover conversion only, leaving assessment and validation to the buyer |
| SI / Outsourcing Firms | Large multi-application programs needing delivery capacity | Low by default, staff-augmented work | Hourly consulting rates | Rarely carry VB6-specific tooling, capacity rather than automation |
A VB6 modernization partner is whichever one of these four an organization puts in charge of the work. The choice depends less on personal preference than on codebase size, documentation state, compliance exposure, and how much of the outcome the buyer needs to own directly.
An in-house team keeps full control and institutional knowledge but usually lacks both VB6-era and current .NET skills at once. A general AI coding tool assists a developer but is not purpose-built for VB6 conversion. A specialized platform automates the mechanical transformation with a defined ceiling, and an SI brings capacity and process discipline without VB6-specific tooling.
Case study: US semiconductor manufacturing tools provider. Years of mergers and acquisitions had left six mission-critical VB6 components tangled into a fragmented, multi-language stack, and any modernization had to preserve the exact real-time timing that stepper and servo motor control depended on. A full-lifecycle approach, assessment through deployment, delivered a 50 to 70 percent reduction in manual processes and a 40 percent improvement in application performance while standardizing the stack onto .NET.
In-House Teams for VB6 Modernization: Capabilities and Limits
An in-house team is the existing application or engineering staff taking on the modernization alongside, or instead of, their regular roadmap. It is the most common answer by a wide margin.
According to Saritasa’s 2025 Legacy Software Modernization Survey, 68 percent of US organizations rely on internal IT for legacy software maintenance, 20 percent use dedicated legacy specialists, 7 percent outsource to an external vendor, and 5 percent report no regular maintenance at all [2].
What in-house gets right is control. Sequencing, priorities, and institutional knowledge of the business logic, where any of that knowledge survived staff turnover, all stay with the people who already understand the organization.
What it struggles with is specific to VB6. A team that knows the current application rarely also has hands-on experience with VB6’s COM model and current .NET target architecture at the same time, since the two skill sets belong to different developer generations. Freeing up two developers for a couple of quarters, a rough floor for even a modest VB6 estate, means pulling them off product work the rest of the business is still counting on.
In-house is not a vendor category, so there is no brand to name here. What it looks like in practice varies by how much outside help gets layered in.
One useful pattern from Legacyleap’s own delivery work: an internal IT team of fewer than six people expanded a modernization program from two applications to twelve over six months once a platform took over the mechanical work, with the team’s own time redirected to review rather than line-by-line rewriting.
This same tradeoff, not VB6-specific, plays out across legacy modernization generally, and VB6’s dead IDE and vanishing talent pool just sharpen it.
AI Coding Tools for VB6 Modernization: What Copilot and Claude Code Can and Can’t Do
General-purpose AI coding assistants, GitHub Copilot, Cursor, Claude Code, and ChatGPT among them, get used constantly by developers to read, explain, and attempt small conversions of unfamiliar code.
For VB6 specifically, that usefulness has a hard boundary most buyers have not run into yet.
GitHub Copilot’s own app modernization documentation lists what it currently supports:
- Java version upgrades and framework moves
- .NET Framework and .NET version upgrades
- JavaScript and TypeScript package upgrades
- A Python migration path to Microsoft’s Agent Framework [3]
VB6 does not appear anywhere in that list. Code District’s 2026 migration guide confirms the same gap independently: Microsoft’s own .NET Upgrade Assistant does not support VB6 either, and Microsoft has since pointed users toward the GitHub Copilot modernization agent instead, which carries the identical limitation [4].
A developer can still use Copilot or Claude Code to explain an unfamiliar VB6 subroutine, or to draft a small, isolated conversion that a human then checks line by line.
What none of these tools provide is a persistent, whole-codebase understanding of a VB6 application, or a conversion pipeline built for VB6’s specific quirks: late-bound variables, ADO-to-ADO.NET translation, Windows API calls, and dead third-party controls among them. They assist a human-led effort. They do not run one. For tool-by-tool tactics, the fuller VB6-to-.NET conversion breakdown goes deeper than the category view here.
Specialized VB6 Modernization Platforms: What They Automate and What They Don’t
A specialized modernization platform is software built specifically to parse, understand, and convert VB6 code, not a general-purpose AI assistant applied to it after the fact. This is where real automation on VB6 exists today. Three examples:
- GAPVelocity AI’s VBUC (VB6 AI Migrator). Formerly Mobilize.Net’s VBUC, it combines rule-based conversion with generative AI to convert VB6 to VB.NET or C#, licensed per line of code, with a stated 90 to 95 percent automation target [5]. That figure covers the code conversion step itself, not the full assess-through-deploy lifecycle.
- TSRI’s Composite AI. A deterministic-plus-generative hybrid positioned against pure generative-AI conversion, which TSRI argues is unreliable for enterprise systems on its own. The company markets Composite AI for VB6 alongside its broader legacy-modernization practice, though its publicly documented case studies for this approach are concentrated in COBOL and mainframe migrations rather than named VB6 engagements [6].
- fecher’s vbPORTER. A proprietary converter with AI-assisted complexity assessment and QA, offered as a managed engagement or in-house-with-coaching.
Most of these tools price for the conversion step specifically. Assessment, validation against the original, and deployment governance are frequently left for the buyer to arrange separately.
Where Full-Lifecycle Platforms Differ
Not every platform in this category stops at conversion. A smaller set treats conversion as one stage in a five-stage lifecycle, Assess, Comprehend, Modernize, Validate, and Deploy, rather than the whole job.
That distinction matters more than the automation percentage alone. The semiconductor manufacturer example earlier in this piece, and another case further down, both took the full-lifecycle route instead of point conversion.

The $0 Modernization Assessment shows what a specialized platform would actually find in your specific VB6 codebase, dependencies, dead controls, and undocumented business logic included, before you commit to converting anything.
SI and Outsourcing Firms for VB6 Modernization: Capacity Without VB6-Specific Tooling
A systems integrator is a large, generalist IT services or consulting firm that staffs the modernization with its own consultants rather than selling a conversion tool.
MarketsAndMarkets names Accenture, Cognizant, TCS, Deloitte, IBM, and Capgemini among the top companies in the system integration services market. IBM Consulting, Cognizant, and EPAM Systems in particular deliver modernization through consulting and engineering execution rather than platform-led automation [7].
What an SI engagement buys is delivery capacity and process discipline at a scale a single in-house team usually cannot match, typically priced on time and materials at senior US consulting rates.
What it generally does not bring is VB6-specific tooling. Large SIs staff to whatever stack a given client needs rather than marketing stack specialization. That means the VB6-specific risk, dead ActiveX and OCX controls, undocumented COM call chains, gets handled by whichever consultants happen to be assigned rather than by a repeatable, purpose-built process.
That tradeoff makes SIs the right fit for large, multi-application programs that need coordinated delivery across many systems at once, and a weaker fit for a single VB6 application where the value is in VB6-specific conversion tooling rather than headcount. The same pattern holds across the wider application modernization platform and provider landscape, beyond VB6 specifically.
How to Choose the Right VB6 Modernization Approach for Your Estate
The four categories above answer “what is available.” The criteria below narrow that down to what actually fits a specific estate.
| If your situation is… | The strongest fit tends to be |
| Small codebase, well documented, spare developer capacity | In-house, possibly with a platform assist |
| Need to understand what an unfamiliar VB6 codebase does before committing to anything | A specialized platform’s assessment step, or a $0 Modernization Assessment |
| Heavy reliance on dead ActiveX/OCX controls or undocumented COM chains | A specialized platform built for VB6 specifically, not a general AI tool |
| Large, multi-application program needing coordinated delivery | An SI, ideally one running a platform rather than staffing conversion by hand |
| Compliance deadline or audit finding driving the timeline | A platform or SI engagement with built-in validation, not an unmanaged in-house effort |
Few real VB6 estates fit cleanly into one row. A specialized platform handling bulk conversion with an in-house team reviewing the output, or an SI running a platform-licensed engagement instead of staffing the conversion manually, both show up more often in practice than a single-category choice.
A Technical Demo walks through how a five-agent lifecycle assesses, converts, and validates a VB6 application end to end, so the choice above is based on what your specific estate needs rather than a general rule.
Legacyleap’s Full-Lifecycle Approach to VB6 Modernization
The specialized-platforms section above pointed at a gap. Most conversion tools automate the transformation step and leave assessment, validation, and deployment governance to the buyer.
Legacyleap, a Texas-based platform that has run more than 150 production-grade assessments across enterprise legacy estates, is built to own all five stages, Assess, Comprehend, Modernize, Validate, and Deploy, through five coordinated agents rather than a single conversion engine.
The Assessment and Documentation agents build a persistent, whole-codebase understanding of a VB6 application before any conversion begins, reconstructing architecture, dependencies, and business logic even when no documentation exists.
The Modernization Agent produces diff-based, human-reviewed transformations rather than direct, unreviewed writes. The QA Agent validates functional parity against the legacy baseline before anything reaches production, closing the gap that a point conversion tool typically leaves open.
That full-lifecycle coverage has already run against VB6 estates with the exact failure modes described above. One audit-flagged flight-operations application, carrying more than 2,500 COM references and zero existing documentation or tests, went from flagged to audit-ready in eight weeks.
Case study: US financial services institution, Salt Lake City, UT. A VB6 core tied to strict financial regulatory requirements needed to move to a scalable architecture without breaking compliance along the way. Legacyleap’s agents handled code comprehension, dependency mapping, and migration in a single coordinated pipeline, and the conversion ran 70 to 80 percent faster than a manual approach while meeting the same regulatory standards.
Both of Legacyleap’s delivery models map onto the categories above rather than replacing them. Platform Licensing runs inside a client’s own environment, a different way to run the specialized-platform or in-house path with a client’s own team at the controls.
Turnkey Modernization Services hands the engagement to Legacyleap end to end, a different way to run the outsourced path with a fixed scope instead of open-ended time and materials.
Choosing a VB6 Modernization Partner
The tool decision gets easier once the executor decision is made. In-house, a general AI coding assistant, a specialized VB6 conversion platform, and an SI each solve a different part of the problem, and most real estates end up combining more than one.
A $0 Modernization Assessment maps a specific VB6 codebase, its dependencies, its dead controls, and its undocumented logic, in 2 to 5 days, at no cost and no obligation, before any of the four paths above gets committed to.
A Technical Demo shows how the underlying five-agent lifecycle works on a real VB6 estate.
FAQs
The runtime is supported as long as the underlying Windows version is, but only for serious regressions and critical security issues, not third-party ActiveX or OCX controls. That gap, not the runtime itself, is usually what forces a modernization decision.
Specialized platforms with high automation rates typically compress timelines to 3 to 6 months for mid-size VB6 estates. SI-led engagements often run 12 to 24 months due to manual rewriting and reliance on scarce VB6-skilled developers.
Yes. Full-lifecycle platforms like Legacyleap handle VB6-specific dependencies, COM, ActiveX, and third-party controls, that general-purpose AI coding tools and most standalone conversion tools cannot reliably address.
Third-party controls without a .NET equivalent, OCX or ActiveX among them, have to be rewritten or swapped for a supported component during modernization. Platforms with a comprehend phase, Legacyleap’s five-stage lifecycle included, map those dependencies before any code conversion begins.
References
1. Microsoft, Support Statement for Visual Basic 6.0 on Windows. https://learn.microsoft.com/en-us/previous-versions/visualstudio/visual-basic-6/visual-basic-6-support-policy
2. Saritasa, Legacy Software Modernization in 2025: Survey of 500+ U.S. IT Pros. https://www.saritasa.com/insights/legacy-software-modernization-in-2025-survey-of-500-u-s-it-pros
3. Microsoft Learn, Languages and Frameworks Supported by GitHub Copilot App Modernization. https://learn.microsoft.com/en-us/azure/developer/github-copilot-app-modernization/languages
4. Code District, VB6 Migration in 2026: The Complete Guide to What It Costs, What Breaks, and Who Can Fix It. https://codedistrict.com/blog/vb6-migration-guide
5. GAPVelocity AI, VBUC (Visual Basic Upgrade Companion) FAQs. https://www.gapvelocity.ai/products/app-migrations/vbuc/faqs/
6. TSRI, Composite AI, The Proven Approach to VB6 Modernization. https://tsri.com/composite-ai-vb6-modernization/
7. MarketsAndMarkets, Top Companies in System Integration Services Market. https://www.marketsandmarkets.com/ResearchInsight/system-integration-services-market.asp







