Establish the build boundary
Begin with every VBP and VBG file, then resolve forms, classes, modules, user controls, resources and binary references. A project can look complete while depending on an unversioned OCX, a COM server from another repository or a type library installed only on one developer PC.
- Record compiler and service-pack level, conditional compilation constants and compatibility settings.
- Resolve references by identity and version, not filename alone.
- Locate installer projects, database scripts, report templates and external configuration.
- Compare produced binaries with the deployed release before trusting the recovered build.
Risk patterns worth tracing
| Pattern | Operational significance |
|---|---|
| Global state and implicit form instances | Startup order and hidden coupling make isolated changes difficult. |
On Error Resume Next | Failures may be suppressed far from the eventual symptom. |
| Dynamic COM creation | Dependencies may not appear in project references. |
| DAO/ADO connection strings in code | Database location, credentials and provider assumptions become deployment risks. |
| Win32 declarations and pointer values stored in Long | Compatibility assumptions require review before platform changes. |
Useful outputs
A practical analysis produces a project/dependency map, reproducible build findings, high-risk modules, critical workflows and a prioritized intervention plan. It should distinguish missing source from merely missing configuration.
If the build cannot be reconstructed, continue with VB6 application recovery. For operational continuity use VB6 support; for planned change use modernization analysis. Database and hardware boundaries may require the database or serial clusters.
Provide for assessment
Complete source roots, deployed binaries, installer media, the last build machine if available, error logs and a description of the workflows that cannot change.