I think that there are some things to do before you tackle the technical question "in what technology do I create the documentation".
The true knowledge and understanding of the system is what lies beyond the actual interface relationships and module structures. It is the understanding of the whole system and how the individual parts in it contribute to the whole.
I would go in the following directions:
1) First, Try to understand the system top-down. This means to first understand the structure of the modules and create some representation of them, from the top down.
During this process, you will probably find additional metadata on the modules that does not exist in your current excels. Take the time to add it, it will be most useful when you later create the automatic documentation, because it will reflect the "non-obvious" knowledge on the system structure.
2) Write a simple program that will generate a set of HTML files from the excel. That will help you browse and navigate the information more easily as a starting point for further investigation. I would not go into a fully fledged javadoc format in the beginning. Start small and evolve your program\script in stages, as needs arise.
During this process you would also discover where refactoring would make sense.
3) Use the output of your HTMLs to research structure of several modules and reach understanding of internal patterns of interfaces. Are there naming conventions? Repeated patterns? Anything that you can deduce and is not obviously documented already in the excel.
I would create some local UML diagrams, but not of a size that will get out of hand - perhaps several UMLs per module. Mark dependencies to external modules in a distinct way.
(Again, generation of automated UMLs will not be as useful, it is the hand-picking of meaningful interfaces in each diagram that will make the most enlightening UMLs in the documentation.)
I think the final result of a set of HTMLs and UMLs will be a good final result.