Estimated Costs for Translating large VB6 projects to DotNet?

Why do you need to convert it?


-------------------------------------------------------------------------------------------------------------------------------
My Articles:
Using the VB6 Debugger • Automatic Insertion of Procedure Names
A Textbox ActiveX Control That Limits Input to Numbers • Spell Check a Textbox
Improved Formatting Tags • Conditional Compilation • Dynamically Resize Form Controls

Marty - MVP 2009, 2010, 2011

Same question as above.  Maybe you can deploy the application a different way to avoid converting it.

Terminal Server / Citrix / Remote Desktop/App services.  Application Virtualization / Thin App

I thought Microsoft says VB6 won't run on Win.8??
Our system is not installed by an IT guy, people just download it from our website as a simple 'msi' and click install.. And expect it will run.
Can an msi install file handle or setup things like Chakko mentions? Eg. setup a Vitrual XP machine?

You should probably look at new approaches more seriously before assuming you have to convert.  Can you list the key features of this software, who the target audience is (is it college students only?), why you do it this way, etc.  I'd like to know some of the assumptions and many people don't always think of these.  This could help us come up with more ideas like the ones discussed so far.  For instance, you mention it is easy to download and instal l.  MS has a "one click install" technology to do things like this but I doing know if out applies.  Also, what about making a complete self-contained virtual machine, then the users only have a simple, commonly used "middle layer" that could allow you to run your program not just on Windows, but anywhere that a virtual machine can run.

Hi Kbirecki..  The software is a medium size complete business system. Ie. Debtors, Creditors, 200+ Reports, Gen.Ledger, Invoicing, Inventory, Orders, Receivals, Barcode scanners, Auto-Syncd webstore. Etc. It has about twice the features of MYOB. Like most business systems this size, it took about 20 man-years to write, so it would be a travesty to let it die..
It is provided as a free franchise to any college graduate.. (Which does sound a little crazy - but, it was written by 3 retired College Lecturers with the welfare of students in mind.)
The idea is each of these 10,000 graduates forms a Co-Op of supporting grads (with Accounting, Management, Hardware, Warehousing skills) and this Co-Op markets this business system to 50 small businesses in their area. Thus, we hoped to provide 10,000 graduates with a free franchise and a million small businesses with a well supported business system.
These IT Co-Ops would be capable of installing virtual machines and thus solve our problem.. But, this plan required the co-operation of colleges (which we initially did have). However, about 4 years ago they refused to help any further because they demanded the software be upgraded to DotNet. Quote.. "VB6 is a dead language and we won't support this plan as it stands."
That left us with trying to directly attract small businesses around the world to download a 6 month free-trial copy off our web-site.. That plan was to establish a customer base that would then attract the support graduates without the need for college support. At the moment, this plan isn't working too well.. Out of a hundred downloads, only one or two manage to get their heads around such a complex system without local support to "show me how this works".
Thanks for your question, it has helped me to realize just how important local IT support teams are, as a first step, if we want to save this project.

"saving the project" sounds like a great idea, especially after all the effort put into it, but technology does march on.  Even if you get it running in newer platforms, the schools point about it being old technology could be valid depending on what sub-technology it uses.  For instance, older COM technology is being replaced with newer, better tools, so if your system retired on something that will no longer exist at some point, the decision will be made for you.  You can use thea concepts to help you string out a transition, but not likely anything long term.  You should probably start a dual path of short term sustainability & long term evolution, with an expectation to continue some form of evolution by looking at where this kind of technology is going.  To be honest, off the top of my head, you'd probably be better off going towards web-based solutions instead of traditional installed software solutions - there are a lot out advantages and ongoing advancements in this direction, including cross platform support, mobile, etc., that more and more customers are already demanding.

What you may ned to consider is a different model.  One idea might be to try to entice more than just grads, and try offering "get in on the ground floor" options with some form of commitment or investment.  You could possibly also consider some of the approaches that open source companies have (earn money for development through support, etc.)

VB6 programs definitely will run on Win7 machines. You may have to change some things like how the program deals with the Registry (if it does) but that a minor change compared to rewriting 1,000,000 a million lines of code.

@MartinLiss,i dont remember the details, but it seems like I read somewhere vb6 COM objects running in win 7 is a problem.  Do you know anything about this?

ok, I'll look when I get online later.  Just thought you might know off the top of your head.  We still use XP as well at my company.

Let me ask you another question then. why get rid of XP? Is the benefit worth perhaps $1,000,000?

The problem is not Win.7 - Our software runs fine on it..  It is Microsofts comment that VB6 won't run on anything after Win.7..
Martin.. "Why get rid of XP?" The problem is our customers accept whatever OS the PC vendors are shipping and expect our software will run on it. They will soon be accepting Win.8.

My original question was "Has anyone converted a big system?" and "How much did it cost?" The 'silence' on that might indicate that those with big systems are also planning to stay on VB6???

No doubt you will eventually have to convert or re-write to .net :(

Most lines in the code will need no converting and VB.Net tries to convert the code for you anyway.

However, there will be a small minority of code lines that do require some special intervention, and they will bring up the cost per line figure, but I think that the given estimate is far too high. It's a lot more that I would quote.

To that last point, it may run, but how would you support it reliably?  There has to come a point where even vb6 stalwarts give up; what would stop someone from using the same argument for the immediately preceding or subsequent versions?  Or all versions?  Where does MS's responsibility end on such old technology?  They may be privately maintaining some semblence of support to give people more time, but technology marches on and, a much as I dont like it sometimes,  we need to keep moving with it, or get left in the dust.  There was a time when rock roads were bring built around the country to support commerce using wagons, but the rail took over for 500 yrs, then roads again.  Things can be cyclical, but the point is they change and expecting them to not change is unrealistic and un productive.

Heres another aspect to think of:  competition.  If your competitors can start today with current technology and get, say, 80% of the functionality with 20% of the effort, what does that do to your relative costs and how long could you compete that way with all the legacy costs of supporting what could be a harder way to do things?  Take this as a wake up call and start working on a parallel track to upgrade to new technology, because if you dont, and the product is worthwhile, you know someone else will.

Innovate or wither -  there is no stagnate.

Thanks everyone for the great advice..
My original question remains unanswered though..
"Does anyone have experience with translating a large Inventory/Accounting VB6 system to DotNet? and what sort of "cost per line" can we expect?"
What about a tiny Inventory/Accounts system? (10,000 lines?) that we could scale up from??
Or.. "Has anyone migrated such a system from VB6 to Delphi?" (Eg. using NexusDB)
I'll up the points and leave this open for a few more days to see if there is some advice I can present to our backers.

I'm not arguing with the need for languages to evolve.. Like COBOL, EVERY language on earth has evolved over the last 50 years.. BUT the increments in the upgrade process were ALWAYS achievable with a cost of less than 5% of the "re-write" cost!
The VB6 to DotNet conversion requiring a major re-write of all the code is unprecedented in programming history. And, there is nothing wrong with the current VB6 system - Our hundreds of users think it is a perfect system! There is nothing they require that it can't do..

For my part, I think I understand where you're trying to go with your question, but in my opinion, and what I see others saying here, you need to change the point of view of the question.  You have some assertions and/or assumptions that I'm not sure are valid.

Here's my take on your assertions and what I'd suggest you consider differently:

1. There *is* a valid "cost per line" number you can rely on to make any kind of decision about migrating from VB6 to dotNet.  I would say that is not valid, helpful or relevant because anything anyone tells you based on a formula without actually doing something like what we used to call a "needs analysis", essentially *looking* at the existing project and required scope, is going to give you wildly inaccurate information and you will be very disappointed when the project begins missing deadlines and cost estimates not based on real analysis.  Nobody here can do that in a vacuum without seeing the details.

2. That methods used in the past to evolve systems from old to new technology can still be applied, such as COBOL.  This, too, is not valid.  Back then, programmers were sometimes paid by how many lines of code it took to develop an app - it was a "manufacturing focused" (i.e. pieces and parts) concept because technology was still new.  There was no incentive to be efficient.  Eventually, people and businesses came along and said they can do this cheaper and faster using totally different methods, again requiring totally new ways to estimate.   In all the "estimating", "project management", etc. books and articles I've read, and all of these types of projects I've done myself, the one most important common thread is a clearly defined scope.  And the best way to get that is to pay a small amount to a trustworthy, knowledgeable company to do the analysis, so that you can determine what the big amount to complete the project will be.  And the completion does not have to be with the same company.  You can put out an RFQ for the analysis (get quotes for this from several companies) whose goal is to scope out an RFP for the completed project (again, to be submitted by several companies).

3. The VB6 to DotNet conversion requiring a major re-write of all the code is unprecedented in programming history.  I don't think this is the case.  Your app may be large, but it is still a series of definable chunks.  Take some of those smaller chunks and use the conversion wizard in dotNet to see how it does and what it shows.  If you get an MSDN subscription, you can go into the archives and get some of the older VB.Net's to be closer to the original VB6 and see if it makes a difference.  There are plenty of articles online on this since it *is* such a big need.  Here is one such article about these ideas where the author has a lot of good suggestions:  http://dotnet.sys-con.com/node/46335.  One of this authors suggestions is what I think I or one of the other experts were suggesting at one point, and that is to work in parallel converting portions at a time (i.e. if there are ActiveX components, convert just that to a dotNet equivalent.

Thanks Kbirecki.. We have tried most of your suggestions..
We have paid some world-class DotNet guys to run our system thru the VB2008 conversion wizard and give us their recommendations.
They agree with Microsoft.. * It will have to be 75% re-written. * About one man-year.
I've also read hundreds of similar VB6 to DotNet questions on ExpertsExchange.. The overwhelming "Guru Advice" is to re-write the lot.
* Other case studies would not be "wildly inaccurate" because most large Business software Systems are almost identical.. They all have the same 5,000 modules, and no mater who writes them, the code for each of those modules looks the same.
* Unprecedented? I have many friends who have been writing large business systems for 30 to 40 years.. None of them have ever seen a case where more than a 10% re-write was needed.
* We have re-written some smaller sub-sections.. We chose them based on their variety of code.. The cost was always about $1 per line and in each case, the 2008 auto-converter was almost useless.. (Which is probably why Microsoft didn't include it in VB2010.)

Thanks everyone.. Not the answer I was hoping for, but good advice.