Migrating Legacy Code: Why You Should Move from VB6/AutoLISP to C# .NET

Many engineering organizations still depend on applications, CAD utilities, and automation tools written years or even decades ago in Visual Basic 6.0 (VB6) or AutoLISP.

And in many cases, those applications still work.

So why replace them?

The real issue is not whether legacy code can continue running today. The question is whether that code can continue supporting your business as CAD platforms evolve, workflows become more connected, developers change, security requirements increase, and engineering automation becomes more sophisticated.

For applications that have grown beyond simple scripts and utilities, migrating from VB6 or AutoLISP to C# .NET can provide a stronger foundation for maintainability, CAD integration, application architecture, testing, deployment, and future development.

At ProtoTech Solutions, we bring 20+ years of experience in the CAD/CAM and engineering software industry, helping organizations develop, modernize, integrate, and automate engineering applications across complex design environments.

Let’s explore when migrating legacy code makes sense, what C# .NET offers, and how to approach migration without disrupting critical engineering workflows.

Why Are Companies Still Using VB6 and AutoLISP?

Legacy software often survives because it solves real business problems.

An AutoLISP routine may automate hundreds of repetitive drafting operations every week. A VB6 application may contain years of engineering calculations, configuration rules, drawing generation logic, or integrations that employees rely on every day.

Replacing something that already works can therefore appear unnecessary.

But legacy applications gradually become harder to maintain when:

The original developers are no longer available.
New developers struggle to understand undocumented code.
CAD software versions change.
Operating systems or external components are upgraded.
Applications need modern user interfaces.
New APIs, databases, cloud services, or web applications must be connected.
Small modifications require disproportionately large development effort.
Testing changes without breaking existing behavior becomes increasingly difficult.

Is VB6 Really a Legacy Technology?

Yes.

Microsoft states that the Visual Basic 6.0 IDE has been unsupported since April 8, 2008. There is no supported way to create or change apps with it. Microsoft tells users to move to new tools like .NET. Windows continues to provide support for selected VB6 runtime components primarily to maintain compatibility with existing applications, but the development environment itself is no longer supported.

This creates an important distinction.

A VB6 application continuing to run does not necessarily mean VB6 remains a good platform for developing the next generation of that application.

Organizations maintaining large VB6 applications may increasingly face challenges related to development tooling, third-party dependencies, ActiveX/COM components, developer availability, testing, deployment, and integration with modern systems.

For business-critical applications expected to evolve for many more years, migration becomes a strategic consideration rather than simply a code-cleanup exercise.

What About AutoLISP? Is AutoLISP Obsolete?

No. And this distinction is important.

AutoLISP is still actively supported within AutoCAD, and Autodesk continues to provide AutoLISP developer and reference documentation.

AutoLISP remains highly useful for tasks such as:

Automating repetitive AutoCAD commands
Manipulating drawing entities
Updating layers and properties
Creating drafting utilities
Processing blocks and attributes
Automating drawing standards
Building lightweight CAD productivity tools

For a small, focused automation routine, rewriting AutoLISP simply because C# exists may provide little business value.

The situation changes when a collection of scripts gradually becomes a large software application.

When an AutoLISP solution begins handling sophisticated engineering rules, multiple modules, complex interfaces, databases, APIs, configuration management, licensing, external applications, or enterprise workflows, C# .NET often becomes the more appropriate architecture.

So the question should not be:

“Should all AutoLISP be replaced?”

It should be:

“Has our automation outgrown AutoLISP?”

Why Move Legacy CAD Applications to C# .NET?

C# is a modern, object-oriented language within Microsoft’s .NET ecosystem, with features including strong typing, generics, asynchronous programming, pattern matching, and extensive development tooling.

For engineering software and CAD customization, these capabilities become particularly valuable as applications grow.

1. Build a More Maintainable Application Architecture

One of the biggest problems with legacy applications is rarely the programming language alone.

It is usually the architecture that develops around it.

Over years of modification, business rules, UI logic, CAD operations, file handling, and configuration code can become tightly coupled.

A C# .NET migration provides an opportunity to reorganize the application into clearer components such as:

Business logic
CAD integration
Geometry processing
Data access
User interface
Configuration
Logging
External service integrations

Instead of placing new code on top of old code indefinitely, teams can establish an architecture that is easier to understand and extend.

Modern .NET also supports architectural patterns and mechanisms such as dependency injection, which can help applications manage dependencies more cleanly.

2. Get Strong Access to AutoCAD’s Managed .NET API

For AutoCAD customization specifically, Autodesk provides a Managed .NET API that exposes AutoCAD functionality through .NET applications. Autodesk’s developer documentation includes support for building applications in C# and working programmatically with AutoCAD objects.

Through the API, developers can work with objects such as:

Lines, arcs, polylines, text, and dimensions
Blocks and block references
Layers and linetypes
Drawings and databases
Views and viewports
Documents
AutoCAD application-level functionality

Autodesk documents these objects through its managed object model.

For sophisticated CAD applications, this provides a structured programming model for developing larger automation solutions.

3. Improve Debugging and Error Handling

Anyone who has maintained a large legacy automation tool knows the difficulty of tracking an error buried inside thousands of lines of procedural code.

Modern Visual Studio and .NET development environments provide sophisticated capabilities for:

Breakpoint debugging
Exception analysis
Variable inspection
Call-stack analysis
Code navigation
Refactoring
Static analysis
Automated testing

This becomes especially valuable when an engineering application contains hundreds of business rules.

Better diagnostics mean developers can spend less time trying to determine where something failed and more time fixing why it failed.

4. Make Automated Testing More Practical

Consider a CAD automation application responsible for calculating:

Component dimensions
Placement coordinates
Clearances
Material quantities
Manufacturing parameters
Configuration rules

A change to one calculation can potentially affect many downstream operations.

With a properly designed C# architecture, the engineering calculation layer can be separated from CAD-specific operations and tested independently.

For example, instead of manually opening several drawings after every modification, developers can create automated tests covering known engineering scenarios.

That does not eliminate CAD-level testing, but it can significantly improve confidence when changing critical application logic.

5. Develop Better User Interfaces

Many engineering applications eventually need more than a command-line interaction or basic dialog.

Users may need:

Configuration panels
Property editors
Wizards
Preview windows
Searchable component libraries
Validation messages
Progress indicators
Interactive engineering forms
Dockable CAD interfaces

C# .NET can support richer desktop application interfaces and can also interact with web-based technologies where required.

This makes it easier to transform an internal utility into a polished engineering application that can be deployed to a larger user base.

6. Integrate CAD Applications with Other Business Systems

Modern engineering workflows increasingly extend beyond the CAD desktop.

A CAD application may need to communicate with:

ERP systems
PLM/PDM platforms
Product configurators
SQL databases
REST APIs
Cloud platforms
Document management systems
Web applications
Licensing systems
Manufacturing databases
AI/ML services

A C#/.NET architecture is well suited to building these integrations.

The result is that CAD automation no longer needs to remain an isolated desktop process. It can become part of a broader digital engineering workflow.

VB6 vs. AutoLISP vs. C# .NET: What Is the Difference?

Area	VB6	AutoLISP	C# .NET
Best suited for	Existing legacy Windows applications	Lightweight AutoCAD automation	Modern CAD and engineering applications
Current development ecosystem	Legacy	Actively supported for AutoCAD scripting	Modern and actively evolving
Application architecture	Limited compared with modern .NET	Primarily scripting-oriented	Strong object-oriented architecture
AutoCAD automation	Often COM-based	Excellent for many AutoCAD automation tasks	Comprehensive Managed .NET API
Large application maintainability	Increasingly difficult	Can become difficult at large scale	Well suited
Automated testing	More difficult	Possible but less natural for large systems	Strong ecosystem
Modern UI development	Limited	Limited	Strong
Database/API integration	Possible but legacy-heavy	Possible, but not ideal for complex integration	Strong
Enterprise application development	Limited	Best for focused CAD automation	Well suited

A well-designed CAD environment may continue using AutoLISP for small productivity scripts while moving larger, business-critical applications to C# .NET.

Should You Rewrite the Entire Application at Once?

Usually, no.

For a large engineering application, a phased migration strategy is often safer than a complete rewrite.

A practical approach can look like this:

Step 1: Audit the Existing Application

First, understand what the existing code actually does.

Document:

Commands
Engineering rules
Input/output data
CAD operations
External dependencies
COM/ActiveX components
Configuration files
Database connections
User workflows
Known limitations

The objective is to separate valuable business logic from obsolete implementation details.

Step 2: Identify High-Risk Dependencies

Legacy applications often depend on more than the source code itself.

Check for dependencies such as:

OCX controls
ActiveX components
COM libraries
Third-party DLLs
Registry settings
Old database drivers
Network paths
External executables

Removing or replacing these dependencies may be just as important as converting the programming language.

Step 3: Design the Target Architecture

Do not simply translate VB6 or AutoLISP line by line into C#.

That can reproduce the same architectural problems in a newer language.

Instead, identify logical layers such as:

UI → Application Services → Engineering Logic → CAD Services → Data/Integration Layer

This makes future changes much easier to manage.

Step 4: Separate Business Logic from CAD Logic

Suppose an application calculates the correct position of a component before inserting it into an AutoCAD drawing.

The calculation and the drawing operation should ideally be separate.

For example:

Engineering service: determines coordinates and dimensions.

CAD service: creates or modifies AutoCAD entities using those values.

This separation improves maintainability and makes engineering calculations easier to test.

Step 5: Migrate Module by Module

Start with a well-defined part of the application rather than replacing everything simultaneously.

For example:

Move engineering calculations.
Migrate configuration management.
Replace database integration.
Convert CAD commands.
Modernize the user interface.
Replace legacy deployment mechanisms.

Existing and modernized components may temporarily coexist while the migration progresses.

Step 6: Validate Against Existing Outputs

Legacy engineering software often contains undocumented knowledge.

That knowledge may exist in calculations, special conditions, exceptions, or seemingly unnecessary lines of code.

Before removing them, compare the new application’s results against known production cases.

For CAD automation, validation might include:

Entity positions
Dimensions
Layers
Blocks
Drawing properties
Engineering calculations
Generated files
User workflows

Migration should preserve proven business behavior unless that behavior is intentionally being changed.

Does Moving to C# Automatically Make an Application Faster?

Not necessarily.

Programming language migration alone should never be treated as a guaranteed performance optimization.

Performance depends heavily on:

Algorithms
CAD API usage
Database operations
File access
Network communication
Geometry processing
Memory management
Application architecture

C# does, however, provide a strong platform for structuring and optimizing complex applications and supports modern asynchronous programming patterns where they are appropriate. Microsoft’s C# documentation, for example, provides native Task, async, and await support for asynchronous application workflows.

The real objective of migration should therefore be better software engineering, not simply replacing syntax.

What About AutoCAD Version Compatibility?

This deserves particular attention during migration.

AutoCAD’s supported .NET environment can change between product generations. Autodesk publishes compatibility information for its Managed .NET SDK and recommends targeting the development environment appropriate for each AutoCAD release.

Therefore, a professional migration should consider:

AutoCAD versions that customers currently use
Target .NET runtime
AutoCAD Managed API compatibility
Required assembly references
Installation and plug-in bundle structure
Digital signing and trusted locations
Backward compatibility requirements

This is particularly important when developing commercial AutoCAD plugins used across multiple customer environments.

How ProtoTech Solutions Can Help Modernize Legacy CAD Applications

Migrating engineering software requires more than general application-development knowledge.

Developers also need to understand the behavior of CAD systems, engineering data, geometry, legacy APIs, and the workflows users depend on every day.

With 20+ years of experience in the CAD/CAM and engineering software industry, ProtoTech Solutions helps businesses modernize and extend engineering applications while protecting the domain knowledge already embedded in their existing systems.

Our development teams can assist with areas including:

VB6 to C# .NET migration
AutoLISP to C# .NET migration
Legacy CAD application modernization
AutoCAD .NET customization
CAD workflow automation
Engineering software development
CAD API integration
Desktop application modernization
Database and cloud integration
Plugin and add-in development
Legacy code assessment and architecture redesign

If your VB6 or AutoLISP application is becoming difficult to maintain, integrate, extend, or support, migrating selected functionality to C# .NET can provide a more sustainable foundation for future development.

Rather than treating migration as a simple code conversion exercise, we focus on understanding the existing workflow, engineering logic, dependencies, future requirements, and CAD environment before defining the modernization strategy.

Planning to modernize a legacy CAD or engineering application? Connect with our team and discuss how we can help you assess your existing VB6 or AutoLISP solution and build a practical C# .NET modernization roadmap.