Hello,

I have for a number of years supported a VB5 application which controls customers equipment. We are now going to do some major changes to software because hardware is changing. It now seems the ideal opportunity to upgrade to a newer/latest version of visual basic, which if we go the Microsoft route is part of Visual Studio.

First thoughts of mine suggest there are two ways of getting to latest version

1) rewrite in new version, using code from old version and converting appropiately

2) convert in steps via the various versions of VB, such that I pick the latest one that will convert existing version. For example probably convert to Vb6 first.

Has anyone else had this to do ? If so any tips please ?

Any other suggestions, different languages, other makes of VB, etc ?

Thanks

Denis

Dani AI

Generated

Several respondents recommended a straight move to a modern .NET rewrite instead of incremental upgrades. and emphasized using the old code as a logic map rather than converting it in-place; offered C# as a pragmatic alternative; warned about scope creep. The short summary below converts those high-level points into a compact, practical migration plan that reduces risk and preserves testability.

Practical checklist (rough order):

  1. Inventory everything: modules, native DLLs/OCXs, COM components, and any platform-specific API calls.
  2. Create a tiny hardware-abstraction interface that isolates transport and device protocol from business logic. Build the simulator as a second implementation of that interface so tests drive behavior.
  3. Port business logic next, keeping it pure and testable — enable strict typing (Option Strict On), remove global state, replace legacy error-handling with structured exceptions, and add unit tests.
  4. Handle native interop deliberately: prefer managed wrappers or recompiled native libs; if 32-bit natives are required, pin the target to x86; test marshaling and edge cases early.
  5. Replace or modernize the UI last and incrementally; keep feature-parity checks against the simulator and the original app.

Small technical example (interface pattern, VB.NET):

Public Interface IDeviceTransport
    Function Open() As Boolean
    Sub Close()
    Function Send(data() As Byte) As Integer
    Function Receive(timeoutMs As Integer) As Byte()
End Interface

Practical cautions and project controls: protect the specification (see ), include explicit change-order terms, and allow at least 1.5x the initial time estimate for unforeseen interop and testing work. Keep the original codebase as a reference implementation, drive acceptance with simulator-based tests, and use incremental milestones so regressions are found early. This approach preserves the original logic, improves maintainability, and contains scope risk.

Recommended Answers

All 10 Replies

Having dealt with such before. It's all up to the client what they want. For me I made the leap over to C# since I wanted to move away from VB6 and prior. It also made deployment easier.

I moved straight to the newest version of vb.net. Especially the API calls were a headache foe me. Got rid of these now as they were always a problem (16 bit to 32 bit to 64 bit). I think you also might save time moving to vb.net and learning at the same time.

If the orginal code was well written and is easy to maintain I would use it as a map to rewrite in vb.net using logic flow as a guide. I would not move to vb6 first.

Move immediately to the latest version and skip the in betweens. It would be a great waste of time to do so.
Make use of the oportunity to make some improvements here and there.
Don't underestimate this, it will take longer than you expected.
Success!!

Thank you for your replies, you confirmed my thoughts - go straight to new version. I have now installed Visual Studio 2015 (community edition) which is free for sole developers, like myself. It also gives opprtunity to modernise the look and feel, not that it looks particuly old. The board will use USB rather than serial,
plus differnt command to do what it currently does.

So a big learning curve - what fun.

They now want a fixed price for doing it. My gut feel says it will take me six months to do, working 3 days a week. As one post says it will take longer than one thinks. Thay are suplying a simulator for me to use, so I cn stay at home and work.

Success!
An other one of my experiences is if I thought a project would take 1 month, it took at least 2 months. But that was in the previous century. With the development tools now available, it shold ease the process.

At some point the people/person asking for the conversion will almost certainly come to you with a statement that begins with "As long as you are rewriting it you might as well...". This is known as scope creep. They will assume that as long as you are rewriting it will take zero (or minimal) extra effort to add features. If your response is

No problem

then you may safely consider yourself a moron. Instead, your response should be to state that the specification was frozen at the time you accepted the conversion project. Any requested changes would immediately render that contract null and void. If the changes are truly minimal they can be made at the end of the project and classified as a new project. Once you accept changes to an existing project you will be repeatedly asked to make further changes. Any failure of the project/missing of deadlines will then be on your head.

I've been there.

commented: O so true! Been there too. +15

Rewriting in newer version, using code from old version and upgrade some feature is better than converting the old system to the latest.

They have already agreed that they will pay extra for any changes they ask for along the way. I like your suggestion of leaving them all until the end. If you don't leave them until end it makes testing more difficult.

Just to let you know - project has started. Thanks for all your advice - I am going straight to VB2015.

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.