When is it time to port an old application to new platform?

Question

I'm working for a company that has an established application written in VB6. The application is stable and continues to provide the company with good income. However, it is beginning to show its age and noises are been made to port to a more modern platform such as .Net.

Since this is hardly ever a cut and dry decision I would appreciate input on when it is a good time to port a long standing application to a modern platform.

Some of the pros and cons that I have already worked through:

In favor of porting

• Finding skills for an old programming language becomes harder and more expensive
• Support from the platform vendor ends at some point
• Leveraging modern programming practises on the old platform becomes harder or impossible
• Rewriting provides the opportunity to improve existing practises
• Moving to a modern platform is motivating for the development team
• Moving to a modern platform provides marketing opportunities

Against porting

• "If its not broken don't fix it"
• The cost of rewriting versus the return
• Risks associated with the transition from the old to the new application
• Upskilling existing software engineers

Some related StackOverflow questions:

• What makes code legacy?
• When do you say that the code is Legacy code?

Answer 1

Echoing jro and especially Erno,

• Upgrade before there is a crisis.
• Upgrade before the developers move on to other places where they have a chance at working on a modern framework.
• Upgrade while the developers that built the original program are still around.

No competent developer will accept a pure porting job, it is not a career enhancing move. But the existing developers will be happy to learn the latest framework as part of a porting effort.

VB6 was released in 1998. March 31, 2008 Microsoft EOL'ed all VB6 support. Your company is so far into the danger zone with this code, it isn't funny.

To add some perspective,

• Netscape was still an independent company and they just release Netscape 4.
• Clinton was still president
• The internet was still a new concept
• Intel had just released their hot new Pentium II running at 450 Mhz
• The Matrix was still filming
• Google hadn't been founded (it was later in the year)

At some point, the company will be forced to upgrade the app because the operating system will no longer support the apis.

You should leave this company. It is career death to stay.

Update because Cody thinks "I am an individual developer":

@Cody -- Rethink your assumptions. I run my own company. Without fail, every time we have slipped behind the last stable release of a platform, catching up has been incredibly painful and expensive. The latest pain point is we are on dojo 0.4.3 and Tapestry 4. T4 and dojo 0.4.3 have this mutual interdependency that we are separating (slowly). Moving to Tapestry5 and/or jquery or even just to the more recent version of dojo is very slow and very painful. The porting has taken over a year because it has to be this long stretched process to keep other development moving along.

The choices are :

1. stay stuck on the old library forever (with the problems around finding/attracting talent),
2. try to run dual-mode (old/new) code (code doesn't always cooperate,
3. or freeze development on large chunks of the product during the port

So far we have been doing a combination of #2 and #3.

Being on old version of either dojo or tapestry means that we have lost the ability of the community to support us and help us with the problems. The advantage of a framework is that other people are doing work that solves your problems. Nobody is solving any VB6 problems any more. Microsoft will not even take money to solve VB6 problems.

The OP's company is completely on their own. Note: that Google was just founded the year VB6 was released. I would suspect that VB6 knowledge has been disappearing from the web and that each year a Google search about any programming problem the OP's company makes will return fewer and fewer results.

This is a business viability risk.

The happy talk about MS supporting VB6 forever and ever is not a good idea. All it takes is some SVP at Microsoft saying: "We can ship the next Windows version in time to make Christmas if the teams do not have to fix these issues that affect only VB6. We will issue a Service Pack later." At some point this can and will happen.

A competitor can come along and introduce a competing product using the latest tools faster ( because the large pool of libraries available when using the latest frameworks.) The OP's company has lost the ability to be nimble because the latest tools and libraries no longer support VB6. (A 13! year old framework!!)

This is another business viability risk.

The fact that this needs to be explained to anyone is a huge, huge warning flag to any developer with any experience who is interviewing at the OP's company.

This reduces the quality and quantity of the talent pool enormously.

Not being able to attract quality talent is another business risk.

The original OP should bail.

Its not just Microsoft and will the Windows support the app. What about things like printers? or displays? Epson is under no obligation to release printer drivers that support a VB6 application.

• What happens when the print function stops working for customers on their latest cool 4G-enabled printer?
• What happens when customers try to use the app on the now-standard 2000x4000 display and the fonts look all goofy?
• What happens when Adobe starts having Adobe Reader advise that the PDF file version should be upgraded?

Seeing a warning dialog popup, not being able to print, use the latest display well, etc will result in customers quietly moving to competitors. They will not even bother to tell the OP's company that they are doing this.

The OP should move on before the layoffs hit.

Answer 2

One of the things to consider is that porting an application can get more and more expensive over time. I have seen applications writen in 'ancient' languages that were very well developed. But, as happens many times, all the domain knowledge was in the code and in the heads of the developers, not in up-to-date documents.

So in situations like this porting means not only rewriting in the new sparkly language but also reverse-enginering the specs and picking the, hopefully available, brains of the developers. This becomes harder and harder over time.

An other thing is that 'porting' is hardly ever as easy as the Migration Wizard want us to believe. Many wizards produce a half-baked solution that is still constructed according to the constructs and features common to the 'legacy' environment and will hardly be using the new features and possibilities. This might not seem that bad but if you leave it at that level you are in fact making it very hard for developers that know the 'new' language to understand the code and make porting to the next platform or language even harder. That is what I call LEGACY in capitals. Dragging useless stuff around for decades.

The optimal moment to start porting, from a developer's point of view, was yesterday.

The optimal moment to start porting, from a manager's point of view, is tomorrow.

The optimal moment to start porting, from a competitor's point of view, is never.

Answer 3

There are a lot of other considerations to evaluate: opportunity cost (what else could we be doing), capacities for extensibility and growth (what else does the application need to do/be), sustainability with other moving parts (DB upgrades, OS upgrades), etc. The list goes on and on.

Specific to VB6, I would evaluate what limitations are in the way of product progress vs. moving up to the current .Net framework. Ask yourself -- is this really an IF scenario, or a WHEN scenario?

From a general standpoint, the worst time to port an application is when you HAVE to port it. Your situation sounds like an ideal time to begin code migration -- before it becomes a necessity. Given your legacy product's profitability for your company, any situation where you're forced to move to migrate brings pressures around deadlines, scope, etc.

All things considered, your situation sounds like an ideal time to port up to the .Net Framework, well before it becomes necessary.