Your VB6 application still runs. That is probably why it has survived this long.
The problem is usually not the executable itself. It is the developer who has left, the ActiveX controls nobody wants to touch, the old database connection, or the next Windows change that nobody wants to test.
We start with the application you have and work out what should stay, what should move and what actually needs to be rebuilt.
You might recognise one of these:
You do not need somebody to tell you that old software is old.
You need to know what can safely remain and what the sensible migration path looks like.
Microsoft continues to provide compatibility support for the core VB6 runtime on supported versions of Windows.
The VB6 development environment itself has not been supported since 2008.
That distinction matters.
An existing application can continue running while becoming increasingly difficult to maintain because the source, build environment, ActiveX controls, integrations and people who understand it are disappearing.
That is the risk we assess.
1
Sometimes the right answer is not an immediate rewrite.
We can document the application, recover the build process, identify external dependencies, test it on a supported Windows environment and fix the highest-risk areas.
That can buy the business time to plan properly.
2
The core application may continue doing its job while new integrations, APIs or services are built alongside it.
That can reduce risk by moving one function at a time instead of replacing everything in a single release.
3
When the VB6 interface and codebase have become the constraint, we can rebuild the application on modern .NET while retaining the business rules and data that still matter.
A rewrite should replace the technology, not rediscover twenty years of business logic from scratch.
We start with the system rather than a preferred destination.
We look at:
From that assessment we can recommend whether to stabilise, integrate around or replace the application.
A business-critical system usually cannot disappear for six months while its replacement is built.
Where practical, we migrate in stages.
Data can move first. New APIs can sit beside the existing application. Individual workflows can move to a web application while the remaining VB6 screens continue operating.
The final cutover happens when the replacement has been tested against the real business process.
CoSource has worked with Microsoft business applications across older and current generations of .NET technology.
We work with applications that businesses still depend on, not just greenfield systems.
We will not prescribe a rewrite before seeing what you have.
CoSource is led from Sydney and works with Australian organisations on business-critical software.
You do not need a complete technical specification.
A few basics are enough:
Thirty minutes. Bring the application name, what it does and whatever source or documentation you still have.
We will tell you whether to stabilise it, modernise it in stages or replace it.
Book a free 30-minute discovery call