2

We are working on replacing 5 million lines of cobol with Java. Apparently this cannot be done without significant cost.

We have estimated it will cost 70000 man hour days to convert it all to Java. However, resources for cobol are becoming scarce, and we are running into problems with maintenance and enhancements. Funds are also short. We have estimated the cost.

How would we manage this project?

Improve this question
2
  • The question appears to be how to estimate the cost of a (fairly common) project. What kinds of reference estimations and techniques exist? What are the parameters that will affect the estimate? What are the cost drivers. The title is distracting- it makes it sound like the question is out of scope. In my opinion the body of the question is probably in scope.
    – MCW
    Jun 17, 2015 at 18:56
  • I edited this to try to make it less broad. Overly broad questions aren't a good fit for our Q&A format. Also, I removed anything asking if anyone has experience with the problem. Since this isn't a discussion forum, you should just ask your question, and if someone has experience they'll answer. This question still in its current form may be a bit broad for our format, but I'll leave that to the community to decide. Hope this helps.
    – jmort253
    Jun 18, 2015 at 13:56

1 Answer 1

Reset to default
2

Can I ask if anyone has been in a company who has replaced over 5 million lines of cobol with Java and how was the project managed.

I worked for an organization that looked at replacing legacy systems several years ago. The decision was taken to "start again". The primary driver was to address shortcomings in systems that were developed in the 1970s and were not flexible enough to adapt to changes in the market place. It was treated as a series of standard IT projects, which unfortunately led to some gaps in terms of user engagement, coordination of projects, missed requirements, etc etc.

There was a lot of pressure to get something done "now", which contributed a lot to the problems that were faced. Hindsight being 20/20, if you want to go down the path of refreshing your systems a better approach is to take the time to define exactly what the systems do (factoring in not only the original design but also however many years of minor enhancements you are dealing with), identifying the gaps between what they did and what you want them to do, and coming up with a comprehensive list of requirements for all components of the program before starting any development work.

Apparently this cannot be done without significant cost.

That was pretty much our experience. But if you don't spend the $$ and time to do it right you will pay more in the long run from not only a systems re-work perspective but also from an employee satisfaction, customer satisfaction and reputation perspective.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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