Many software companies today are faced with a common dilemma: what do we do about legacy VB6 applications?
Generally, if you’re a commercially successful business with one or more of your major products built in VB6, it’s probably reasonably well-built, stable, and serviceable.
Your customers have come to rely on it. They trust you and the data your product manages. However, they’re frustrated with the antiquated look and feel. They are also tired of waiting for the web and mobile experiences you promised but haven’t delivered, because they’re difficult to deliver.
Additionally, your customers might also feel as if their data is locked inside your product. In fact, some may have even taken steps to extract it themselves directly from your databases in an effort to provide analytics or fill gaps in your portfolio. They may also be tempted by a competitor’s offerings that look more modern and sexy (even though those other guys are unable to handle the level of necessary complexity in their business that your products handle with ease).
And that’s not even taking into consideration the fact that your R&D team has been itching to rewrite your products for years. They may have already begun this effort (inevitably titled ‘NextGen’), despite the fact that a real replacement that you can market, sell, and that can drive net new revenue is far, far away.
Luckily for you, (and your customers) all is not lost! There are three possible paths you can take to modernizing your VB6 apps:
- Rewrite the application from the ground up
- Port your VB6 app into .NET or HTML5
- Modernize the app incrementally
As I always advise our clients, it’s critical to look at technology decisions through an investor’s lens. Each path is beset with differing levels of risk, required investment, and potential returns. And just like anything else, it’s your job to choose the path that will provide the best possible combination of risk and return.
So, let’s dive in and explore Path #1.
VB6 may be old technology, but we are confident it will continue to run on Microsoft Windows as long as x86 processors are still around. The takeaway is that you’ve got up to 10 years with VB6, and possibly longer (remember COBOL?).
But even though you’re not going to hit a technical brick wall anytime soon, that doesn’t mean your VB6 products are competitive, or that enterprise customers won’t start rejecting your VB6 solutions.
All software companies with commercially successful VB6 Apps have looked at rewriting them in modern technologies like .NET or HTML5. This is what your engineering team is probably clambering to do, and no doubt you’ve gotten pressure from some customers to do this as well.
But you should think of this as your last resort. Ground-up rewrites always carry a very high price tag, typically take years to complete, and, depending on the skill and experience of your tech leads, may have a very high risk of failure. At a minimum, they can also have very serious budget or timeline overruns.
Sometimes, you have no choice but to rewrite, rebuild, or re-platform a product. For instance, if your products are built in Silverlight, you’re between a rock and a hard place. The right thing to do is to rebuild or migrate to something else because you are about to hit a wall—all browser support is about to be dropped.
But thankfully, your products are in VB6. And you have options. And you have time to do it right.
Don’t get me wrong, ground-up rewrites aren’t all doom-and-gloom. It’s just important that you truly understand the risks involved with this kind of undertaking. For my money (and more importantly, my sanity) I would hop off this path and instead, look at paths #2 or #3.
I will delve into both of those options in my next two blog posts.
In the meantime, if your head is spinning and you’d like to have a deeper conversation about any of this, please send me a note. I’d be happy to share my insight without any obligation.