Visual Basic and how it ceased to be
Visual Basic was created by Microsoft in 1991. With time it became very popular and a lot of in-house applications for enterprises were implemented with it along with an ecosystem of third-party components.
But later Visual Basic was abandoned by Microsoft in favor of the modern .NET Framework. The final VB release was version 6 in 1998. Visual Basic 6.0 IDE is not supported anymore. According to Microsoft, Windows supports core VB6 functionality which is “used in the majority of application scenarios” under the so-called “It Just Works” commitment.
To migrate or not to migrate
So should companies migrate from Visual Basic if it still runs for them? The short answer is Yes. Microsoft itself published an article “Why is it a great time to stop developing in Visual Basic 6.0?” in 2009, 11 years ago.
Most importantly, Visual Basic might unexpectedly stop running. As a low priority process, VB6 support is obviously not verified extensively in every and each of the numerous Windows updates. In 2019 a BlueKeep vulnerability in Windows was found and a patch was released. But that update broke functionality necessary for VB to run. Automatic updates which are recommended for security reasons, simply caused VB applications to stop responding with an “invalid procedure call error”. It took several days for MS to release an update to address the VB issue. During that time customers were left with two options – don’t run VB apps or don’t install BlueKeep-related updates and be susceptible to viruses. At the same time, U.S. National Security Agency and Microsoft itself stated that virus attacks using BlueKeep could be similar in scale to EternalBlue-attack such as the notorious WannaCrypt. That “worm” encrypted the whole hard drive and demanded a ransom in bitcoins. No wonder it was nicknamed by frustrated victims as WannaCry.
A closer look at Microsoft’s pledge to support VB core reveals that they never promised to support everything. Users might experience strange behaviors of applications, cryptic error messages, and crashes resulting in data loss. The core VB might work, but third-party components written in VB6, such as OCX/ActiveX controls, might stop working. Customers are advised to contact original vendors. The thing is, a lot of original vendors also don’t provide support for their old programs or even are not present in the business anymore.
Eventually, all companies will face no choice but to rewrite their applications. The recent 2020 case with the US government systems working on COBOL shows that the longer the problem is postponed, the more costly it is to resolve. Ancient languages like COBOL and Visual Basic don’t attract current students and the number of experts is dwindling each year. Scarce programmers willing to work in that field must be paid exorbitant salaries. Problems arise also because old languages used old architecture approaches and such “spaghetti code” drastically increased the complexity of the application that should be modernized. Moreover, such old applications are usually poorly documented and people who remembered what it should do, don’t work in a company anymore. Reverse engineering of such legacy applications earned the name “software archeology”.
All companies must evolve to keep up with their competitors. For the company software, it entails a change in processes, integration with new industry-standard applications. Business growth demands program scalability. Modern enterprises are going web, cloud, and mobile. This all is either very expensive or simply impossible in Visual Basic.
How to approach migration from VB6 to .NET
Now, what can be done when a company is ready to start a transition to the new technologies? There are three possible ways of approaching the migration task:
When an old application works fine (and the issues/risks described above are accepted), but it is desired to develop new features with fewer efforts and costs, extension can be suggested. Additional .NET modules can be called from within old applications. Legacy can be left as is, but new stuff will be implemented with some modern framework. Eventually, old modules that are still relevant to the business can be also migrated to .NET. This approach is well-known as a “strangler” pattern.
Advantages of the Extension approach:
- Might be the cheapest way in the short term.
- The system is converted gradually; clients immediately benefit from investments done for modernization purposes.
Disadvantages of the Extension approach:
- Business continuity risk: parts that are left in Visual Basic will still be prone to VB6-related issues until they are eventually rewritten.
It might be the case that an old application works unstably annoying users with frequent errors, sometimes even causing work loss. At the same time, the number of users is relatively constant and business processes are attuned to the desktop experience. A good choice in this case
is to migrate applications. This might be started with automated converters that take Visual Basic code and translate them to C# .NET. The resulting code requires manual adjustments for specific parts that are conceptually different in those languages, for replacing OCX/ActiveX controls. Also, upgrade from default for converters Windows Forms to the newer WPF is desirable.
Advantages of the Migration approach:
- Second cheapest way after the Extension approach.
- The similarity of platforms allows preserving the usual user experience and lowers the chances of incorrect implementations.
- The whole application will be free from VB6 security and stability issues.
Disadvantages of the Migration approach:
- The base application must be developed before the new functionality can be added.
- Poor architecture choices might be inherited from the original code, eliminating them would require additional efforts.
The third way is a complete rewrite to the .NET Framework. This is the approach required when the migration is done straight from legacy desktop VB6 application to a different platform like web. Such transitions can be demanded to support the extending base of users by scaling into cloud. A similar reason can be a strategy to extend market share by providing users with simple yet powerful access via web and providing features at hand via mobile applications. Finally, the original application might be totally outdated, not satisfy business in significant areas thus major overhaul is anyway necessary.
Advantages of the Rewriting approach:
- The only way to go if a change of platform to web or mobile is required.
- Architecture written from scratch using modern approaches allows cheaper development of improvements and more reasonable ongoing support expenses in the long term.
Disadvantages of the Rewriting approach:
- Requires a bigger initial investment than the previous two ways, however, it is still justified by the future benefits.
- Rewritten functionality must be extensively tested to confirm compliance with the old behavior.
Discover how .NET development can benefit your business – contact us by filling out the form below.