Gap between Code base and Production application

Question

Background

I joined a company as a solutions architect less than a year ago, with a main task of consolidating, and modernizing legacy code resulting from 90+ company acquisitions over the past 20+ years.

One of those legacy applications, is a desktop application written in VB 6.0 that accesses a SQL Server database and has business logic embedded in the client side. That was the good news!

The bad news is that the production release of this client residing at end users machines, is two releases after the latest code checked in our source control system (that is 5 years gap).

What I did so far

I installed Enterprise VB 6.0 IDE, and attempted to load latest source code and tried to charter the application into main modules, relying on menu items defined in the main form.

I used some sort of a mind map like diagram to list down those menu items, and identified the main function of each of those items, in terms of data access and processing.

Fortunately, 8 menu items out of the 162 items are useless decorations, but the rest points at real business logic and data access.

What I was planning to do next

1. Identify database tables accessed by each menu item
2. Identify relations among those tables in terms of triggers, referential keys and possible stored procedures
3. Build a skeleton .NET web application
4. Attempt to infer some workflow diagram for one of the main modules of this application
5. Extract that logic of the identified module into and implement it into the .NET application with hooks to the original database
6. Convince users to use the new screens provided.
7. Iterate on the previous steps until all functions covered by he legacy application are migrated into the modern web application.
8. After all screens and business logic is migrated, I should start refactoring database objects.

My Question

IS the above plan realistic? is it sub-optimal? Any advise on more practical way to deal with this beast?

Thanks and sorry for the long question

Answer 1

So it seems you are planning to rewrite the original application step-by-step and replace it with a new application. Depending on the application logic, a "step-by-step" approach maybe possible or not, and it could be a sensible approach.

However, for a 100k LOC application, if the new implementation will be roughly of equal size as the old, my gut tells me you should expect a total effort of something between 2 and 4 person years (roughly). Of course, this is just a wild guess, and it will really depend on a dozen factors like the team involved, in the necessity to migrate the full application or only parts of it, in your ability to analyse the unknown business logic and so on. But it should give you an impression about the costs you have to expect, so you or your company can consider if it is worth it or not. You should also be familiar with the arguments in Joel Spolskie's warning against big rewrites, however, this article assume you have some alternatives based on evolving and refactoring of the original source code.

Before you go this route it might be worth to consider some alternatives which could turn out to be more economic:

• try to track where the former devs are living today and if someone of them might have a archived copy of the actual production source (or at least a newer version than you have). A two weeks salary for a professional investigator will probably be much less than a 2 years salary of a developer, so it might be worth it.

• analyse how big the actual functionality gap is between the available source code and the current production release, and make an estimation if it may be cheaper to reimplement the missing differences on the available VB6 code.

• try to use one of the existing VB6 decompilers. Even if it does not produce you maintainable or compilable code, it might help you for doing the former step, or to make the migrating of the old application to

In the end, this boils down to a management decision. Rewriting the old thing might be also a strategic decision to get rid of the old VB6 legacy code. Another key factor here is also how important that old application is to your company, or how important it is that evolvement and bugfixing can take place.