By Nellaiappan L | March 19th, 2021 |
VB.NET conversion from an original VB application requires choosing between two design options – either re-build from scratch and thereby take full advantage of the .NET platform or fit the existing code base to run on the .NET Framework, which means running your old application on the new framework with no added functionality. Whichever you choose, developer code changes and reworks are inevitable as VB.NET is not backward compatible after conversion.
From functionality and supportability aspects, the first method of re-writing is a better choice. It assures that the full array of .NET capabilities can be harnessed for maximum functionality of your application and it will work properly in the .NET environment. Most IT Managers prefer to have the full application features available to them and to have their Visual Basic application updated to the next generation of web or modern (WFP) desktop applications. Microsoft’s own Visual Basic Programmer’s Journal recommends, to migrate to .NET “you should rewrite an app rather than port it, to take the best advantage of VB.NET’s new features and structures.”
When you go ahead with rewriting the code from scratch, there is a possibility that you may lose the logic and functionality underlying the messy code. A whole lot of knowledge is hidden beneath the legacy code that should not be lost. It is tough enough to read mature well-tested code written by someone than to write it, and yet reading code takes less time than re-writing code. By incrementally improving, you can make sure that the new code does not lose any important functionality. One needs to schedule conservatively and plan for many iterations when re-writing from scratch.
If you choose the latter option of migrating from VB to VB.NET, it should be performed in a systematic way consisting of a plan, identify processes, gather requirements, and eventually build the architecture of the solution. Migration to .NET should be carried out by first converting the existing application to .NET and then fixing the converted code in .NET. There are many tools available to help with the migration, such as the Upgrade Wizard as well as multiple code analyzer tools. However, you will still need to expect to spend a significant amount of time working on the code. If your VB code is anything earlier than VB 6.0, you will need to first upgrade to VB 6.0, then execute a VB6 Migration to .NET. When attempting to run your newly upgraded VB code in the .NET environment, the Upgrade Wizard will launch automatically and will create a new .NET Project. Expect to find compilation issues with properties or objects that are not supported in the .NET Framework. These are issues that will need to be addressed by your developer for the application to execute properly. Once your application executes and is ready for use, it still won’t be able to take full advantage of the benefits of the .NET Framework.
There comes a time when companies decide which kind of migration to choose, there are two types of migration paths, automated and manual migration. This is not a case of one versus the other as well, because depending on the individual case, they might have to blend both to gain the best result.
Automating to .NET is simply code conversion, but the is a code conversion on a massive scale, to begin this process, there are several pre-migration activities. The first step involves going through the entire code for the suitability to convert into .Net without any new coding being required. Microsoft Visual Studio .NET offers a VB upgrade wizard to provide the project team a migration map. Automating to .Net is supposed to be an robotic process, even though it never is, usually after the conversion, the codes will be a mix of .NET and VB codes. Where developers need to come in and rewrite the codes. In short for an automated process there is a lot of manual coding. This approach has both advantages and disadvantages that need to be weighed in your situation.
Manually migrating an application is complex and difficult as the migration team creates a new program from the ground up as they try to match the business logic and business functionalities of the existing projects. It is not only difficult as they start from the ground up, but they also need to study the design of the program as well. This means up-to-date documentation, up-to-date specifications document, and more. So, if there are documentation then the process is straightforward, if not then it is a bottom’s up approach. There is a huge problem when going with the build from scratch approach as the team cannot add any new features until the end. This increases the timeline of the migration process.
Converting from VB to VB.NET will require a significant amount of effort as backward compatibility is not a high-priority goal with the .NET environment. Common Language Runtime is one of the profound changes that reinstates this fact when you move from VB6 to VB.NET. To take the best advantage of the new features in VB.NET, it is advised to rewrite rather than automating the application. But in cases where rewriting the application is not feasible, you can convert the VB6 code using a code analyzer tool and then extensively work on the code before loading it to VB.NET.
