In it March issue, Visual Studio Magazine published an in-depth article about legacy migrations called “Unlocking Legacy Code”. This article talks about the challenges faced by companies migrating from Visual Basic 6.0 to .NET, the drivers behind these migrations and the pros and cons of using an automated migration solution.
The article uses BEMAS Software as a case study for successful migration products. I am incredibly happy they are doing as well as they are with the conversion – they are using our tools, and I visited BEMAS about a year and a half ago to train them on the VBUC and help them plan the migration project. I remember they had a lot of conditional statements (by “a lot”, we are talking thousands of different combinations), as mentioned in the article:
"We also ran into some issues with the conversion tool because early on in the VB code we did a lot of #ifs, which means that the code acts differently depending on how you compile it," Pownall adds. BEMAS worked with ArtinSoft so that VBUC would recognize those instances and convert the code correctly.
It was quite a challenge to get it to convert, since the default behavior of the VBUC is to convert the code inside the conditional statement that evaluates to “TRUE”. Commenting out the conditionals wasn’t going to work either, since that would cause multiple variable declarations and other semantic errors that caused issues during the migration of this particular code. In the end we worked together with BEMAS, and with heavy involvement of the VBUC development team, we managed to modify the tool enough to get the code converted correctly.
Another very interesting item mentioned by Steve Pownall in the article, that I want to talk about some more, is the fact that even though the code came through very cleanly, it didn’t have the .NET architecture they were aiming for so they had to “The dev team had to massage or opted to rewrite the rest of the codebase manually in C# and .NET 3.5 using VS2008.”. This is a very important point, since the overall architecture of the code will remain as it was in VB6.0. The migration, however, gets you quickly to a stable .NET codebase that you can then rework to make it take advantage of the latest features of the .NET Framework. In our experience, this path (migrate, then enhance) is the one with the lowest risk, and it allows you to reduce the time to market for your applications by a wide margin. This is important to keep in mind, since we, as developers, always want to improve the code base – it is part of our professional formation, and I would say, part of our nature – but we sometimes fail to grasp the additional risk this implies. The migration is very controlled process, that gets you predictable results in a short time. Enhancing the application after the migration may seem like duplicating work (and indeed, there are enhancements that can be done during the migration process) but it guarantees that you will get a .NET in the allocated timeframe and budget, not to mention the cost advantage.
Read the complete article, Unlocking Legacy Code at Visual Studio Magazine.
A quick post to let you all know that the recording of last week’s webcast I did on compatibility options for Windows 7 is now online. In this webcast I briefly covered different compatibility options available for Windows 7, mentioning things like virtualization (such as XP Mode) and Remediation, and the focusing on the benefits of using automated migration tools to get the application off VB6.0 and into .NET so it can take advantage of the new APIs available in Windows 7 (Taskbar API, touch API, etc).
See the recording here
Next Monday, August 17, I will be presenting a Webinar along with Microsoft for the Latin America region on how you can use several options to get your VB6.0 applications to run on Windows 7 AND get the Windows 7 logo. The webinar will be in Spanish, and covers the business reasons for the migration, the benefits of using in the .NET Framework, alternatives, and information (+demo) of the VBUC.
Here’s the link so you can register for the Webinar:
Actualiza tus apliaciones y consigue el logo de Windows 7
Fecha: 17 de agosto 05:00 p.m. Ciudad de México
Register for the Webinar
We just posted a new case study about how an Italian company, Wolters Kluwer Italia, managed to successfully migrate its flagship Accounting and Financial services product from VB6.0 to Visual Basic .NET, using a customized version of the Visual Basic Upgrade Companion.
This Wolters Kluwer is a case where the VBUC customizations performed by ArtinSoft helped them achieve two very important goals: first, to radically speed up the overall migration project, by having the VBUC do particular transformations that otherwise would have required manual changes, and second, to meet very specific requirements for the migration, such as using having the VBUC generate .NET code that used their own controls, do additional refactoring to the code, and other architectural customizations made possible by the VBUC engine.
Read the case study: Wolters Kluwer licenses the Visual Basic Upgrade Companion to quickly and cost-effectively modernize its flagship Accounting/Fiscal software product
This past couple of week I’ve been contacted by a couple of developers concerned with Microsoft’s decision to stop supporting the Visual Basic 6.0 IDE, but to continue support for the Visual Basic runtime and some support libraries in Windows 7 and 2008. This made me think about revisiting the topic with new information and changes since February, when I wrote this post.
It is obvious that Microsoft has been trying to drop support for VB6.0 for a while now. They have extended it a couple of times, and they say they are committed to "make sure the IDE works" for the lifetime of Vista and Windows 2K8. But here is an important part of the support statement that is worth highlighting:
“VB6 runtime will ship and will be supported in Windows 7 for the lifetime of the OS. Developers can think of the support story for Vista being the same as it is for Windows 7. However there are no plans to include VB6 runtime in future versions of Windows beyond Windows 7.”
This means that the next version of Windows will very likely not include the VB6.0 runtime files. This has obvious implications if you have a large application that will require several person-years of effort to migrate (or rewrite, if you decide to go that path). There are also some additional implications on the components you are using, since they may have a dependency on the VB6.0 runtime and thus may not work, even if the rest of you application is already in .NET and using these components through COM Interoperability. Just to be sure I’m not spreading unnecessary panic, Windows 7 is not even out yet, and it will be covered by Microsoft’s OS support policies, so you are good for at least the next five years. If you think the effort to move away from this platform will take longer than (or at least close to) this timeframe, make sure you start evaluation your options soon.
Another important thing to keep in mind is that the VB6.0 runtime files are 32-bit only. Starting with Windows Server 2008 R2, 32-bit mode (WOW64) is optional, and the next version of Windows Server (tentatively due in 2011-2012) will be 64-bit only. This affects both server-side components, ASP, and client-side applications running on the server through Terminal Services, Citrix, or any other remote access technology (though they may able to run using WOW64, albeit requiring an extra configuration step).
A big change since I wrote the last post is that now Windows 7 includes a complete XP virtual machine to run legacy apps, known as XP Mode. I already made a couple of posts on this, and basically, this seems to be a good intermediate steps to “buy some time” before companies move their applications to supported platforms.
As I recommended in the previous post, you should read the "Support Statement for Visual Basic 6.0 on Windows Vista, Windows Server 2008 and Windows 7". Also, the Microsoft Product Lifecycle details the specific dates when support ended for VB6.0.
The business-oriented newspaper, El Financiero, just published an article talking about the advantages of performing a migration instead of a manual rewrite. The article talks about how Banamex (part of Citigroup) saved an estimated 80% of the cost when compared to rewriting their 125 applications, totaling over 5 million lines of code. It also talks about the advantages of being in .NET, including how it allows customers to rapidly respond to changes in market conditions.
You can read the original article in Spanish at the following link: Cambiar el software en estos tiempos de crisis or read the Google Translation in English. You can also check out the Banamex/Citigroup case study at the following link: Banamex - Citigroup turns to ArtinSoft to ensure compliance and business continuity through massive migration to C#.NET
Yesterday TechNewsWorld published an article called Planning a Migration Route From Visual Basic 6 to .Net, which discusses some aspects of a report by the Aberdeen Group. The article contains lots of valuable information for those of you considering moving your VB6.0 applications to .NET, by giving a very good idea on the best practices performed by the “Best-in-Class” organizations. I wanted to touch briefly on some of the points from the article, and how it matches our experience helping Fortune/Global 1000 companies upgrade their applications to the latest technology.
Something that is consistent with what we’ve seen is that 33% of the respondents from Best-in-Class and 15% of the “All Others” organizations engage a third party to assist with the migration. We at ArtinSoft, with our Consulting Services group, and along with our world-wide partners, have seen this as a growing trend, and have accumulated a vast a mount of experience that can be leveraged by these organizations to move away from legacy environments.
Also, as part of our migration methodology, we promote a controlled process that first brings your VB6.0 application up to Functional Equivalence in .NET, and then you can use this as a base to enhance an improve your investment. For many clients we also use the extensibility capabilities of the Visual Basic Upgrade Companion to prepare the source code for these enhancements by automating specific architectural modifications required by our customers. These modifications represent an enhancement in itself, and also leave the code ready for further changes by making sure it meets all the practices and coding standards of the organization. The Vertex Omiga and Supervisor Case Studies are a good example in this regard – and we’ve done other migrations with even more important customizations that, unfortunately, I can’t mention directly.
Finally, I want to quote the following text from near the end of the article:
“The research shows that Best-in-Class companies are six times more likely than all other companies to use code conversion or automated porting tools in order to help accelerate part of the migration process.”
You can read our case studies that show this is in fact the case, and we have helped many organizations save time and resources when performing migrations aided by using the Visual Basic Upgrade Companion.