Visual Basic 6 Migration & Support
for businesses in Australia, New Zealand, the UK and the US.
The VB6 development environment has been unsupported since April 2008. The runtime still ships with Windows, so the applications keep working and the decision keeps getting deferred.
- Independent No licence commission, no reseller agenda
- 18+ yrs Building business software
- Fixed Price scopes, no surprises
- AU NZ UK US Perth-based, working remotely
Eighteen years unsupported, and still running payroll
Visual Basic 6 built an enormous amount of Australian business software between 1998 and 2005. Microsoft has kept the runtime working on every version of Windows since, which is generous and also the reason nothing forces a rebuild. The IDE itself is another matter: installing it on a current machine is an exercise in patience, and finding somebody who will is harder.
The applications we are asked to look at are usually stock control, job costing, quoting or membership systems. They work. They just cannot be changed any more.
Your VB6 project, end to end
Three stages. Scoped and fixed-price before anything starts, delivered by the founder, and your existing system stays running until cutover.
-
Week 0
Read the system as it is
We go through the existing application and record what it actually does, including the parts nobody documented. You get a written inventory and a fixed price before any build starts.
-
Weeks 1-N
Rebuild and run in parallel
The replacement runs beside the original until the numbers reconcile. The old system stays untouched and switched on the whole time.
-
Cutover
Go live and hand over
Cutover on a date you choose, then thirty days of support. Source code, documentation and credentials are handed to you, in your name.
What the work actually is
The same application, on something that can be maintained
We read the .frm forms and the module code, map out the workflow, and rebuild it on a current stack. Where a third-party OCX control is doing something odd, we replace the behaviour rather than the control.
What you have now
- .vbp projects and .frm forms
- ActiveX and OCX controls
- Access or SQL Server back end
- Crystal Reports output
The same application, on something that can be maintained
We read the .frm forms and the module code, map out the workflow, and rebuild it on a current stack. Where a third-party OCX control is doing something odd, we replace the behaviour rather than the control.
See how a project runsWhat you end up with
- A web application with the same screens and the same workflow
- The database kept or moved, whichever is less disruptive
- An application that can actually be modified again
The 5 pieces of VB6 work we are asked for
Most engagements are some combination of these, and most start with the first.
Work out what it does
Forms, modules, class files and the database schema documented, including the business rules buried in event handlers.
Deal with the dependencies
ActiveX and OCX controls are the usual blocker. We identify what each one does and replace the behaviour with something supported.
Rebuild as a web application
Same workflow, same field names, same order of operations, so your staff are not retrained from scratch.
Move or keep the database
If it is already SQL Server it usually stays. If it is Access, that is a second problem and we handle it at the same time.
Rebuild the reporting
Crystal Reports output reproduced and reconciled, because that is what the business checks first.
Where you are now
It works, and nobody will touch it
- The IDE has been unsupported since April 2008
- Nobody will install VB6 on a current machine to make a small change
- ActiveX and OCX dependencies break on new Windows builds
- Any change at all is quoted as a full rewrite by everyone you ask
After
Supported, documented and yours
- A codebase any current developer can read and modify
- No dependency on controls that stopped shipping twenty years ago
- Runs in a browser, so remote and multi-site work stops being a problem
- Small changes become small changes again
Scoped and quoted before you commit. You own the code, the documentation and the credentials at the end of it.
Get a fixed-price scopeVB6 questions
Can VB6 code be converted automatically?
Partly, and we generally do not recommend leaning on it. Automated converters produce something that compiles and nobody understands, which trades one unmaintainable system for another. We read the original and rebuild the behaviour deliberately.
Our VB6 app uses ActiveX controls nobody sells any more. Is that fatal?
No, it is normal. Those controls are usually doing something ordinary such as a grid, a date picker or a report preview. We identify the behaviour and reproduce it with something current.
Does it have to become a web application?
No. A web application is the usual answer because it removes the deployment problem, but if the work genuinely suits a desktop application we will build one and say why.
How long does a VB6 rebuild take?
It depends entirely on the number of screens and the amount of logic hidden in them. We scope it first and quote fixed-price, so you get a number before you commit rather than an hourly rate and a hope.
Can you support it while we decide?
Yes. Keeping a VB6 application alive is a legitimate holding position and we will do it. It does not remove the risk, but it stops the decision being made for you in a crisis.
Sending your details…
You can stay on this page while we send it.
Tell us what you are running
What the system does, roughly how old it is, and what is forcing the question. We will come back with a straight answer and a fixed-price scope, even if the answer is to leave it alone.
Prefer a quick chat? Call 0425 531 127. We answer the phone in Perth.
