VB6, MS Access and Classic ASP
Migrated to Modern .NET
Systems nobody left can maintain, running the business anyway. We migrate them incrementally — the existing application stays up while capability moves across, one section at a time. No big-bang rewrite, no eighteen-month freeze on everything else.
Who actually does this work: Genuinely old estates — VB6, MS Access, classic ASP — often can't be staffed at all. I've worked with .NET continuously since its first release, and where a system predates it, that work goes to a specialist I have worked with for years who still works in those environments. Between us, that's coverage from VB6 through to .NET 10. I architect and review every engagement personally either way.
The Problem Isn't the Code.
It's That Nobody Can Read It.
A VB6 or Access system that has run correctly for twenty years is not badly written. It is unstaffable, which is a different problem with a different solution — and rewriting it is usually not that solution.
The Hiring Market Has Closed
Nobody has entered the profession as a VB6 developer since before the current graduate intake was born. The people who can still work in it are retiring, and the ones who remain are not looking for a permanent role maintaining one internal system. This is not a rate problem you can solve with a bigger number.
The Business Rules Exist Nowhere Else
Two decades of process knowledge — every exception, every special case for one important customer, every rule someone added after an expensive mistake — lives in that code and in no document. That is exactly why a rewrite from a specification overruns: the specification is a summary of what people remember.
The Dependencies Are the Real Exposure
Third-party ActiveX and OCX controls are where these systems actually break. Microsoft does not support components it did not ship, the original vendors are frequently gone, and the control that renders your invoices is a binary nobody can rebuild. Cataloguing them is the first thing an assessment does.
Access Runs Out of Room, Not Time
An Access back end does not fail on a support date. It fails when the file hits its ceiling, when two people write at once over a flaky share, or when the one person who understands the linked-table layout leaves. There is no version upgrade that fixes a data store being asked to be a database server.
The Support Position, With Citations
Most of what circulates about these platforms is either alarmist or complacent. Here is the actual position, and a link to Microsoft's own documentation for each claim so you can check it rather than take our word for it.
- Visual Basic 6.0 IDE
The Visual Basic 6.0 IDE has been unsupported since 8 April 2008. Microsoft's own words: “there is no supported method to create or maintain Visual Basic 6 applications”, and it “strongly recommends that you replace your applications with modern technology”.
Microsoft VB6 support statement - Visual Basic 6.0 runtime
The VB6 runtime remains supported for the lifetime of supported Windows versions, but the support bar is limited to serious regressions and critical security issues for existing applications. It is 32-bit only, and on 64-bit Windows runs solely under WOW64 emulation.
Microsoft VB6 support statement - Classic ASP
Classic ASP is still supported on every supported version of IIS, and its support lifetime is tied to the host operating system rather than to a date of its own.
Microsoft ASP support statement - VBScript
VBScript — the language most classic ASP is written in — was deprecated in October 2023. Microsoft will ship it as a feature on demand before removing it from Windows entirely.
Microsoft deprecated Windows features - Microsoft Access
An Access database is capped at 2 GB minus system objects, with a documented maximum of 255 concurrent users.
Microsoft Access specifications - .NET 10
.NET 10 is the current Long Term Support release. Microsoft supports it until 14 November 2028.
Microsoft .NET support policy
Every date above links to Microsoft's own documentation. Check them — that is what they are there for.
Doing Nothing Is a Decision.
So Is Rewriting.
The runtime being supported is not the same as the system being safe. What actually ends these systems is the hiring market, the unsupported third-party control, the 32-bit-only constraint, and the fact that any change at all is now a research project. But the answer is almost never to rebuild from scratch: a rewrite means re-deriving twenty years of business rules from a specification nobody wrote, while the business waits. We migrate incrementally, capability by capability, with the existing system serving users the whole time — and the old path stays reachable until the new one has been boring for a while.
A system that has run correctly for twenty years has survived real-world chaos that no new build has been tested against yet. That deserves respect, and it is an argument for moving it carefully rather than replacing it.
Incremental, With the Old System Still Running
The same method whatever the source platform. The point of every step is that it is reversible, and that the business never waits for the whole thing to finish.
Catalogue Before Anything Else
Every form, module, report, query and dependency, including the third-party controls that will decide how hard this actually is. You cannot plan a migration whose inventory you do not have, and this is the step vendors skip in order to quote faster.
Move the Data First
Access or Jet to SQL Server, with the schema straightened out on the way rather than reproduced faithfully. The legacy front end keeps working against the new database through linked tables or an updated connection, so this step delivers value before any UI has changed.
Extract the Business Rules
The logic buried in form event handlers moves out into a .NET service layer with tests around it. This is where the twenty years of accumulated knowledge gets preserved — read out of the code that has been running it, not reconstructed from a workshop.
Route Section by Section
For classic ASP especially: a reverse proxy in front of the estate sends one section to the new .NET application while everything else still reaches the old one. Users meet one new screen at a time instead of one new system on one Monday.
Replace the Interface
VB6 forms and Access forms become a modern web front end — or stay as a desktop application where that is genuinely the right answer for people using it on a shop floor. The stack follows the users, not our preferences.
Decommission Last
The legacy path stays live and reachable until the new one has been in production long enough to be dull. Rollback is a routing change rather than a restore from backup, which is the entire reason for working in this order.
Legacy Estates Changed Without Stopping the Business
We have not published a VB6 migration case study yet, and we are not going to imply one. What we can show is the harder half of the skill — changing old systems that a business is actively running on, which is what a migration of this kind actually consists of.
Changing a System That Cannot Stop
New carrier data feeds in the PNRGOV and PAXLST formats, plus watchlist connectors, integrated into a border-security platform while agencies in other member states screened live traffic on it. Changing a system that cannot pause is the constraint every legacy migration shares.
.NET · PNRGOV / PAXLST (UN EDIFACT) · IIS
Extending a Live Retail Back Office
Stock-take, supplier promotion downloads and shelf-edge labelling added to a production EPOS system while independent retailers kept trading on it. New capability, with existing muscle memory left intact.
.NET · SQL Server · EPOS integration
Production ASP.NET WebForms
A statutory body's petitions portal built and run on ASP.NET WebForms. We have shipped the older Microsoft web stack in anger, which is why we can tell you honestly what moving off one involves.
ASP.NET WebForms · SQL Server
What an Assessment Produces
Two weeks, fixed price, and a document your team owns whether or not you engage us for the migration itself.
Inventory & Dependency Map
Every form, module, report and query, and — the part that decides the difficulty — a named list of third-party ActiveX and OCX dependencies with a supported replacement identified for each, or flagged where there isn't one.
Business Rules Extracted
The rules the system actually enforces, read out of the code and written down. On its own this is often worth the fee: it is the documentation that has never existed, and it survives whatever you decide to do next.
Risk Register
Named, specific exposure rather than general warnings: unsupported components, the 32-bit and WOW64 constraint, single points of failure, data-integrity risk, and what happens to each of them if you do nothing for another two years.
Phased Plan & Costed First Step
The order to migrate in, sized per phase with the assumptions shown so your engineers can challenge them, and a fixed-scope quote for phase one. Each phase leaves you with a working system.
What We Migrate From, and To
The pre-.NET platforms come through a specialist engaged for the work; everything from .NET 1.1 onwards is Anil's own ground. Both halves are stated plainly because the difference matters to you.
Find Out What Is Actually In There
Before anyone can tell you what a migration costs, somebody has to open the system and count. Two weeks, fixed price, and you own the document either way — including the business rules nobody has ever written down.
Is Your Business Running on Something Nobody Can Maintain?
Tell me what the system does, roughly when it was built, and what is prompting the question now. Forty-five minutes, no charge, and a written summary afterwards — including if my honest answer is that it can safely wait another year.