The heading below was originally my working title. The title above is the replacement after I realized the first couldn’t have been drier if I’d tried. I needed something a little more interesting. So I played with some word associations: dinosaurs are a pretty easy association to make, right? Prehistoric, big, dominating virtually every corner of the globe for an eon—the legacy, enterprise-scale VB6 system still exists in many forms today.
Issues in Upgrading Legacy VB6 Enterprise Applications
Fairly recently, I consulted to a company to solve the thorny problem of how to upgrade their enterprise-scale product from VB6.0 to .NET. At the end of the assignment, I handed over what we all agreed was a workable and realistic strategy. It was an interesting project. There were things I’d forgotten about how we did things a decade ago; not just in code, but in documentation, meetings, decision-making, everything, too.
Large Scale VB6 to .NET: Still a Common Challenge
One of the most notable things I learned was that this is still a fairly common situation: there are many VB6 large applications still in production, still being actively supported and maintained. I couldn’t find any reliable figures for the number of installations in operation today in 2015 but there are certainly indications that the number is not small.
One article on InfoQ calls it a “looming crisis”, and outlines the problem well—in contrast to some of the comments, which came across as simplistic or naive—some suggesting, for example, that COM Interop (“for me, it is not theoretical. I’ve done it for years, and it works great,” says one) and migration tools (“upgrading VB6 applications to modern .NET (C# or VB.NET) using automatic tools is very easy and accurate,” says another who describes himself as a CTO) are the comprehensive solutions that have somehow inexplicably escaped everyone else who have not yet applied them. The article’s title does seem a little alarmist, though. On the other hand, if a business loses competitiveness and market share, if the business discovers too late that an upgrade will take a year and almost as much money as it took to build the original in the first place, then that is pretty much a crisis, from that business’ point of view.
The .NET Framework was released in 2002 and from the outset Microsoft and partners were already offering migration tools and services. In 2002, Microsoft Press released a complete technical guide called Upgrading Microsoft Visual Basic 6.0 to Microsoft Visual Basic .NET (download the free PDF from Microsoft). More than a decade later, why are there still any major line-of-business VB6 applications in production? Okay, there will be the cases where a system will never need any maintenance or extension ever again, or the need isn’t great enough to justify the cost, and these should be left in VB6. However, for the rest, even if a business had decided to put off a complete rewrite till after the release of .NET 3.5 and Visual Studio 2008, that rewrite should already be in production by now, eight years later. Clearly, the situation or the solution is not always straightforward.
There are still a number of vendors offering products, papers, and services for migrating from VB6 to .NET. They are found readily enough with an Internet search, so I won’t elaborate on them. If you’re just starting to look into this topic now, a good place to start is Microsoft’s own list of resources and partners. I will mention though that I consider the innovative approach taken by one particular vendor, VB Migration Partner, to be the most compatible with the strategy I developed and recommended to my client. (I’ll outline the approach in an upcoming blog post.)
Note that what I’m saying here is that converting code alone should not be the whole strategy. There is more to migration of a large application than simply sucking code in at one end, spitting out different code at the other, then testing the crap out of it. There are other serious considerations such as business continuity, training, resourcing, expertise in both old and new and dissimilar technologies, changes in project methodologies and practices and the tools that support them, just to name the most obvious examples.
What is Enterprise Scale?
Just to clarify: I’m referring generally to those systems with hundreds of thousands or even a million lines of code, with some form of distributed architecture comprising server-side tiers, including databases and middleware, and a separate fat or thin client.
A typical configuration is a client-side VB6 standard EXE installed on workstation PCs, often packaged with several custom/third-party controls and client-side DLLs, connected via DCOM over the local network to server-side COM+ components that handle: transactions, queuing, and connectivity to one or more databases—typically MS SQL Server or Oracle—via stored procedures or direct queries. There may also be other server software or services involved such as MSMQ or Queued Components, ASP, IIS, and Active Directory. All this is admittedly a rather jumbled outline, but anyone who has worked with classic VB6/COM+/MSSQL n-tier systems should immediately recognize the setup I just described.
The diagram below is a conceptual representation of the legacy application I worked with. Some particulars the migration would need to address:
- The system was large—approximately a combined million lines of VB6 and SQL, a hundred forms, excessive number (hundreds) of classes, etc
- The main client EXE referenced dozens of different custom and third-party components and controls, some (critically) without source code or vendor and for which COM Interop was not a satisfactory remedy
- Lots of code violated the intention of the layers in which it lived (e.g. ADO connections in form code, SQL queries passed as strings from the client to the server)
- There were over 1500 stored procedures containing over 90% of the business logic
- A large COM+ “business” layer that consequently did nothing more than shunt requests and responses to and from the stored procedures
- Many deployments of the entire system working standalone were being maintained on customers’ sites, hosting their own servers and networks
I’m not critiquing the original system, mind you. I mention these issues because there will be other businesses with similar issues, and those other businesses may be interested to know how we were going to handle ours. There must be very few “pure” architectures left in the VB6 world, after all…
So, what about the non large/enterprise-scale applications? In addition to the “enterprise” applications, there are far greater numbers of smaller applications and utilities in the wild. As a former VB6 programmer in consultancies, I saw in every company I worked with typically 10, or many more, smaller applications and utilities. Although these standalone applications may also present a potentially real and costly risk to the business, my focus in this post is on those monolithic line-of-business systems, where the complexity and cost of dealing with obsolescence is many times larger.
Having said that, in your own planning, don’t forget to consider any smaller applications that depend on any part of the migration candidate system, directly or indirectly. This may include database schemas, server components, data exports/imports, work processes, etc. You don’t want to be scrambling for workarounds and kludges in the event that something is unexpectedly impacted by your migration.
Not Acting is Acting (Unwisely!)
By the time I was engaged to work on the strategy, my client had already poked for a few years at getting an upgrade underway. As time wore on, they realized they needed to take some definite steps or risk eventually being back-footed by circumstances outside their control.
VB6 was released in 1998, a full 17 years ago—an eternity in IT terms—and declared legacy in 2008. New programmers are not being taught nor opting to learn VB6. Even though classic Visual Basic still ranks #13 in the TIOBE Index for October 2015 of most popular programming languages, it would be irresponsible of any decision maker not to assume that the pool of VB6 programmers available to help with any migration effort will eventually dry up. Businesses will not be able to run Windows XP or XP Mode forever. (Technical support for XP and XP Mode was discontinued on April 8, 2014.) Despite polls and petitions to revive VB6, the language as a mainstream business tool is a dinosaur (obviously ignoring VBA in this discussion). Businesses will eventually be forced to resolve the issues presented by legacy applications and operating environments, and the competition for the last VB6 programmers will become stronger. Yes, all nice and fascinating (like Rasputin’s refusal to die might be fascinating), but of course the critical concern is what needs to be done in the face of inevitable obsolescence.
Failing to decide is clearly itself a decision, and the least prudent at that. Not to put too fine a point on it, but if the application concerned is mission-critical, failing to make strategic decisions and plan for continuity is tantamount to negligence.
Velocity Can Matter, Too
There’s another aspect to “acting” that may be relevant to you, and that is the pace of action. Any way you slice it, migration is a major undertaking and chances are that it will take you a long time. Depending on size, complexity, approach, and experience, a migration project could conceivably take from a few months to a couple of years, and that’s if the business makes it a top priority. That’s a long time for a line-of-business system to be in a state of transition. Working against this is the pace at which traditional VB6 “shops” move. I don’t think it is controversial to observe that development moved way slower back then.1 VB6 programmers grew up in a time of Unified Process, UML, PMBOK and project managers, heavyweight documentation, centralized version control and Visual SourceSafe, physical servers and server configuration, RPCs and LANs, tricky integration and package and deployment activities, etc. Now, we have unit testing, behavior-driven development, dependency injection, continuous integration, Lean principles, Agile/Scrum, test automation, distributed version control systems like Git, SOA and RESTful services, virtualized machines and databases and operating environments and services in the cloud. Going from the old to the new means acquiring many new skills and a different mindset.
I suspect that many VB6 shops will experience growing pains. Taking too narrow an approach to the strategy will make the pain greater. I included in my strategy the heads and principles of where I believed the organization needed to grow. Early in 2014, I wrote (optimistically, it turns out) that they should aim for a first-stage migration “before the end of 2014” and, by that time, “we will be agile”. Almost two years later, I’ve noticed some terms like “agile” and “sprint” have crept into their marketing literature but they have not yet made the real transformative leap.
And so I think progress may be disappointingly slow for many businesses. One client, for example, gave themselves five years(!) to complete migration. Even so, to be in the ballpark of that timeline, they will need to adopt and embrace many changes, even down to their culture. How? Obviously, an appropriate level of commitment and budget are critical. Just as important is the realization that much is new and changed in one-and-a-half decades past and that they must find a new passion to learn about them. Practically, it is important to find leadership in “new school” experience and skills; find practitioners of Scrum/Agile, and experienced .NET programmers with contemporary competence with modern tools and practices. Even better is a senior who has lived in both the “old world” and the “new world”.2 And best of all would be such a person who has worked on a migration project before.
To close out this post, here is an example of how old ways might hinder migration success. Back when VB6 programmers roamed the Earth, when a change to a system was proposed to the VB6/COM+/SQL system, the architect or technical lead first prepared a feasibility report or analysis. She analyzed existing code, played with new tools or libraries, perhaps retrieved some old technical documentation (then discarded it when he realized it wasn’t up to date). After many days, a draft version is emailed to all stakeholders and a review session scheduled. Everyone attends with printed copies of the document in hand and, for the next hour, steps through and debates the contents. The architect modifies the document accordingly; after a few such iterations, the document is signed off and accepted by the decision maker. Then follow the next stages of the waterfall, gathering increasing numbers of stakeholders and participants, producing thicker and more detailed documents along the way. Days can turn into weeks, weeks into months. Our strategy document was distributed for final review mid-July; we conducted that review in September.
In my next post, I’ll look at some migration options and how our choices were affected by stated project goals, desired migration benefits, and some specific technical issues.
Feature photo: I took the photo at the top of this post when I visited Uluru (Ayers Rock) during a singing tour to Alice Springs in February, 2014.
1. None of this impugns VB6’s major strength as a rapid application development tool. I used to fire up Visual Studio 6 anytime I wanted to try something quickly, the way many people fire up Excel to try plugging values into a table. I loved that I was immediately in the editor with no fuss and I could immediately start dropping controls onto forms or typing code—sometimes I didn’t need to do anything more than type in the Immediate window. It is everything else in and around the world of VB6 development that is slow.↩
2. Apologies for the use of vague terms like “old world” and “new world”: they’re just a convenience to refer to all the tools, techniques, environments, practices, etc used in two different eras of Microsoft programming.↩