One of the messier problems is when a machine is technically networked, but not really part of the plant network. It has a controller. It has an IP scheme. Maybe there is a switch in the cabinet. Maybe there is an HMI and a PLC talking to each other just fine. But from the plant side, it might as well be on an island.
The clean answer is to readdress everything and put it on the right network. Sometimes that is right. A lot of times it is not the first move. The machine is running. The OEM settings are weird. Nobody wants to break HMI communication. There may not be drawings. The person who set it up is gone. Also, the goal is not to win a network architecture award. The goal is to collect useful data without making production worse.
That is where a small gateway starts to make sense. One side talks to the machine island. The other side talks to the plant network. It can be a dual-NIC industrial PC, a small edge device, or something purpose-built. The important thing is not the box. The important thing is respecting the boundary.
The constraint is that this can get ugly fast if nobody documents it. Fifty machines means fifty little exceptions. Some may have the same private IPs. Some may have different controller families. Some may need NAT. Some may only expose a few tags. The gateway solves access, but it also creates something new to maintain.
What I would check first is the actual machine architecture. Not what the kickoff deck says. What is in the cabinet? What IPs exist? Is the HMI talking to the PLC directly? Is there a managed switch? Is there a free port? Does the OEM support data access? Can I read without writing?
The surprise is how often the hard part is not technical. It is deciding the least disruptive path. If I can make the machine visible without touching the running controls, that is usually the first useful step. After that, maybe the network can be cleaned up. But I would rather start with a small, reversible data path than a big readdressing project that never gets approved.