I will definitely state up front that I don't know much about either serial or parallel specifications. I'm very open to being proved wrong, but to my simple way of thinking I just can't see how this is possible.
In your current set up your application sends to a COM port, which physically gets sent over a USB cable but gets adapted back to its original serial stream at the other end. It's effectively serial to serial communication, just with a different cable in between (no different to the adapters that let you adapt serial to Ethernet then back again). And from what I've read in the past few minutes, serial-to-parallel is quite possible (if a little fiddly) to do. Since your current printer has a parallel port (and this is the salient point), it can interpret the signal that's coming in and knows what to do with it. So I see why your current set up works.
Your new printer does not have a parallel port though. So while you can no doubt get cabling to take your applications serial output and get it to go into your new printer over the Ethernet (or USB) cable, how can you get the Ethernet printer to make sense of what's coming in? I know that the USB-to-serial cables only work one way, and serial-to-Ethernet adapters look to be the same. And from what I can tell there are no devices on the market that do what you want. That suggests pretty strongly to me that I'm right, meaning what you want to do isn't possible.
So where from here? If it were me, I would run Hyperterm and watch the output when you print from your application. If you are really lucky what you see will be all plain-text. If that were the case, I would find or write software that takes the stream of output and saves it to a .txt file in a directory somewhere. You could then write a helper program that looks for new files in this directory. Any time if finds one it prints it to your new printer, then deletes (or archives) the .txt file. If you need to write the software, then you should be able to skip the middle step and just print the text to your printer directly.
If you are less lucky you might see a bunch of plain text, with undecipherable binary in-between. This binary will be information that the printer interprets; things like "start printing in bold now". If it were me, and if it were acceptable, I think I would write a program that strips out the binary and prints the plain text that's left. You wouldn't end up with a well-formatted page, but you would have all the content. If you contact the manufacturer of your old printer they may be kind enough to provide the specification. If not, and if you were persistent you may be able to figure out what the binary codes mean yourself. If you could figure out the 'start bold' and 'end bold' markers for example, you could then replace them with b and /b HTML tags and output to an .html file instead of .txt. Figure out enough and you can format your reports properly.
If you are unlucky you will see lots of binary code in Hyperterm. This might be because graphics are used (these were typically proprietary specs in old serial printers, so good luck interpreting those!).
If you get all binary code, it's likely that Hyperterm is not set up right (wrong baud rate etc). It could also mean that your application is not outputting ascii.
How far you go with this will depend on the cost of change of the application or printer. Personally I wouldn't go past the stage of figuring out binary codes and converting the output to HTML. That's more than messy enough. If graphics are involved then I'd say the task at hand is near impossible.
Don't be afraid to go back to management with an honest report of the situation. I know you said it's not possible to change application or printer, but it is always possible. If you said "it's impossible to get these new printers talking to our old software" management would definitely change one or the other. If you think management might not believe you, then I'd recommend contacting a reputable software company in your area and have them quote the cost to implement the serial-to-txt/html-to-new printer application. The cost of building that application would likely give them incentive to replace either the app or the new printer. And if not - at least it's not your responsibility to code this horrible interface!
