Inventory management system in Visual Basic

The key facts

• The honest technical take: VB (classic or .NET) can express the movement-based design fine — the language is not the risk; the ecosystem around it is.
• Classic VB6 is a legacy platform: unsupported runtime territory, 32-bit assumptions, and a shrinking pool of developers who will touch it.
• VB.NET is a supported .NET language — a legitimate choice with the same design obligations as any stack: movements, derived quantities, transactional integrity.
• The decision frame: inherit-and-maintain, rewrite, or adopt — the build-vs-buy arithmetic prices the first two against the third.
• Context: the full inventory system holds the wider system, this page one stop in it.

Classic VB6 and VB.NET are different decisions

Visual Basic 6 — the source code most such searches find — lives on 32-bit assumptions and a runtime Microsoft supports in compatibility mode only. A VB6 inventory system can keep working for years (they famously do), but every year adds risk: no supported modern tooling, a developer pool limited to those who remember the quirks, and integration surfaces (accounting handoff, APIs, web) that expect modern platforms. Inheriting a working VB6 system is a legitimate short-term position and a poor long-term one; the rewrite conversation should start before the system forces it.

Visual Basic .NET is a different case: a supported, first-class .NET language. A VB.NET inventory project carries the same design obligations as any stack — the append-only movement table, derived quantities, transactional allocation — and the same framework ecosystem as C#. The honest critique of a VB.NET build is not the language but the tail: someone owns the hosting, patches and every future requirement, forever.

Evaluating inherited VB source code

Find the stock model first. Movements with derived quantities, or editable totals typed into a grid? The answer predicts the system's trustworthiness — the schema reasoning applies to 1998 code exactly as to today's.

Map the integration points. How do invoices reach the accounting system, and how much re-keying does the seam involve? Legacy integrations are usually manual exports, which means the record drifts from the books monthly.

Price the maintenance honestly. Who can still read the code, what does their hour cost, and what happens the month they are unavailable? Developer availability is the real legacy-language risk — the code does not rot, but the pool of maintainers does.

Check the data's exit path. Whatever you decide, the movement history must be exportable. A record locked in a dead platform is a hostage situation waiting for the deadline.

The three honest paths

Inherit and maintain — rational short-term if the model is movement-based and a maintainer genuinely exists; set a review date. Rewrite — port the data model to a modern stack, keeping the movement discipline that made the old system useful; the schema migrates far more easily than the forms. Adopt — replace the homemade record with a maintained one. We build BSimple, so weigh that: the same conceptual model — live multi-location stock, purchasing, portals, invoicing to Xero or MYOB (US integrations rolling out) — as cloud software from $180/month AUD, with the trial as the full product and the public REST API available if the VB system's custom logic deserves a modern home beside a maintained record. The spreadsheet-and-macro cousin of this route carries the same decision frame at smaller scale.