A serial device server is a networking appliance that puts one or more legacy serial devices onto an IP network, so equipment that only speaks RS-232 or RS-485 can be reached over Ethernet or the cloud. It differs from a simple single-channel converter by offering multiple serial ports and driver-based access, letting host software treat a remote serial port as if it were plugged into the local machine. For sites full of older RTUs, meters, and flow computers, it is the bridge that brings serial equipment into a modern, network-centric monitoring architecture.
Serial Device Server in one line: A serial device server is a multiport appliance that connects legacy serial devices to an IP network, exposing them either as virtual COM ports on a host or as raw TCP sockets. It lets existing software talk to remote serial equipment over Ethernet without rewiring, making it the standard way to network-enable multiple RTUs, meters, or flow computers at once.
A serial device server typically offers two ways to reach the serial equipment behind it. In virtual COM port mode, a driver installed on the host machine creates software COM ports that map across the network to the physical serial ports on the device server, so an application opens what looks like a local port and the driver transparently tunnels the traffic to the remote device. This is invaluable for legacy software that only knows how to open a COM port and cannot be modified to speak over a network.
In raw TCP mode, the device server simply forwards bytes between its serial port and a TCP socket, with no driver required. Software that can open a network socket connects directly to the device server's IP and port and exchanges the same serial byte stream it would over a cable. This mode suits newer applications and is often used to carry serial protocols like Modbus RTU across a network without translation, since the device server just relays the raw characters.
Some device servers add protocol awareness on top, for example bridging serial Modbus RTU to Modbus TCP so an Ethernet client can address the serial slaves natively. The distinction matters: a transparent raw-TCP relay preserves the original protocol byte for byte, while a protocol-aware bridge actively translates between the serial and network forms. Choosing the right mode depends on what the host software expects and whether the protocol needs translation or just transport.
What sets a device server apart from a plain point-to-point serial-to-Ethernet converter is scale and integration. A device server commonly provides several serial ports in one chassis, each independently configurable for its own baud rate, parity, framing, and RS-232 or RS-485 mode, so one appliance can front a whole rack of mixed serial equipment. That consolidation reduces the number of network drops and the amount of gear at a site compared with one converter per device.
The driver ecosystem is the other defining trait. Because the vendor supplies a virtual COM port driver for the host operating system, a device server slots cleanly into existing polling software, SCADA drivers, and configuration tools that were written for physical serial ports. This driver-based model is why the category is often called a terminal server or serial server, echoing the older networking appliances that gave network access to serial consoles.
Configuration typically covers per-port serial settings, the operating mode, and network parameters, and getting the per-port serial settings right is just as critical as on a direct cable, since a mismatch in baud or framing on any port breaks that channel while the others keep working. A well-managed device server also reports per-port status and connection state, which helps when one of several attached devices goes quiet and you need to know whether the fault is the device, the serial link, or the network path.
In a cloud SCADA deployment, a serial device server is a common way to lift a site's existing serial RTUs, meters, and flow computers onto the network so a gateway or the cloud can poll them. Rather than replacing proven field instruments, the operator drops in a device server, wires the existing serial equipment to its ports, and gains network access to all of it at once. The instruments keep speaking their native serial protocol while the device server handles getting that traffic onto IP.
This preserves capital and reduces risk, because a functioning flow computer or meter does not need to be swapped just to be monitored remotely. The serial equipment continues to run exactly as before, and the device server adds a networked front door that a cloud platform can reach through the site's cellular or Ethernet backhaul. For fields with many older serial devices, consolidating them onto a few multiport device servers is often the most economical path to remote visibility.
From the platform's side, the data still arrives as Modbus registers or the relevant serial protocol, whether transported raw over TCP or translated to a networked form. A cloud SCADA system that tracks per-device communication health then makes the whole chain diagnosable, since a device server that surfaces per-port status combined with platform-level last-seen and error tracking lets an operator pinpoint whether a silent point is a failed instrument, a serial mismatch on one port, or a lost network path, all without a trip to the pad.
A single-channel serial-to-Ethernet converter typically bridges one serial port to the network, while a serial device server offers multiple ports and a driver-based model that exposes remote serial ports as virtual COM ports on a host. The device server is built to network-enable several serial devices at once and integrate with existing COM-port software, making it the choice for consolidating many RTUs or meters rather than a single link.
A virtual COM port is a software serial port created by a driver that maps across the network to a physical serial port on a remote device server. An application opens what appears to be a local COM port, and the driver tunnels the traffic to the remote device transparently. This lets legacy software that can only open a COM port communicate with serial equipment over an IP network without being rewritten.
Yes. In raw TCP mode a device server relays the Modbus RTU byte stream transparently over a socket, and some models actively bridge serial Modbus RTU to Modbus TCP so Ethernet clients can address the serial slaves natively. Which approach to use depends on what the polling software expects. In every case the per-port serial settings such as baud and framing must match the attached device.
This page references the protocol specifications published by the organizations below. Editions, product capabilities, and documentation change over time - confirm current requirements and specifications directly with the source.
Last reviewed: July 27, 2026. Merobix is not affiliated with, endorsed by, or sponsored by these organizations; their names are used only to identify the standards and products discussed.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.