VB6 and Legacy .NET Modernization

Why VB6 and .NET Framework apps are still running

Many companies still run order entry, production scheduling or claims processing on a Visual Basic 6 desktop app written in the late 1990s, or on a .NET Framework app from the 2000s. They keep running because they work. The rules inside them reflect years of real cases, and the people who use them every day are fast with them. Tepia starts modernization by respecting that, not by declaring the old system broken.

The risks build up around the edges. The VB6 development environment has been unsupported since 2008, so every change depends on an old virtual machine and a developer who remembers the language. Apps rely on 32 bit ActiveX controls and Crystal Reports versions from vendors that no longer exist, and each Windows update is a small gamble. On the .NET side, Web Forms never moved to modern .NET and WCF server support lives on only through the community CoreWCF project, so those apps stay tied to Windows Server, IIS and a framework that gets security fixes but no new features.

The people risk is often the biggest. When the one developer who understands the code base plans to retire, the business suddenly has a deadline it did not choose.

Modernization paths by starting point

Tepia chooses a target per module, not per application, because one legacy system often contains several of these patterns at once:

The choice between a web front end and a modern desktop app depends on who uses the system. Plant floor stations with barcode scanners may stay on the desktop, while sales and management screens move to the browser.

Replacing an old app one module at a time

Big bang rewrites of legacy systems have a poor track record, because the old app keeps changing during the rewrite and the new one inherits none of the hidden rules. Tepia uses an incremental approach often called the strangler pattern. A routing layer, such as a YARP reverse proxy for web apps, sends each page or screen to either the old or the new code. One module is rebuilt, tested against the old behavior and switched over, then the next one starts.

Characterization tests make this safe. Before rewriting a module, Tepia captures its actual outputs for a large set of real inputs, including the odd cases, and runs the new code against the same set. Differences are either bugs in the new code or long standing bugs in the old code that you decide whether to keep. Microsoft’s .NET Upgrade Assistant speeds up mechanical project conversion, but business logic is rewritten and reviewed by people.

Opening the modernized app to other systems

Older applications usually exchange data through nightly flat files, shared database tables or an FTP folder. As modules move to ASP.NET Core, Tepia exposes them through documented REST APIs, so your CRM, ERP, ecommerce site or mobile app can read and write data directly. Events such as an order approved or a job closed can publish to a queue like Azure Service Bus or Amazon SQS, letting other systems react without polling.

Authentication moves too. Windows integrated login inside the office becomes single sign on through Microsoft Entra ID or Okta, which also lets remote staff and partners use the new web screens. Our API development and integration and event driven integration pages describe that work in more depth.

How Tepia approaches VB6 and legacy .NET modernization

Tepia maps its six phase process onto release waves, so each group of modules goes through the full cycle under one US based project manager.

1. Discovery: a code inventory covering forms, modules, COM references, third party controls, database calls and reports, plus interviews with power users and any original developers. Deliverables are an Investigation Summary with a dependency map, an Interview Summary and User Stories for each module.
2. Design: a design questionnaire, moodboards, a style guide and wireframes that keep the keyboard shortcuts and dense layouts power users rely on while fixing screens that confuse new hires.
3. Development and Testing: characterization tests first, then module releases on an Alpha and Beta schedule, with functional, user acceptance and performance test plans for each module.
4. Training: short sessions as each module switches, so users learn in small steps rather than all at once.
5. Launch: module by module cutovers, data migration where schemas change, and final retirement of the old executable and its installer.
6. Support: issue resolution, bug tracking and a plan for moving to each new .NET long term support release.

Typically Discovery runs 1 to 3 months, development and QA 2 to 6 months per release wave, and each launch about a month, with larger systems split into several waves. See our process.

Rewrite, convert or leave it alone

Automated conversion tools can translate VB6 into C# or VB.NET, and they help with large code bases full of simple forms. The output often mirrors VB6 patterns that are hard to maintain, so Tepia uses conversion selectively and rewrites the modules where business logic lives.

Leaving an app alone is sometimes right. If it runs on an isolated network, changes rarely and has a developer who will be around for years, Tepia may recommend documenting it, adding tests and putting an API in front of it instead. A rewrite becomes the better call when security reviews flag the platform, the app blocks remote or mobile work, or the knowledge is about to walk out the door. Read rebuild or refactor your app and how to choose a legacy modernization partner, browse our work, then talk to Tepia.

Frequently asked questions