Replace your Visual Basic application with modern software
VB6, VBA and classic ASP still run every day at hundreds of Dutch companies. These applications have served faithfully, often for more than twenty years. But the Visual Basic 6 IDE has been officially out of support since 2008, the runtime receives only "best-effort" support on Windows 11, and the pool of developers who still know VB6 and COM shrinks further each year. We replace your Visual Basic application with a maintainable web application or desktop app, preserving all business logic and data.
VB6 is officially obsolete: what does that mean for your legacy application?
Visual Basic 6.0 was released in 1998 and for years was the quickest way to build Windows applications with forms, databases and COM components. But that era is over. Microsoft ended mainstream support for the VB6 IDE in 2005, followed by extended support in 2008. Since then, only the runtime has been shipped with Windows, and even that with increasingly clear disclaimers.
What the official status actually means
- ! VB6 IDE: end-of-life since 2008, with no patches, no security fixes and no MSDN support. The MSDN archive is read-only.
- ! VB6 runtime on Windows 11/12: best-effort, Microsoft still ships MSVBVM60.DLL, but offers no functional guarantees across feature updates.
- ! VBA receives less attention, Office continues to support VBA, but Microsoft is actively steering users towards Office Scripts (TypeScript) and Power Automate as successors.
- ! 32-bit only, VB6 binaries run only in 32-bit; on fully 64-bit Windows environments they require a WoW64 compatibility layer.
The silent risk stack
- ! Hardware driver incompatibility, old COM add-ins for scanners, weighbridges, cash drawers and barcode printers no longer work with modern USB stacks or TWAIN versions.
- ! Shortage of developers: people who understand VB6, COM and ADODB.Recordset are retiring. Finding a replacement through a recruitment agency is now almost impossible.
- ! No more security patches: known vulnerabilities in MSCOMCTL.OCX, Crystal Reports controls or older ActiveX components are no longer being patched.
- ! Audit pressure: ISO 27001, NIS2 and SOC 2 audits classify unpatched runtime components as a compliance risk.
In practice: while your VB6 application keeps running, little seems amiss. The pressure only becomes acute once Windows ships a breaking change, a COM control stops registering, or the last person with VB6 knowledge leaves. At that point, a calm migration project is no longer an option. We help you replace it before that moment arrives. For the wider context of legacy modernisation, see our page on replacing legacy software.
6 reasons to replace your Visual Basic application now
No migration project is cheap. But with VB6 and VBA, the clock is ticking. These are the six most common triggers that lead our clients to decide on replacement.
Runtime unstable on Windows 11/12
Windows feature updates can break MSVBVM60.DLL, OCX controls or the IDE. You no longer have a contractual right to a fix. What works today may stop working after the next KB update.
Shortage of VB6 expertise
Developers who still work fluently in VB6, with COM/OLE and manual ADODB recordset management, are retiring. Finding a successor through a standard job advertisement has become virtually impossible in 2026.
Security: no more patches
Known CVEs in older ActiveX controls, Crystal Reports versions or MSCOMCTL.OCX will no longer be fixed. For NIS2, ISO 27001 and BIO projects, an unpatched runtime is a red flag.
Hardware and drivers no longer cooperate
VB6 applications often rely on COM add-ins for specific hardware: scanners, cash drawers, barcode printers, weighbridges, RS-232 terminals. Modern 64-bit Windows with USB stack updates breaks those TWAIN or SerialPort integrations. A fix is no longer available from the original vendor.
No browser, no mobile, no cloud
VB6 applications are fat clients with a Windows installation on each workstation. Remote workers, field engineers, warehouse staff using a tablet, or customers who need to log in themselves cannot reach the application without a VPN, RDS or Citrix, and that feeds through into licence costs.
Integrations with modern SaaS get stuck
REST/JSON, OAuth 2.0, webhooks, GraphQL, JWT tokens: the standard vocabulary of modern SaaS. VB6 speaks it through middleware or not at all. If you want to integrate with a new accounting package, CRM, e-signing platform or invoicing portal, the project stalls because the VB6 side cannot keep up.
Our migration approach: code archaeology through to parallel run
VB6 projects are rarely well documented. The original builder has usually left, the business logic is scattered across Form events, modules and dynamic SQL built through string concatenation. Our approach is therefore always reverse-first: we first understand, then we rebuild.
Code archaeology
We take the VB6 project files (.vbp, .frm, .bas, .cls), inventory all Form events and module functions, and map which COM references are active. We count Form_Load and _Click handlers, locate all GoSub/GoTo spaghetti, and flag the On Error Resume Next blocks that silently swallow errors. Everything goes into a readable inventory report.
Business logic extraction
Beyond the visible forms, the business value lies in the calculations, validations and workflows. We extract that logic, document it in pseudocode or TypeScript, and validate it against production data. Only what is demonstrably working and in use is carried over; dead code stays behind.
COM dependency inventory
Which OCXs, type libraries and COM/OLE servers does your application use? Crystal Reports version, MSCOMCTL, ADODB, MSXML, RDO, legacy DAO 3.6: we map a complete dependency graph and determine, for each item, whether to replace it, flatten it or build a runtime shim.
Parallel run and data migration
The new application runs alongside the old one for several weeks. Users enter data into both systems, or the old one is mirrored to the new one nightly. Only once the discrepancy is zero and users are confident does the old application get switched off. MDB or ACCDB files are migrated to PostgreSQL or SQL Server using a validated transformation.
For clients with a Microsoft Access front end on a shared MDB, we often work in two stages: first replace the back end (see replacing an Access database), then the VB6/VBA front end. This lowers the risk and spreads the investment.
What we replace: forms, controls, data access and reporting
A VB6 application consists of a number of fixed components. For each one, we have a modern equivalent ready.
Forms and controls
.frm files with TextBox, ListBox, DataGrid, MSFlexGrid, DTPicker and all their custom OCX extensions are replaced by React or Blazor components with the same layout, validations and keyboard shortcuts. Speed and keyboard-driven operation remain, because cashiers and planners often work only with the keyboard.
VBA modules and COM add-ins
VBA macros in Excel or Word, COM add-ins for Office and home-built .DLLs in VB6 or VC++: we extract the logic, rewrite it in TypeScript or C#, and host it on a server. Office integration can be handled via Office Scripts, Microsoft Graph or a custom API.
DAO/ADO data access
ADODB.Recordset, DAO 3.6 on MDB files or direct ODBC connections with inline SQL: we replace the entire data layer with an API using parameterised queries, prepared statements and an ORM such as Prisma or Entity Framework. SQL injection through string concatenation disappears and transaction management becomes explicit.
Crystal Reports and reporting
Crystal Reports 8/9/10/11 reports, Active Reports, or home-built Print routines on a Form: we convert the output to modern PDF rendering (Puppeteer, wkhtmltopdf, Microsoft Reporting Services), interactive dashboards (Metabase, Power BI Embedded) or a clean HTML print view. Layout pixels stay identical where needed for compliance or client documents.
Hardware integrations
Barcode scanners, cash drawers, weighbridges, RFID readers, label printers (Zebra, Honeywell), TWAIN scanners, RS-232 terminals: we reconnect them via WebUSB, WebSerial, a local device agent or an MQTT broker on a Raspberry Pi gateway. That way your industrial app keeps running without depending on 32-bit OCX controls.
Typical VB6 applications we replace
Three use cases we frequently encounter, with the choices we make in such a project.
Industrial app on the shop floor
A VB6 application on an industrial PC in a production hall, connected to a SCADA system, weighbridge and MES database. Replaced by an Electron app or Progressive Web App with a local device agent (Node.js or Rust) that handles serial ports and MQTT topics. Front end in the browser, back end on a local Linux server, replicated to Azure or AWS for management reporting.
Checkout and order-entry system
VB6 on a Windows point-of-sale terminal with OCX controls for the cash drawer, receipt printer and card terminal. Replaced by a browser app on Chrome OS Flex or Windows IoT, with WebUSB for the card terminal integration, an ESC/POS receipt printer via a local agent, and a central REST API for stock and payments. Offline-first with Service Workers, so the till keeps working during an internet outage.
Production planning and order management
VB6 front end on a shared Access MDB, used by planners and production preparation. We first replace the back end with PostgreSQL or SQL Server (see bespoke ERP system), then the front end with a React application featuring real-time updates via WebSockets. Planning, order intake, capacity overviews and exports to Excel or the ERP remain familiar to users.
Back-office financial administration
VBA macros in a large Excel file with formulas, links to SQL Server and automated reports to the accountant and management. We recode the logic into a web app with explicit data typing, audit trails and role-based authorisation. To keep the Excel feel, we retain keyboard controls and spreadsheet grids with copy-paste support. Read more about building custom software for the wider context.
Visual Basic 6 versus a modern web application
| Aspect | Visual Basic 6 / VBA | Modern web application |
|---|---|---|
| Microsoft support | IDE end-of-life since 2008, runtime best-effort on Win 11/12 | Actively maintained frameworks (React, .NET, Node) |
| Workplace | Windows-only, fat client per PC, 32-bit | Browser, mobile, tablet, laptop, kiosk |
| Data layer | DAO/ADO with inline SQL, prone to injection | API with parameterised queries and an ORM |
| Error handling | On Error Resume Next makes errors invisible | Try/catch with central logging and alerting |
| Deployment | Setup.exe per workstation, COM registration required | Browser load or CI/CD deployment, no client installation |
| Auditability | No built-in audit log, often manual | Audit trail per record, NIS2/ISO 27001-ready |
| Talent | Scarce, average age over 50 | Readily available in the Netherlands |
Frequently asked questions about replacing VB6 and VBA
On Windows 11, MSVBVM60.DLL is still present and most VB6 applications start without problems. However, Microsoft classifies runtime support as "best-effort" — no contractual guarantee, no security fixes for the IDE components, and specific OCX controls may break with Windows feature updates. Nothing has been committed for Windows 12 at the time of writing. For business-critical applications, that is too thin a foundation.
We first establish which version you run (Crystal 8.5, 9, 10, 11, XI or newer) and which data sources it touches. We then decide per report: convert to PDF rendering with Puppeteer or wkhtmltopdf, rebuild as an interactive dashboard in Metabase or Power BI, or move to server-side reporting via Microsoft Reporting Services. Layout fidelity is preserved where it matters for customer documents or compliance, and kept simpler where it can be.
Yes. Business logic extraction is the core of our approach. We read through the VB6 code line by line, document the logic in pseudocode or TypeScript, and validate the outcomes against production data. MDB or ACCDB databases and SQL Server tables are migrated using a validated transformation and sample checks. During the parallel run, old and new systems operate side by side until the outcomes are identical.
That's more the rule than the exception. Our code archaeology phase is designed precisely for this: we open the .vbp, .frm, .bas and .cls files, map all Form events and module functions, trace COM references, and build readable functional documentation from them. We then interview the end users to establish what is actually used in practice and which edge cases they are aware of.
Yes. We usually replace VBA macros in Excel or Word with a web application, or with an Office Script (TypeScript) when the workflow needs to stay within Office. For VBA in Microsoft Access, we first check whether we can decouple the Access back end (see our Access database replacement page). We then replace the Access front end with a browser-based application with the same forms and reports.
For modern hardware, we use WebUSB or WebSerial in a Chrome or Edge browser. For older peripherals, we install a local device agent (Node.js, .NET or Rust) that runs on the Windows or Linux workstation and serves the browser via a local WebSocket or REST endpoint. For industrial environments, we often place an MQTT broker on a Raspberry Pi or industrial gateway in between, so the browser app stays stateless.
Yes. We always work with a parallel run. Your existing VB6 application stays live until the new application has been fully verified. We synchronise data nightly or in real time, users practise in the new environment, and only once everything is green do we switch off the old application. No big-bang go-live where everything can go wrong at once.
By default, React or Next.js for the front end, Node.js or .NET for the back end, PostgreSQL or SQL Server for the database, and Azure or AWS in a Dutch or EU data centre for hosting. We stay technology-agnostic where possible: if your IT department already manages .NET or Java stacks, we align with those. The guiding principle is that the new application must remain maintainable for ten years, with talent that is available in the Netherlands in 2026 and beyond.