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?

  • 1
    You cannot generalize. Experienced programmers are cheaper than inexperienced in terms of time spent because they know the codebase better.
    – user1249
    Commented Feb 24, 2011 at 12:24
  • 2
    Have you all looked at Visual COBOL? That way you could easily interop with C# when needed (or any .Net or even JVM langauge).
    – Jetti
    Commented Feb 24, 2011 at 12:45
  • 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.
    – Gabe
    Commented Feb 24, 2011 at 13:43
  • @S.Lott: OK, I added it as an answer.
    – Gabe
    Commented Feb 24, 2011 at 17:02
  • Are your COBOL programmers going to have to learn C#? What is the cost associated with that?
    – Ben L
    Commented Feb 24, 2011 at 18:03

6 Answers 6


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.

  • 6
    I'm sorry but your last paragraph is purely your opinion with no reasoning or references given to back it up. The original question is specifically asking for experience or any study. They want facts, not our off-hand opinions. I think your appropriate answer should be "I don't know" and leave it at that. Commented Feb 24, 2011 at 12:40
  • 1
    @Scott - Sorry Scott but I stand by my statement. Common sense alone would tell you this is true. Plus, my experience tells me this. Commented Feb 24, 2011 at 12:57
  • 8
    @Randy Minder - This is the worst problem with subjective sites like this: you've just made a statement with no evidence to support it, a bunch of other people like what you say, so they all come by and vote you up because they want it to be true, and it sits here forever on the internet as the de facto answer for this question. If software development ever wants to be a Profession, it needs to stop allowing this kind of misinformation to propagate. I'm not saying you're wrong, but I'm saying your answer cannot be considered "correct". If you have an anecdote, share it. Commented Feb 24, 2011 at 13:32
  • 9
    I disagree with the feature rich comment. An app that has been running for 15-25 years has features you'll never dream of even if you reverse engineer all the COBOL code. Odds are you'll miss something.
    – JeffO
    Commented Feb 24, 2011 at 14:37
  • 2
    You are actually wrong on the estimate on hundreds of millions of lines of code. The most recent estimates is hundreds of billions of lines of code. Quite a difference!
    – Bo Persson
    Commented Mar 5, 2011 at 22:17

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.

  • 1
    If fixed width stuff gives you trouble, I'd like to recommend FileHelpers, as they have some nifty IO handling. filehelpers.com
    – Tangurena
    Commented Feb 24, 2011 at 14:30

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?

  • COBOL nowadays has quite "intuitive GUIs" afais; it also integrates nicely in VS making that point non-existant. youtube.com/…
    – Rook
    Commented Feb 24, 2011 at 15:00

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.

  • 1
    Your answer is short. That is good as it proves that being less verbose does not make it better.
    – Bent
    Commented May 20, 2018 at 14:31
  • Some languages like APL are notoriously terse, but the development and maintenance time does not drop proportionally with the number of characters saved.
    – Steve
    Commented Sep 1, 2020 at 12:44

For productivity analysis, consider this simple C# LINQ query:

var BestCandidates = DataBase.Applicants
        .Where(apl => apl.LookingForJob == "Y")
        .OrderBy(apl => apl.SkillLevel)
        .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.).

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.