How Do You Rebuild a VB6 Application With No Source Code?

Can you decompile a VB6 EXE to get the source code back?

The honest answer is rarely, and never cleanly. Visual Basic 6 compiles in two modes, P-code and native code. Native was the default in VB6, and roughly 90 percent of VB6 applications shipped as native².

If your app is P-code, a decompiler can recover the forms and a good part of the program logic as pseudo-source. If it is native, you do not get the original code back at all. What you get is a slow reverse-engineering effort against disassembly³. Two things are gone for good in either case: the variable and function names, and every comment the original developer wrote. A decompiler hands you working logic full of names like Function1 and Var7, not a project anyone can maintain with confidence⁴. Decompilation is an analysis aid, not a restore button.

What can actually be recovered from a VB6 executable?

It helps to be precise about what survives compilation and what does not, because the gap is where the rebuild effort lives.

The most valuable recoverable asset is usually not inside the EXE at all. It is the database the application has been writing to for years. That schema and that data are the real record of how the business runs, and they survive no matter how the program was compiled.

Why is "just decompile it" the wrong plan for a business-critical app?

Even a clean P-code decompile gives you pseudo-source that nobody can maintain confidently. No names, no comments, no design intent. Building the next ten years of a business on reverse-engineered code is fragile in a way that does not show up until someone has to change it.

The platform underneath is frozen too. The VB6 IDE has been unsupported since April 8, 2008, and Microsoft's own guidance is to replace VB6 applications with modern technology¹. The runtime still ships in Windows 11, but support is limited to serious regressions and critical security issues, and it is 32-bit only⁵.

What does PCG actually do to rebuild a VB6 app with no source?

The method is reconstruction, and it starts by reading the application rather than chasing the missing code. The order matters.

1. Discovery and behavior capture. Run the app, document every screen, input, output, and rule as a black-box specification of what it does.
2. Database first. Read the schema and the data the app depends on. This is the backbone of the rebuild and the part that survived intact.
3. Extract what the EXE allows. Pull forms and layouts for visual parity, recover resources, and use any P-code logic a decompiler can surface as reference material.
4. Map the dependencies. Identify the third-party controls and external calls, then match each to a modern equivalent.
5. Rebuild on .NET. Build to the documented behavior, not the lost code, so the result is a maintainable application rather than a transcription.
6. Parallel run and cut over. Run the old and new against the same data until the new one is validated, then switch.

This is the same discovery-first approach PCG uses on every legacy engagement, including cases where the original developer has disappeared. The target and scope come out of step one, which is why the rebuild is quoted on evidence rather than on a guess. For the broader picture of moving VB6 forward, see the VB6 migration to .NET guide.

How long does a no-source VB6 rebuild take, and what drives it?

It depends, and the discovery phase is what turns that into a real number. The drivers are the count of forms and reports, how much business logic is buried in the code, the number of integrations and third-party controls, the size and cleanliness of the database, and whether the app is P-code, which is more recoverable, or native, which is less.

A single-form utility is a short project. A multi-module operations system with hundreds of rules is a larger one. The honest version of this answer never comes before the discovery phase, because quoting a no-source rebuild without reading the app first is how projects double in cost halfway through. The same variables drive the price, which is covered in the cost of losing your business software source code.

What happens if you do nothing?

The app keeps running, because the runtime still works in Windows 11. That is exactly what makes the risk so easy to defer.

The trigger is rarely a crash. It is a new Windows build that breaks a 32-bit dependency, a third-party control that stops loading after an update, a hardware failure on the one machine the app lives on, or a business requirement the frozen application cannot meet. On that day the rebuild becomes an emergency, run on the worst possible timing instead of yours. The source code did not vanish today. What is quietly disappearing is the choice about when to deal with it.

Frequently Asked Questions