Blog 

1. Freeze the legacy system before choosing a replacement

Do not start with a new-board shortlist. Start by recording what the current system actually depends on. A complete baseline should be sufficient for another engineer to rebuild the old unit, reproduce its normal operation, and identify every connection to the field equipment.

Software baseline

• CPU mode and application architecture: 32-bit i386 or 64-bit amd64
• Distribution, release, kernel version, bootloader, partition layout, and filesystem
• Application binaries, source availability, build toolchain, shared libraries, services, scheduled jobs, and configuration files
• Kernel modules, out-of-tree drivers, firmware blobs, license servers, USB dongles, and hard-coded device paths
• Direct port, register, or memory access performed by the application
• Data locations, retention rules, log rotation, database consistency, and backup/restore procedure
• Startup order, shutdown behavior, update mechanism, remote access, and rollback method

An x86-64 processor does not by itself guarantee that an old 32-bit application will run. Debian's amd64 port provides a 64-bit user space, while Debian Multiarch can install i386 packages alongside amd64 packages. Multiarch helps when the required 32-bit packages and libraries still exist; it does not make a proprietary kernel module, an unsupported installer, or direct access to old hardware portable.

Kernel dependencies deserve their own gate. Linux deliberately does not promise a stable in-kernel binary interface for external drivers, as explained in the kernel documentation on the stable API and in-kernel ABI. If the old system relies on an out-of-tree module, obtain its source and confirm that it builds and behaves on the target kernel. Otherwise, budget for a maintained replacement driver or keep the old kernel and hardware in the transition path until that dependency is removed.

Hardware and I/O baseline

For every connector and I/O channel, record more than the label on the enclosure:

• Bus or logical function: serial, GPIO, Ethernet, storage, USB, ISA, PCI, PC/104 family, or another expansion bus
• Physical connector and pinout
• Electrical standard and levels: TTL UART, RS-232, RS-485, isolated digital input, open-drain output, and so on
• Direction, polarity, pull-up or pull-down, termination, biasing, isolation, and grounding
• Device name, address, chip select, baud rate, framing, protocol, and message timeout
• Startup state, safe state, error state, and behavior during reboot or power loss
• Normal rate, burst rate, response deadline, tolerated jitter, and recovery timeout
• Cable length, field noise, surge/ESD requirements, and regulatory constraints

Also capture the board outline, mounting holes, connector clearance, cooling path, power input, peak load, enclosure airflow, service access, and every external cable. A board that boots the application can still fail the migration because a mounting point, voltage level, or power-loss behavior changed.

2. Choose the least disruptive migration path that can be verified

The correct path depends on which parts of the compatibility contract are hardest to change.

If the migration also changes the relationship between the compute module, carrier, and finished board, use the separate SOM versus SBC decision guide to evaluate ownership of carrier design, connectors, and qualification. Those form-factor choices are related to migration, but they do not replace the compatibility checks in this guide.

Legacy expansion names must be checked at the specification level. The PC/104 Consortium lists PC/104, PC/104-Plus, PCI-104, PCIe/104, and PCI/104-Express as distinct specifications. A shared family name or stackable shape is not proof that an old card will work on a new host. Verify the actual bus, connector, keying, voltage, interrupt, DMA, and software-driver requirements.

A bridge is useful only when it preserves the behavior the old card needs. Measure end-to-end latency and failure recovery through the bridge under realistic load. Do not assume that a converter described as “transparent” preserves interrupt timing, ordering, or device identity.

3. Prove software continuity on the target x86 platform

Build a clean test image rather than cloning the production disk and treating a successful boot as acceptance. The test should reveal exactly which dependencies are native, which are supplied by a compatibility package, and which are still tied to the old board.

Use this sequence:

1. Install the intended distribution, kernel, firmware, and boot configuration on the target storage.
2. Recreate the application user, permissions, services, libraries, locale, time synchronization, and data paths from the recorded baseline.
3. Run the original user-space binary with representative input and compare its output against the old system.
4. Load and exercise every required driver. Reboot repeatedly and confirm deterministic device discovery.
5. Test clean shutdown, abrupt power loss, filesystem recovery, application restart, backup restoration, and rollback to the previous image.
6. Repeat the tests after applying the update procedure that will be used in service.

Virtualization or a container can preserve an old user space when the application is not tightly coupled to hardware. It does not automatically solve access to a physical serial controller, GPIO line, ISA card, watchdog, or real-time interrupt path. Include the hypervisor, device passthrough, host kernel, and bridge in the compatibility contract and in the timing tests.

Binary compatibility is therefore a gate, not a product feature that can be inferred from “x86.” Pass it only when the exact application, libraries, drivers, data, and boot/recovery sequence have been tested together.

4. Map serial I/O by protocol, electrical layer, and timing

“UART” is not a complete interface specification. A logic-level TTL UART is not electrically interchangeable with RS-232 or RS-485. The migration record should identify the transceiver, voltage levels, connector pinout, isolation, termination, duplex mode, direction control, and protocol timing for each channel.

For Linux RS-485, the kernel exposes configuration through TIOCGRS485 and TIOCSRS485, but support depends on the serial driver implementing the required callbacks and advertising the supported features. The official Linux RS-485 documentation also shows that RTS behavior and delays before and after transmission are part of the configuration. Consequently, a USB or TTL-to-RS-485 adapter is not proven equivalent until its driver, direction control, turnaround delay, termination, biasing, and isolation have all been checked.

For each serial channel, validate:

• Stable device identity across cold boots, reboots, and reconnects; use persistent rules or application-level mapping instead of assuming /dev/ttyUSB0
• Baud rate, data bits, parity, stop bits, flow control, and application timeout behavior
• Full message exchange at normal and worst-case traffic, including bursts and simultaneous channels
• Disconnect, short frame, checksum error, cable reconnection, and field-device restart behavior
• RS-485 turnaround, collision handling, bus idle state, termination, biasing, and isolation where applicable

Record results at the protocol boundary the application uses. A loopback test proves that bytes can move; it does not prove that the full field network, timing, or fault recovery is equivalent.

5. Remap GPIO by function, not by old line number

Linux GPIO identities can be derived from Device Tree, ACPI, or platform data, and the mapping may include semantics such as active-low or open-drain. The kernel's GPIO mappings documentation is a reminder that the board description is part of the interface. Copying an old global GPIO number to a new controller is not a migration plan.

For user-space access, current Linux provides the GPIO character-device interface through /dev/gpiochipX and line requests. The GPIO character-device v2 documentation describes line attributes, edge events, debounce, and event clocks. It also warns against using user-space GPIO to replace a proper kernel driver for a function already supported by the kernel.

Create a functional map for each line:

Run GPIO tests from power-on through application startup, normal operation, process crash, reboot, and power removal. Industrial outputs must reach a defined safe state even when the application does not start.

6. Treat real-time behavior as a measured contract

A newer CPU can reduce average execution time while still missing a field deadline because of interrupt routing, firmware, storage activity, network load, thermal management, or power-saving states. Preserve real-time behavior by recording deadlines and measuring worst-case latency on the complete target system.

If the application requires deterministic Linux scheduling, evaluate the PREEMPT_RT real-time preemption path together with the target kernel and drivers. The official rt-tests repository documents tools such as cyclictest and hwlatdetect, but a tool name is not an acceptance result. Define the workload, duration, CPU load, I/O traffic, temperature condition, power settings, and maximum permitted latency before running the test.

The acceptance record should include:

• Application deadline and allowed jitter, expressed at the actual field I/O boundary
• Kernel version and configuration, firmware/BIOS version, CPU affinity, IRQ placement, and power-management settings
• Concurrent serial, network, storage, and GPIO workload
• Test duration and environmental condition
• Maximum observed latency and missed-deadline count, not only the average
• Recovery behavior after overload, link failure, device reset, and power interruption

If a bridge or gateway sits between the application and the field device, measure the complete round trip. Testing only the SBC scheduler excludes part of the system being certified.

7. Verify reliability, serviceability, and lifecycle separately

After functional parity, test the operational behaviors that determine whether a unit can be deployed and recovered remotely:

• Power-on mode after AC restoration and behavior after brownout or repeated power cycling
• Watchdog implementation, trigger conditions, timeout, reset scope, and recovery logging
• Boot-device priority, corrupted-primary-storage recovery, image rollback, and spare-unit provisioning
• Network naming, link recovery, DHCP/static addressing, firewall rules, VPN, time synchronization, and dual-link behavior if used
• Storage endurance assumptions, write amplification, log growth, free-space alarms, and database recovery
• Cooling, throttling, enclosure temperature, input tolerance, grounding, EMC, vibration, and connector retention under the project's actual requirements
• Target-board, adapter, storage, and transceiver availability; revision-control and end-of-life notification terms
• Regulatory and safety impact of every changed board, power supply, enclosure, cable, and isolation component

Do not infer these properties from the processor family. Require a datasheet, supplier commitment, certification record, or project-specific test for each claim that affects deployment.

8. Use staged acceptance instead of a one-time swap

A low-downtime migration uses evidence gates and retains a working rollback path:

“The application starts” is an early bench result. Migration acceptance requires behavioral parity under normal load, worst-case load, faults, reboot, and power loss.

9. Conditional worked example: evaluating the youyeetoo K1

The youyeetoo K1 Wiki identifies an Intel N100 x86 platform with Windows 10/11 and Ubuntu/Debian support, dual Gigabit Ethernet, eMMC plus NVMe/SATA and SATA 3.0 storage options, and TTL UART, I2C, SPI, and GPIO interfaces. The Wiki also provides configuration or tutorial entry points for watchdog use and power-on mode. These public capabilities make K1 a candidate for the compute, networking, storage, and low-level I/O portions of a legacy x86 migration. The broader K1 embedded integration guide covers the platform outside this migration-specific checklist.

Important boundary: These public capabilities do not establish that K1 is a drop-in replacement for a particular industrial system. Before selecting it, the project still has to verify:

• Whether the legacy application and all required libraries run on the selected Windows or Debian image
• Whether every required kernel module or device driver is available and maintainable
• Whether the available TTL UART channels, external RS-232/RS-485 transceivers, isolation, connectors, and timing match the field network
• Whether the GPIO electrical interface, startup state, polarity, and line mapping meet the machine requirements
• Whether watchdog and power-recovery behavior meet the project's fault model
• Whether mechanical fit, power, cooling, environmental, lifecycle, regulatory, and real-time requirements pass project-specific tests

Specification check required: The current K1 Wiki contains conflicting UART counts in different sections, so the count should be confirmed for the exact hardware revision before design freeze. Its public specifications also describe UART as TTL; they do not prove native RS-485 or CAN. No published evidence cited here demonstrates compatibility with a specific legacy Debian image, proprietary driver, or PREEMPT_RT deadline.

That is the right standard for any candidate board: map public capabilities to the baseline, expose every unknown, and approve the hardware only after the complete system passes the compatibility contract.

Final migration checklist

Before replacing the production SBC, confirm that you can answer yes to every applicable item:

• The old image, configuration, application data, and logs can be restored.
• Application architecture, libraries, licenses, kernel modules, and hardware access have been identified.
• Every I/O channel has a documented protocol, electrical layer, pinout, identity, timing limit, and safe state.
• The selected migration path preserves or deliberately replaces each legacy bus and driver dependency.
• Serial and GPIO behavior has been tested across boot, load, disconnect, reboot, and power loss.
• Worst-case application and I/O latency meets a written limit under representative stress.
• Watchdog, power restoration, storage recovery, networking, remote maintenance, and rollback work as intended.
• Mechanical, power, thermal, environmental, regulatory, lifecycle, and supply requirements are backed by evidence.
• Bench, soak, parallel, and pilot stages have passed with traceable results.
• The old system remains recoverable until the new system completes the agreed field observation period.

Preserving a legacy software and I/O stack is possible when its dependencies are explicit and testable. The decisive question is not “Is the new SBC also x86?” but “Does the new system preserve every behavior that the application, field equipment, operator, and safety process depend on?”