Business-focused custom software

Legacy technology is always a tricky question. Constantly re-writing applications so that they are using the latest and greatest technology/framework/etc. seems unrealistic as this can be quite expensive, with little perceived value for customers and end-users if there are no new features. On the other hand, technology often has a shelf life; over time it may not work on newer operating systems or with other services that do get updated.

Here’s an example: an application written in VB6 that has been running for almost 25 years! In addition, it is running on Windows XP and using SQL Server 2000. It has continued to work and has not needed any new features, so no one has seen a need to update it to newer technology. One of its key features is to send emails via SMTP, and unfortunately this stopped working recently due to security requirements for Office 365. 

This situation has got me thinking about the risks involved in leaving applications on their old technology. Here are the questions I’m asking when considering the risks involved keeping an application on older technology:

What parts of the application are dependent on external resources that can possibly change? This can be things such as:

• APIs
• Cloud-based libraries
• Cloud-based images
• Browsers

These are the areas where your application is likely most vulnerable to changes that can break your software.

You won’t have support for these out-of-date technologies, so what will you do if one of these technologies fails? In my VB6 example, one thing done to mitigate the risk of running on these earlier technologies is to run everything in a virtual machine which is occasionally backed up. This has meant that if something has a major failure, we can typically start with the backup, then restore the latest database backups and move forward.

So what happened with the VB6 application? After exploring several alternative solutions, we changed the VB6 application to simply queue the emails in a new database table, and then created a .NET console application to send the emails based on this queue. It runs on a different server O/S, and is scheduled to periodically check the queue table for new emails to send. Fortunately, the architecture of this application made it easy to decouple this one part of the process from the rest.

Do you have applications that are dependent on legacy technology? What are you doing to mitigate that risk?