Over twenty years have passed since the last major release of Classic Visual Basic (a.k.a VB6) and Classic ASP. Microsoft's recommended replacement for VB6/ASP, .NET, has evolved rapidly and is established as a leading platform for software development. The world is moving on, and VB6 and classic ASP are being left farther and farther behind.
People: the supply of skilled resources ready, willing, and able to maintain and enhance classic VB/ASP will continue to shrink. This trend will accelerate as the number of organizations offering opportunities to work with more viable platforms increases.
Products: the number of vendors, authors, and experts who are focused on supporting and serving the classic VB/ASP market will continue to shrink. Not the least among these vendors is Microsoft who has clearly shifted its considerable marketing, technical, and support resources squarely to .NET. This trend will also accelerate as other more viable platforms (e.g. .NET) become more important in the market.
Process: the number of new productivity/quality enhancing processes, tools, and techniques that are designed for classic VB/ASP development will shrink. Cost saving techniques such as automated unit testing, dependency/impact analysis, and continuous integration are designed around contemporary development languages and platforms and they do not always work so easily with classic VB/ASP. As with people, and products the decline of VB/ASP centric process innovation will also accelerate creating a growing productivity gap between teams using classic VB/ASP and teams using .NET.
You will likely face some resistance when you try to make a case for migration:
If it's not broken, don't fix it.
This is very good advice most of the time. But in the case of depending on critical software systems
If it's not broken ... it will be.
Like it or not: classic VB and ASP are dead languages. We must now take steps to
There are many factors that go into computing the ROI for legacy modernization. Let's begin by asking: what will happen if we choose to do nothing?
I admit these ROI factors are difficult to put a value on, but they are clearly important and they must be factored into the decision of why and when to migrate. Fortunately, our products and methodology will significantly reduce the effort, risk and disruption of your migration without sacrificing quality, control, or time to market and this will benefit the ROI.
Notice that this ROI model does not depend on functional enhancements, process/productivity improvements, or the intrinsic value that .NET, or any other contemporary platform, might offer. These value-added benefits are real, but they are secondary. The primary, and most critical motivation for leaving a dead platform is to reduce the risk of business problems that can impact you and your customers.
Planning, starting, and finishing a migration will go much smoother if you are proactive in determining where you are going and you follow the right approach to getting there.
We appreciate that different organizations face different challenges. Please contact us if you would like to discuss your specific needs.