We are doing a cost benefit analysis on a migration project.
It would be nice to be able to say that future changes will be x percent cheaper due to the migration.
Does anyone have any experience or know of any study that shows what benefit we could expect?
I don't think it is possible to measure that beforehand, because it depends on too many factors like size of the system, qualification of your programmers, the existing "ecosystem" of your software, the migration strategy and so on. Hell, it may be true that future changes will be more expensive after the migration, it really depends.
Only thing you can do is try to measure the effort for near future changes after they are done and make a guess how much effort you would have had for the same change at the Cobol platform.
You're trying to determine whether it would be cost effective to migrate a COBOL app to C#? I would think that's like asking if it would be cost effective to migrate from a 1972 Ford Pinto to a 2011 Name Your Brand.
On the serious side, this is so much an apples to oranges comparison. You are dealing with a technology that has long past its prime (COBOL), even though there are still probably hundreds of millions of lines of COBOL code still performing quite well. One thing you must consider is how likely you will be in the future in being able to find qualified COBOL developers. Who is studying COBOL anymore? Who wants a career in COBOL anymore? It's a dinosaur as far as software development technologies is concerned.
I can tell you this, it's quite likely that whatever the application is, it will be far more feature rich in C#, be more maintainable, and be more maintainable by more people than your COBOL app(s). If I had to guess, I would say your COBOL app was developed at least 15-25 years ago. Probably 20 different people have worked on it over the those years. Very few people understand what it does. And the code is probably UGLY to look at and understand.
How come nobody has asked "What does the application do?" - this is fundamental!
If it's a front-end appliction, using screens (CICS or MVC) communicating with COBOL programs, there's no doubt it will be easier to maintain in C#, and will probably look a hell of a lot better too. However, it's a big migration from one to the other.
On the other hand, if it's a big batch system designed to process thousands of records, stored in files in fixed-width format, this will be a lot trickier to do in C# (I don't know C#, I'm assuming it's possible, but I think it's probably trickier).
Your cost-benefit should look at the the purpose on the migrated/amended/rewritten system, and decide on the best technology to get the job done.
First of all, you'll need to come up with the cost to rebuild the app with the same functionality. Let's assume you can calculate the difference between a COBOL code change compared to C#. Give C# a 25% discount - why not?
The real question is, how much of the application do you plan on changing? Because even at a 25-50% discount, you have to make major additions to the app to cover the cost of the conversion. If no one has justified necessary additions at this point, I wouldn't bother.
Can you factor in other savings? Ease of replacing C# developers over COBOL. Training new users is faster because of an intuitive GUI? New functionality saves on data entry time and improves integrity. Consolidating hardware. Ease of administration because it is browser based and desktops no longer have to use a terminal emulator?
Generally speaking, a programmer can write X lines of code per day. If a language is less verbose (i.e. C# can do more in X lines of code), a programmer can be more productive in it.
For productivity analysis, consider this simple C# LINQ query:
var BestCandidates = DataBase.Applicants
.Where(apl => apl.LookingForJob == "Y")
.OrderBy(apl => apl.SkillLevel)
.Take(10)
.Select(apl => new { apl.FullName, apl.RequestedSalary });
How many lines of COBOL would it take to write the equivalent? I think it is more than 100 (I know both languages).
You can do a fair comparison with some reporting and processing exercises. Just make sure that the programmers know their languages well. For instance, a good COBOL programmer can defeat a bad C# programmer in some circumstances, especially in performant batch tasks (i.e. COBOL operates on flat files with direct memory access, therefore cannot equally compare to -let say- RDBMs with memory Objects, unless the programmer knows well about indexes, garbage-collector, direct file access, etc.).
