The grey program with the chunky buttons
It was written in Visual Basic 6 at some point around the turn of the century. It has grey forms, a menu bar, maybe a splash screen with an old logo. It prints your delivery notes, works out your pricing, or schedules your production. Staff are fast with it because they have used it for years.
Each Windows upgrade makes someone nervous. Last time a new PC arrived, the program would not start until somebody found the right version of an old OCX control and registered it by hand. There is a folder of installers nobody wants to delete.
You know it has to go. What you do not know is how to replace something whose full behaviour nobody can describe.
Why VB6 programs are so sticky
The program is not really the problem. The problem is that the program is the only complete record of how parts of your business work.
Over the years, rules were added straight into the code: a discount that only applies to one customer group, a rounding quirk the accounts team relies on, a check that stops two orders sharing a reference. Those rules were never written anywhere else. The developer who added them may be long gone.
Many replacement projects start by interviewing staff about what the system does. Staff describe what they see, which is the screens. The rules underneath come to light only when the new system gets something wrong in production.
The cost of leaving it where it is
| Risk | How it shows up |
|---|---|
| Unsupported runtime and controls | The program fails on a new PC or after a Windows update |
| No source code or a lost copy | Nothing can be changed at all, even a VAT rate |
| Desktop only | No remote use, no mobile access, no integration with web tools |
| Knowledge in one head | Changes queue behind one person, or stop if they leave |
| Old database drivers | The data is hard to reach from anything modern |
The more immediate cost is what the business cannot do. You cannot connect the program to your online shop, your CRM or your accounts package, so people retype between them. Every new idea gets the same answer: the system will not let us.
How we replace it
We start from the code, not from a wish list.
- Source recovery. We locate the VB6 project files. If only the compiled EXE survives, we can still recover a lot from the database structure, the forms and decompiled logic, though it is slower.
- Rule mapping. We read the code module by module and write every business rule as a plain statement with the line it came from. You confirm which ones are still wanted.
- Data access first. Most VB6 systems sit on Access, SQL Server or an older database engine. We put a modern API in front of that database so new tools can read and write the data before any screen is rebuilt.
- Rebuild in slices. We rebuild one area at a time as a web application, starting with the part that causes the most pain or blocks the most work. Each slice is tested against the rule list.
- Side by side. The old program keeps running for the areas not yet replaced. Staff move over a piece at a time, so there is no single frightening switch-over day.
- Retirement. When the last slice is live, the VB6 program is archived along with a copy of its source and database, in case anyone needs to check historic behaviour.
Automated conversion tools that claim to turn VB6 into .NET do exist. They can help with a first pass on some projects, but they tend to carry the old structure and its problems forward, so we treat them as a reference rather than the answer.
After the switch
Staff work in a browser from any machine. The pricing, numbering and validation rules still behave the way they did, because they were written down and tested one by one. New PCs no longer need a technician with a folder of old installers.
Because the data now sits behind an API, the systems around it can finally connect. Orders from the website can land in it directly. Invoices can go to Xero or QuickBooks without being retyped. That is often where the real day-to-day change is felt.
Is this your situation?
- A core program was written in VB6 and still runs daily work
- New PCs need special steps or old components to make it start
- Nobody is fully sure what rules are inside the code
- The source code is on one old machine, or might be missing
- You retype data between the program and newer tools
- Every Windows update comes with a small worry