Industrial PC in factories often remain in service far longer than ordinary office computers. The problem is usually not whether the machine can still boot, but that its hard drive, motherboard, interface cards, or other components have already been discontinued. Once a failure occurs, finding an identical replacement can be difficult.
However, replacing an industrial PC is not simply a matter of installing a newer computer. A new system may fail to run legacy software, serial port assignments may change, PLC communication may be interrupted, or existing data acquisition and control cycles may behave differently.
For this reason, replacing an obsolete industrial PC should not begin with the question, “Which new PC has better performance?” Instead, start by understanding exactly what the existing system is doing.
Before shutting down the old system, document four types of information:
One important question is whether the existing software depends on the x86 architecture, a specific Windows version, a USB license dongle, or proprietary drivers.
If any of these dependencies cannot be migrated, replacing an x86 industrial PC directly with an ARM industrial PC may not be practical.
A real legacy-system upgrade provides a useful example. The original machine used a 386 processor and DOS 6.2, mainly for serial-terminal communication and data logging. Rather than replacing the entire system, the maintainer kept the original enclosure, ISA backplane, keyboard, and floppy-based logging method while upgrading the computing board.
Even then, processor instruction-set limitations prevented the latest Linux kernel from running, so an older compatible kernel had to be used.
The lesson is simple: when upgrading legacy industrial equipment, compatibility with the existing system matters more than simply choosing the newest hardware.
Before selecting a replacement, determine whether the application should remain on x86 or can be migrated to an ARM industrial PC.
If the existing system relies heavily on Windows-specific applications, legacy SCADA software, proprietary drivers, USB license dongles, or x86 binary programs, staying with an x86 industrial PC is usually the safer approach.
PUSR USR-EC100, EC300, and EC500 industrial PCs support Windows or Linux and provide common industrial interfaces such as serial ports, Ethernet, and USB. They are better suited to applications where the original PC-based software environment needs to be preserved.
If the old industrial PC mainly performs data acquisition, protocol conversion, edge computing, local control, or cloud connectivity, migrating to an ARM industrial PC may provide more flexibility.
For example, the USR-EG628 runs Linux Ubuntu and provides RS232, RS485, CAN, Ethernet, and USB interfaces. It also supports technologies such as Node-RED and Docker, as well as multiple industrial communication protocols.
This makes it possible to gradually migrate functions that were previously distributed across data acquisition software, protocol gateways, and supervisory scripts into a modern edge-computing platform.
For applications mainly involving RS485 or CAN FD data acquisition with moderate computing requirements, the USR-EG228 can also be considered. With dual RS485, dual CAN FD, and dual Ethernet interfaces, it is well suited to lightweight retrofits involving multiple fieldbus devices.
Whenever possible, run the old and new industrial PCs in parallel during the migration period.
Start by allowing the new industrial PC to read data only, without sending control commands.
Compare:
Once the data acquisition results are consistent, gradually migrate non-critical functions such as data processing, HMI functions, historical data logging, and remote communication.
Control commands should be transferred last.
If the fieldbus does not allow two devices to connect simultaneously, use a planned maintenance window to verify the system interface by interface.
Test RS485 first, then CAN, Ethernet, USB, or other interfaces separately instead of moving every connection at once.
This makes troubleshooting much easier if something does not work as expected.
A low-risk industrial PC replacement usually does not require every device in the automation system to adapt to the new computer.
Instead, the new industrial PC should imitate the external behavior of the old one as closely as possible.
For example:
If the original system communicates over a serial connection, restore the serial communication first.
If other equipment accesses the old industrial PC through a fixed IP address, avoid redesigning the entire network during the same maintenance project.
The fewer external changes you introduce, the easier the migration becomes.
Instead of turning the replacement into a complete automation-system redesign, you reduce the project to a controlled replacement of one computing node.
Before putting the new industrial PC into production, keep a complete backup of the original system.
This should include:
During the initial production period, do not immediately remove or discard the old system.
If unexpected communication instability, driver problems, or control-cycle differences appear after the migration, the original industrial PC should be available for quick restoration.
This is much safer than trying to troubleshoot every possible variable while the production line is stopped.
Replacing an obsolete industrial PC is not primarily about finding a newer computer with higher specifications.
The real task is to identify and migrate the interfaces, communication protocols, software dependencies, and control logic that the existing automation system relies on.
If the application strongly depends on Windows and the x86 software ecosystem, continuing with an x86 industrial PC is usually the more practical choice.
If the main workload has shifted toward data acquisition, protocol conversion, edge computing, and industrial networking, an ARM industrial PC can be a suitable replacement platform.
The safest migration strategy can be summarized in three steps:
Maintain compatibility first, migrate functions second, and optimize the architecture last.
For most automation systems that are already in production and cannot tolerate long periods of downtime, this approach is far less disruptive than rebuilding the entire system at once.
