Your VB6 application runs on Windows 11. That answers the first compatibility question. Now try installing it on a clean machine, rebuilding it from source, and running the workflows your users depend on. Those checks tell you much more about whether you can keep maintaining it.
Microsoft continues to support the VB6 runtime on supported Windows versions, including Windows 11. That support is limited to serious regressions and critical security issues in existing applications. It doesn't cover the entire application you built around the runtime.
Microsoft separates the core runtime from selected redistributable runtime files and the development environment. The VB6 IDE has been unsupported since April 8, 2008. Third-party OCX and ActiveX controls depend on their vendors for support. VB6 runtime components remain 32-bit and run under WOW emulation on 64-bit Windows.
Those distinctions should shape your assessment. A supported runtime can't tell you whether a specific control is maintainable, whether you still have its installer, or whether your team can reproduce the production build.
Start with a dependency inventory tied to the deployed application. Check the project files, installer, and working environment against one another. Record enough detail for another engineer to reconstruct the setup:
Assign each dependency an owner and a known support status. Mark anything unverified as unknown. “It is on the old developer laptop” is a lead to investigate, not a deployment procedure.
Use a controlled environment to build from the source you believe matches production. Preserve the compiler settings, dependency versions, installation media, and deployment instructions. Have someone other than the usual maintainer follow the process.
Then test the installer on a clean instance of your intended Windows 11 configuration, using the permissions an ordinary user will have. An existing workstation may contain years of accumulated prerequisites. A clean installation helps expose those assumptions.
A successful build doesn't make the IDE supported. It gives you evidence that your team can reproduce and deploy the application while you decide what to do next.
Choose workflows with the people who use the application. Include invoice calculations, report totals, imports, exports, failed transactions, and recovery after an interrupted operation. Add month-end or other infrequent processes that a quick demonstration would miss.
Capture inputs and expected results using approved test data. Check permissions and failure handling as well as the happy path. Keep these cases: they become acceptance tests for a future migration.
For example, a replacement billing screen can look correct while calculating a discount differently. Compare the resulting amounts and database changes with the existing application. Investigate differences before accepting the new behavior.
Prioritize the problems the assessment uncovers. A missing deployment package needs a different response from an unsupported control that blocks a required feature. Decide which issues can be contained and which justify replacing a component or migrating a workflow.
If you use AI to translate code, apply the same acceptance criteria. Compilation is an early checkpoint; business behavior still needs verification. Include dependency replacement, deployment, and user acceptance in the estimate.
Start with one representative workflow that exercises a difficult dependency and meaningful business rules. Use what you learn to estimate the rest of the application. That produces a stronger plan than extrapolating from the easiest screen.
Talk to GAPVelocity AI about a VELO assessment for your VB6 application. Bring the source, dependency inventory, and critical workflows so the discussion starts with the code and the behavior you need to preserve.
Support-policy details above are drawn from Microsoft’s statement linked below. The assessment steps are our recommended engineering approach.
Source: Microsoft Support Statement for Visual Basic 6.0 on Windows