Estimated Costs for Translating large VB6 projects to DotNet?

Does anyone have experience with translating a large (1 million line) Inventory/Accounting VB6 system to DotNet? Our contracted translation of smaller projects so far has cost us about $1 per line.. (Inventory systems are quite complex)
Microsoft is on record somewhere as estimating "Over one Man-Year per million lines." That is about 25 cents per line..
We are a "Not for profit" who has provided this software to college graduates free of charge for about 15 years. Our Funding Board has very little money and is concerned that the high Cost of Conversion will mean the death of this software package.
Some real experience and costs would be greatly appreciated.
LVL 5
BrianVSoftAsked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Martin LissOlder than dirtCommented:
Why do you need to convert it?


-------------------------------------------------------------------------------------------------------------------------------
My Articles:
Using the VB6 DebuggerAutomatic Insertion of Procedure Names
A Textbox ActiveX Control That Limits Input to NumbersSpell Check a Textbox
Improved Formatting TagsConditional CompilationDynamically Resize Form Controls

Marty - MVP 2009, 2010, 2011
0
chakkoCommented:
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

0
BrianVSoftAuthor Commented:
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?
0
Ultimate Tool Kit for Technology Solution Provider

Broken down into practical pointers and step-by-step instructions, the IT Service Excellence Tool Kit delivers expert advice for technology solution providers. Get your free copy now.

chakkoCommented:
the msi won't do that.

But Windows 7 (Pro and up versions) (and Windows 8 - I guess) has an XP mode (a virtual machine) which should allow the program to run.

You could just provide a set of good instructions for the people who need to run your application.

http://www.microsoft.com/windows/virtual-pc/download.aspx

http://www.sevenforums.com/tutorials/8247-windows-xp-mode-install-setup.html

Also, I haven't checked on Windows 8 so I don't know about it.
But, I found this page where someone says that the preview release of Windows 8 did run a VB6 application.
there is also some people asking if installing the VB runtime libraries will allow VB6 program to run.  So maybe you should test that out.
http://stackoverflow.com/questions/4221661/vb6-running-on-windows-8

0
kbireckiCommented:
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.



0
BrianVSoftAuthor Commented:
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.
1
kbireckiCommented:
"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.)
0
Martin LissOlder than dirtCommented:
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.
0
kbireckiCommented:
@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?
0
Martin LissOlder than dirtCommented:
I'm not an expert since I still use XP, however here is a thread from VBForums that talks about using VB6 with Win7 and Vista. It doesn't speak to the com issue (if there is one) but I'm sure that a search of the web would give you the answer.
0
kbireckiCommented:
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.
0
Martin LissOlder than dirtCommented:
Let me ask you another question then. why get rid of XP? Is the benefit worth perhaps $1,000,000?
0
BrianVSoftAuthor Commented:
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???
0
Martin LissOlder than dirtCommented:
No doubt you will eventually have to convert or re-write to .net :(
0
GrahamSkanRetiredCommented:
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.
0
VBClassicGuyCommented:
I have a suite of VB6 programs (27 of them) that all run fine on anything from XP to Win7 64-bit. In addition, I use a good number of third-party packages (Wise Installer, ProEssentials graphing, Mabry MIME and mail components, AmyUni PDF components, old version of XZeedZip, and others...some of these came out even before XP!) Plus, I do a lot of deep hardware manipulation that MS has been hiding deeper and deeper from programmers as time goes on. Ihave had NO problems running on ANY current version of Windows.

But, yes, I also heard Microsoft's announcement as Win7 was being released..."We have no current plans to provide VB6 compatibility in Windows 8". But you and everybody else in the world knows there are TONS of VB6 apps still out there. Some very active and even on store shelves. Somehow, someway, MS WILL allow VB6 programs to run on Win8, or there would be such a public outcry you wouldn't believe it. Consumers with VB6 programs installed that suddenly quit working would take that as the "last straw" and make a mass exodus to Apple. And Microsoft knows that...they aren't stupid. It may be a virtual machine, special XP mode, I don't know, but I firmly believe VB6 programs will run on Win8. Now, while I firmly believe VB6 apps will be able to run somehow on Win8, that doesn't mean I am NEAR as confident you'll still be able to DEVELOP them on Win8...
0

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
kbireckiCommented:
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.
0
BrianVSoftAuthor Commented:
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..
0
kbireckiCommented:
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.

0
BrianVSoftAuthor Commented:
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.)
0
kbireckiCommented:
Hmm, if this is such an unusual case as it appears, there must be something radically different than "typical" cases.  Maybe in this case, you could think you'd justifiably point to MS's radical departure from VB6 to the dotNet framework concepts as being the reason(s) this would require so much work *without*  the implied improvements, effectively say it's _not_ worthwhile to make the change.  Using the COBOL example again, going from version X to X+1 at any given level probably wasn't as much of a departure as the change from VB6 to dotNet x.whatever.  And I remember this being such a challenge *because* of the significant differences.  I took it as MS deciding/acknowledging they weren't going to able to please everyone, and became committed to dramatically "improving" what was a lot of separate languages - and I think they achieved their goal, but it did at the expense of people like myself, and groups like yours that didn't see the value in making the investment required at the time to switch.  In my case it was because I was in such a small company (< 10 people), in your case because it was such a long term investment already in place.

But I see at least two things that have come up so far from all of this discussion to help you with your backers:
1) You got that important confirmation (the "needs analysis") that gives you confidence that a 75% or better rewrite is necessary and the old model of a "5-10% rewrite cost" does not apply.  So using any count of lines as a basis is also not likely to be valid.  Use your analysis to create a second phase RFP to plan a reasonably accurate second phase implementation.  It should include time and dollar restrictions, goal monitoring, project management performance requirements and appropriate penalties for the winning developer.  This is what your backers will be able to sink their teeth into and get good value for the info/project.  *And* it shows that the rough and ready old formula's based on old methodologies don't apply.  You're going the right way with these concepts.

2) I'm surprised the assessments of costs so far on the small sectional changes you did were also still $1/line.  This seems to counter #1 above.  We must be missing something in the analysis (granted, I'm far from the details and you know that better than any of us), but assuming same-to-same feature-wise, you should see vast improvements in abilities with newer technology.  What this statement of " The cost was always about $1 per line" seems to say, again, is that old methods from however many years ago _are_ accurate -  generated code at $1/line (the old formula) compared to modern development languages, even though they are easily more capable with less effort, are still generating the same cost-results of $1/line with the same feature output.  To be clear, I read this as you saying that the old code with certain feature set rewritten still follows the old model, meaning the newer languages are *not* offering any improvement in development effort reduction|features|etc.  In other words, you should either see fewer lines of code than the old code to get the same features (effectively creating an improved performance per line count), or you should see 1:1 of old lines to new lines, but and improvement of features/capabilities, effectively creating another kind of improvement per line.  (Did I explain that clearly?)

However, maybe there is another assumption in there we're missing.  For instance, maybe the costs are still based at $1/line, but features, capabilities and *volume* of lines is less, thus reducing your overall costs.  It would take a spreadsheet (my favorite analysis tool) to compare old and new and flesh out these variables.  I love doing those types of things!  Most people don't know how to break down things into bite-size chunks to get a true apples-to-apples comparison.
0
BrianVSoftAuthor Commented:
Seems like no answer to my initial question.. Lots of food for thought tho..
I thought there would be many "case examples" of VB6 Experts who have converted their Business Systems (Debtors, Creditors, Inventory, Gen.Ledger Etc.) to DotNet.. It seems those with such systems - like our local legend "ClassicGuy" - are staying with VB6?
After reading the above advice, and a lot of other research, our backers are unanimous that they can't afford to upgrade to DotNet..
Our Asian manager brings up another valid point.. He insists that a DotNet product would not be welcome in most provincial areas (India is our biggest market) He says many provincial PC sellers will refuse to warranty any PC with the framework on it, and they won't sell or support any software based on DotNet. In his words "Plenty of great Delphi and VB6 Apps available - no need for 250mb footprints". Download speeds for 80% of the world are equiv to a 100k modem with dropouts every 5 minutes. Framework updates are out of the question.. (Most Indian users are on XP and will be for years to come.)
0
BrianVSoftAuthor Commented:
Thanks everyone.. Not the answer I was hoping for, but good advice.
0
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Visual Basic.NET

From novice to tech pro — start learning today.

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.