Business Case for Migration

Trends and Predictions

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.

If it's not broken...

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
built with a language that has been left behind by the development community, it simply does not apply.

In this case, the more realistic and proactive mindset is:

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
protect your VB6/ASP investments by upgrading them for a viable platform.

What is the ROI?

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?

Recruiting and retaining people to maintain and enhance your software on the classic VB/ASP platform will become very difficult and expensive. Productivity will suffer and costs will increase.
The needs and expectations of users, customers and other stakeholders will diverge from what classic VB/ASP has to offer and they will grow dissatisfied. In some cases, an inability to meet these expectations (i.e., strategic, policy, regulatory, or security) will have serious business implications.
As your competitors move their systems off classic VB/ASP they will gain a competitive advantage and be in a better position to recruit and retain skilled developers and sales people. If you are an ISV, your competitors might tell prospective customers that your products are old-fashioned and out-of-date compared to theirs.
It will become more difficult and expensive for you to integrate with contemporary third-party tools and products.
Eventually, incompatibilities with the changing environment will lead to more frequent and severe system problems and the lack of good people to help you resolve these problems will increase their impact and cost to your business.
The ultimate result of doing nothing is reduced IT agility at best and critical system failures at worst.

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.

Where do I go from here?

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.

Choose a replacement platform: If your developers know Windows and your customers are happy with Windows, .NET is a viable option – probably your best option. Contact us if you are serious about investing in migration to a platform other than .NET.
Get your organization ready to make the move: Immediately begin upgrading your development teams to .NET with training and hands-on work then begin executing a strategy for taking advantage of the .NET platform, tools and processes.
Develop a plan to make the move efficiently. We believe you will find this much easier to do if you "cash-in" your legacy codes using our tool-assisted rewrite methodology. Start getting smarter with this case study and the other documents on our site

We appreciate that different organizations face different challenges. Please contact us if you would like to discuss your specific needs.

Browser not supported