VB6 & Classic ASP Migration Service
Tool-assisted rewriting moves you to .NET without rebuilding.
VB6 to C# / Windows Forms (.NET 10); Classic ASP to ASP.NET.
Powered by gmStudio (Great Migrations)
The deadline is already visible
Microsoft plans to disable VBScript by default around 2027 and remove it later — and VBScript is what Classic ASP runs on.
Running is not the same as maintainable
The VB6 runtime is still supported on Windows 11, but IDE support ended in April 2008. The tools and people who can change the code go first.
Track record in Japan
Logistics, receivables, EDI, sales, order management, core batch and other business-critical systems (VB6 and Classic ASP combined).
VB6 support — the facts
VB6 runtime
Supported on Windows 11 / 10 and Windows Server 2025 back to 2008 R2, following the OS lifecycle.
VB6 IDE
Unsupported on every Windows version. Microsoft strongly recommends replacing VB6 apps with current technology.
32-bit / 64-bit
On 64-bit Windows it runs under WOW64; it never becomes 64-bit native.
Bundled OCX / DLLs
mscomctl.ocx etc. must be shipped with the app; threed32.ocx, spin32.ocx etc. are unsupported.
Source: Microsoft, “Support Statement for Visual Basic 6.0 on Windows” (Microsoft Learn)
Common misconceptions
「VB6 apps no longer run on Windows 11」
The runtime is supported on Windows 11 / Server 2025. “It will stop working” is not a valid reason to migrate.
「The runtime is supported, so we’re safe」
Only running is supported. The IDE ended in 2008, and nothing supports changing or rebuilding the code.
「Migrating means rebuilding from design documents」
Converting the current source to C# with a tool keeps the current specification. Updated documents are not required.
「One day everything will stop」
In practice you get stuck piece by piece — OCXs, DB drivers, 32-bit limits, engineers.
Deadlines around VB6 and Classic ASP
- Oct 2025Windows 10 support ended — the client environment changes
- Jul 2026SQL Server 2016 extended support ended — database upgrades may come first
- Oct 2026Year 1 of Windows 10 commercial ESU ended — per-device cost doubles each year
- Nov 2026.NET 8 / .NET 9 support ends — choose .NET 10 LTS as the target
- Jan 2027Windows Server 2016 support ends — servers for ASP and VB6 batch jobs need replacing
- Around 2027 (planned)VBScript to be disabled by default in Windows (removal later) — hits Classic ASP and VB6 code using VBScript.RegExp
- Oct 2028Final Windows 10 commercial ESU deadline
- 2029 (guide)Expected end of Edge IE mode
Sources: Microsoft Lifecycle, .NET Support Policy, Windows IT Pro Blog. The VBScript timing (disabling, then removal) is a stated plan, not a fixed date.
VB6: the real risks come from the surroundings
The IDE can’t be maintained
Installing and building on new PCs becomes unstable; every change means hunting for an old PC that still runs VB6.
No engineers to make changes
Legal and tax changes wait until someone who can do it is found.
The 32-bit wall
Combinations with 64-bit Office, DB clients and ODBC drivers are limited, freezing upgrades around the app.
Components are drying up
New ActiveX development has shrunk, and code using VBScript is affected by its default disabling.
VB6 is not a dead technology — it is becoming unmaintainable. The issue is continuity of maintenance, not whether it runs.
The state of Classic ASP
The platform is going away
Classic ASP runs on VBScript. Once VBScript is removed from Windows, the runtime itself is gone.
Engineers are running out
People who can work on VBScript / Classic ASP are harder to find every year.
Fewer integration options
Modules for Classic ASP from payment gateways and other services are shrinking.
IE-dependent code already fails
IE11 ended in June 2022; client-side VBScript and IE-mode screens need workarounds.
Classic ASP hits a wall before support ends: the people who can build it and the services it connects to disappear first.
Three migration options
Stay as is
Cost: low
Pros
- No further investment now
- No impact on operations
Cons and risks
- Forced stop when the deadline comes
- No way to handle faults or legal changes
- No engineers left
Rebuild from scratch
Cost: high
Pros
- Business processes revisited
- Latest architecture available
Cons and risks
- Design documents required
- Largest effort; hard to freeze specs
- Same behaviour hard to assure
Tool-assisted migration
Cost: medium
Pros
- Spec carried over to .NET
- No need to update documents
- Effort ≤ 1/5 of manual
- Quality stabilizes as rules accumulate
Cons and risks
- Code becomes unfamiliar to VB6 / ASP engineers
Move to .NET as is, then rebuild only what needs it — a two-step approach is the realistic one.
VB6 target — C# / Windows Forms (.NET 10)
| Today (VB6) | After (.NET 10) | |
|---|---|---|
| Language | Visual Basic 6.0 | C# (VB.NET also possible) |
| Screens | VB6 forms / controls | Windows Forms / .NET controls (WPF possible) |
| Data access | ADO / RDO / DAO / oo4o | ADO.NET / ODP.NET |
| Third-party | ActiveX (OCX) | .NET versions or standard .NET controls |
| Runtime | VB6 runtime + registered OCX (32-bit) | .NET 10 runtime (64-bit capable) |
| IDE | VB6 IDE (unsupported) | Visual Studio (current) |
Windows Forms is structurally close to VB6 forms, so layouts and operation carry over almost unchanged. Deployment can use ClickOnce and similar methods.
Option: web version (Blazor Server)
The migrated C# / Windows Forms source runs on the server and is displayed in the browser. Without rebuilding screens, the system can be used in a browser from outside the office and across sites.
Windows Forms (desktop)
When you want to keep today’s usability
- Structurally close to VB6 forms, so screens and operation carry over
- Printing, local files and devices used directly
- Windows clients still need deployment
Blazor Server (web)
When you want the same source in the browser
- Runs in the browser from the same source as the Windows Forms version
- Nothing to deploy to PCs; works remotely and across sites
- Responsiveness and traffic depend on the network
- Requires a Windows server; printing is basically via PDF
Because the web version runs from the same source as Windows Forms, you can migrate to Windows Forms first and extend browser use to the business areas that need it. See how it works (web architecture) →
Tool-assisted rewriting with gmStudio
A migration development platform from Great Migrations (USA). We offer everything from licences, training and technical support in Japanese to carrying out the conversion for you.
Not a one-shot converter
You keep adding conversion rules and re-converting. Because rules — not hand edits — accumulate, you can re-convert at the same quality whenever the source changes.
Built on compiler technology
More than 30 years of language-processing technology. COM / ActiveX APIs, Win32 API calls and built-in functions are replaced with .NET equivalents.
Keep changing the system meanwhile
Maintenance of the current system can continue in parallel, shortening any code freeze. Throughput is about one million lines per minute.
Supported conversions
ASP.NET is generated in code-behind style. Visual Studio 2010–2022 project formats are supported, and the target .NET version is selectable.
Compared with a manual rewrite
Manual rewrite
- Update or create design documents
- Update or create test cases
- Develop from detailed design
- Unit testing
- Integration and system testing
- Data migration
- Cutover
gmStudio migration
- Skip if documents are not needed
- Update or create test cases
- Conversion with gmStudio (rule iteration)
- Unit testing
- Integration and system testing as needed
- Data migration (often unnecessary)
- Cutover
Because documents don’t have to be updated first, actual migration effort drops to one fifth or less. If you need design documents, AppDocOne can generate them.
How conversion works — three iterative steps
Resolve references
Source and libraries are scanned, dependencies analyzed and the compile order fixed. Unresolved references are handled.
Resolve compile errors
Compile in gmStudio or Visual Studio and fix the errors as conversion rules.
Resolve runtime errors
Unit tests reveal runtime differences, which are fixed. This is our standard delivery scope.
Third-party components
Same API in the .NET version
Swap in the .NET library after conversion and adjust namespaces.
Different API in the .NET version
Our intermediate library connects converted code to the .NET version without touching the code. Differences stay in the library, so re-conversion causes no rework.
Products we have handled
| Databases | oo4o → ODP.NET / ADO·ODBC (Oracle) → ODP.NET / ADO·ODBC (SQL Server) → ADO.NET / RDO → ADO.NET |
|---|---|
| Reports | Excel → current / SVF → .NET / Crystal Reports → .NET / ActiveReports → .NET / PrintPRO → EUR |
| GUI | SPREAD (ActiveX) → SPREAD (.NET) / InputMan → InputMan (.NET) / TrueDBGrid·FlexGrid → .NET / ComponentOne / SSSplitter → ComponentOne |
| Other | Win32 API → .NET equivalents / BASP21 (mail) / CDO / MSXML2 / Shell32 / Remote Scripting · client VBScript → JavaScript |
Other products can be supported by building a new intermediate library. Start by sending us the list of products you use.
Service levels
Licence and support
If you convert in-house
- gmStudio licences
- Training
- Technical support in Japanese
Up to compile-error removal
If you will own testing
- Reference resolution and conversion rules
- Source that compiles on the specified .NET version
- Conversion report
Up to runtime-error removal
If you want it running
- Everything in Level 2
- Unit tests (normal cases)
- Fixed until normal operation raises no runtime errors
Track record
Business areas migrated
Optional services
Project phases
Survey and rough estimate
Led by us / 1–2 weeks
Inventory of source size, referenced libraries and components; approach and rough estimate.
Conversion
Led by us / by size
Rule development and iterative conversion, compile and runtime error removal, conversion report.
Testing and migration
Shared / by size
Comparison with current screens, integration and system tests, deployment, data migration, cutover.
How we estimate
Share your source code
Share your VB6 projects or Classic ASP source. We analyze size, references and components and present an approach and estimate. NDA first.
If source cannot leave your company
Run the analysis feature of the gmStudio trial in your own environment and send us the report. We estimate from the report, so your source code never leaves your company.
Just the list of third-party products (OCX / DLLs) and a rough source size is enough for an initial answer.
Start with the list of components you use and a rough source size
Tell us the platform version and the number of screens, and we will send an initial answer. We are happy to sign an NDA first.
TEL +81-3-5962-3776