Modularis

Porting: An Alternative Path for Legacy App Modernization

SHARE THIS

The Dark Knight. The Empire Strikes Back. Naked Gun 2 ½. 

What do these iconic movies have in common with this week’s blog?

They’re all the middle feature of a trilogy. They’re also universally lauded as the best installment of their respective trilogies, which means I have my work cut out for me in terms of expectations.

But I love a challenge! 

Just to recap, there are three possible paths you can take when modernizing your VB6 apps. You can:

  1. Rewrite the application from the ground up
  2. Port your VB6 app into .NET or HTML5
  3. Modernize the app incrementally

 

Last week, we covered rewriting the legacy app from the ground up in great detail. You can read it here

This week, we explore Path #2. 

Lots of software companies have been approached by service providers offering to “port” their VB6 products to more modern technology like .NET or Blazor using semi-automated means. It’s been sold as the automated path to legacy app modernization.  

But, it begs two important questions: “What are you going to do?” And, more importantly, “What’s the RIGHT thing to do?”

Time and money are limited, and you need to modernize your products to retain your current customers, bring on new customers, and catch up to, if not beat, your competition. So, it’s not surprising that the idea of porting your VB6 products to something more modern sounds appealing. And, if done right, can be quite effective as long as you have deep pockets and can manage your own expectations carefully.  

On the upside, this approach gets rid of VB6.  But, on the downside, the user experience your customers will receive will be nearly identical to what they have now. In fact, if the port is done well, users will hardly notice the difference. Even if your VB6 products are ported to Blazor and can now run in a browser, the end user experience may be significantly worse than it is right now, especially if your app has large or heavy forms or is very chatty with its database.  

Do you want to spend hundreds of thousands (or millions) of dollars on modernizing your solution, only to have your customers not even notice, because you needed to check a box? Even if that’s what needs to be done, you owe it to yourself to examine all options before going all-in on porting. 

There are three important things to consider when you’re undertaking any major tech modernization effort:  

  1. You want to be careful not to re-invent legacy. I’ve seen this time and time again—organizations spending huge amounts of time and money porting or rewriting applications in newer technologies, only to find that the same architectural constraints, flaws, or limitations that existed in the old technology are still there in the new. If you’re making a major investment in modernization, make sure you avoid this common pitfall.  And, if you’re porting an entire product from VB6 to .NET, understand that this won’t fix any of your long-standing architectural or performance issues by itself.
  2. Modernization efforts have a way of consuming all the oxygen in the room (and your R&D resources and budget). Be careful with how you allocate your resources if you’re going all-in on a modernization effort. Why? Because when customers ask for new features or enhancements for your existing products, you’ll feel a lot of pressure to tell them they’ll have to wait until the NextGen project is complete. When will that be? How much do you trust your team’s estimates?  Again, go into this effort with eyes wide open. Calibrate your investment so that you can continue to deliver value to your existing customers through your current product while you’re busy building the “Next Big Thing.”
  3. Your VB6 product has grown organically over many years. You’ve probably added functionality that only a small number of your customers may be using, and there’s more than likely some code or components that aren’t being used at all anymore. Before you launch into a major modernization effort, go over your current VB6 product and codebase with a fine-toothed comb to identify unused (or rarely used) modules that you can discard or ignore when you’re porting or rewriting your solution. Look at the cost of maintaining those little-used modules or subsystems—it may be worth it to lose a couple of small customers in exchange for significantly reducing the amount of effort and cost of modernization.

 

Next week, I’ll close out this modernization trilogy by exploring a more incremental approach. And, as always, if you’d like to speak in more detail about porting (or even your favorite movie trilogy) send me a note and I’ll be happy to coordinate a call.

Blog Image courtesy of @Mehaniq via Twenty20.

Head over to LinkedIn and follow us for more Software Product Development Insights

Follow On LinkedIn