Sure! Almost anything would have been a better solution. However, no one knew how the system actually worked, and we were on a shoestring budget.
See, the situation was that IT management, who officially had the responsibility for the PC saw it as a risk because we in IT were unable to do anything if the system died. But the production line management, who had to pay for the upgrade, saw no reason to do it because it was "working fine!".
Sure it was working fine, and had been for almost 20 years. But WHEN it would inevitably give up the ghost they would be completely hosed.
For RS232 connected to a PLC I would assume it to be comparatively easy. Maybe it is not, but it is probably easier than for modern usb or network attached devices, since you can easily spy on transmitted data.
I would also assume that the PLC just gets some commands from the master.
What are you going to do with just the transmitted data? That's just a tiny part of operations, when the machine is working correctly. What if something breaks? Do you know what all the possible error states are? What does the machine have to do if it gets an eg. "machine on fire" alert? Does your software even recognize the data sent by the machine, if it hasn't been sent before and correctly recognized?
Sniffing a protocol to reverse engineer stuff, is like trying to learn a new language by listening to conversations of a ground-level monitor and a crane operator.
You can download the program from a PLC that supplies the logic aside from labels and comments, if that isn't available anymore. Some PLC even supply the complete project, but that is unlikely on such an old device.
Modern USB/TCP connected PLCs just encapsulate RS-232 data into USB or TCP packets, nothing else (for backward compatibility). Also there are encapsulation and decapsulation devices which enables archaic PLCs and other industrial devices to be retrofitted to more modern systems.
Moreover, the OP noted that emulation speed was at critical importance so, the code is CPU speed sensitive. Missing specs, missing company, missing source plus time sensitivity makes this endeavor very risky if not hard.
It might be easy if they had a detailed (and accurate) spec to work to, a good test environment that mimics the current production one sufficiently, and time/money for the required dev/devtest/qa cycles. It sounds like they had none of the above.
That said, as long as it works...