what COBOL platform  are you using? is it an Object Oriented COBOL? is it multi user? is it a distributed system? what is the back end data storage system?

there are different COBOL systems which are not generally compatible with each other, but if your system  is a distributed one, and their components are connected to each other by CORBA, then best strategy is to replace them component by component with java  equals.
this way you will have a COBOL program rewritten in java and you probably hardly use any benefits of java platform.

another strategy may be to re-architect and design the system from scratch and install it in parallel and let users migrate from old system to the new one, this way you will gain more advantage out of Java platform.

there are lots of tools which automatically convert COBOL programs to Java. just search on google for your own version of COBOL.

These are both costly solutions. I suppose the reason behind this migration  needs to be clarified. the problem statement is not clear enough.

If you want to provide a java-based interface to outside of the COBOL architecture, you can design an interface to the existing system. or as it was mentioned by Arash, you may be able to provide a CORBA interface with existing system, otherwise rewriting or rearchitecting are both long term solutions and you have to go through the whole process which will definitely duplication the testing effort of the components that are already written and responding fine (in COBOL). sometimes providing ONLY an interface (Web, J2EE-based, or any other interface) to the legacy system  is a good short term solution and satistfies the big  customer. JCA interface could be one simple solution and you can keep existing reliable part of your COBOL system and avoid duplicate and possible complicated testings.

the reason that most of the companies these days are migrating their COBOL systems is that finding an experienced COBOL programmer is becoming harder and more costly each day.
I am not sure why they want to migrate to java  but may be they don't want to keep COBOL codes in their system  any more.

I agree that new technology brings new functionalities, but the existing legacy system  is already working and migrating all of them into new tech is going to be costly, risky, and time consuming. no one will ever shutdown the running system and install a new one. the best approach that I have ever seen is step by step migration. it is more realistic and the least level of risk is involved. The approach that I am familar with is to prototype pieces of the old system with new tech and run it through different analysis. that will help  to better understanding as how to utilize the new tech and how to migrate.

usually these kind of migration  starts with interfacing with the legacy systems and replacing the current business object one by one and very carefully with the new tech implementation.

there are loads of learning curve involved in every different industry that will show up in such process. but jump right from the old system into a new one just for the sake of it is not really adviced.

I remember, once I read in a book, that once a bug was found in a control tower software of an airport, casing two 747 airplanes to crash. they write a new multi milion dollar system  to solve the bug, but the new systems stability and quality was so unknown and they had too risk many lives to test it so, that they decided to keep the system and train users to handle the situation!

completely understandable. good example you mentioned there. imagining how software can put people's life into danger is really crazy. little bit softer could be in banking system  that might corrupt transaction and securities involved, but some might get heart attach. I've seen people getting excited about new tech but the risk is the biggest challenge.

so going back to the original question, our friend should really clarifies the type of migration  and provide milestones for each step not to impact the serviceability of the running COBOL system. eventually he might get into a full migration. It might also be partial COBOL and partial new tech (whatever that new tech is). there is no straight guideline for that other than prototype, test, and be careful.