ROS 2 vs ROS 1 Migration for Production Robots

ROS 1 Noetic reached its official end-of-life on May 31, 2025. The GitHub repository holding the ROS 1 core packages is now archived, and no further security patches, bug fixes, or updates will follow. A deprecation warning gives a team a runway, a window where the old thing keeps working while people migrate at their own pace. This is not that. There is no extended community support track for Noetic the way earlier ROS 1 distributions once had, and the cutoff is firm rather than advisory. Any vulnerability found in ROS 1's communication stack or core libraries after May 31, 2025 stays unpatched permanently, which turns every day a production robot spends on ROS 1 into accumulated, unaddressed risk. The robotics industry has already built its own deadlines on top of this one. PAL Robotics announced that starting April 1, 2026, official software support for its robots moves exclusively to ROS 2, with hardware maintenance continuing as before, and that systems still running ROS 1 Noetic fall outside Official Software Support after March 31, 2026, even though existing SLAs and contracts remain intact. Robotnik has issued a similar call to migrate, telling teams to check sensor and component compatibility with ROS 2 and review their control PC specifications before making the move. None of this leaves room to treat ROS 2 adoption as optional polish. It is the only path left that keeps a production robot on maintained, patchable software.

What ROS 1's Architecture Could Not Do

The urgency behind the end-of-life date traces back to decisions baked into ROS 1 from the start, not to any sudden policy shift. ROS 1 was built around three assumptions that rarely hold once a robot leaves the lab: that it runs on a single machine, that its network is reliable, and that nothing on board needs real-time guarantees. Each of those assumptions quietly limited what a production system could do. The rosmaster process is the clearest example. Every node in a ROS 1 system registers with rosmaster to find and talk to its peers. This makes rosmaster a single point of failure: if it goes down, the entire robot stops working, and nothing in the architecture brings it back automatically. Communication between nodes ran over custom protocols, ROSTCP and ROSUDP, that had no built-in quality-of-service controls, no encryption, and no authentication. That setup was fine for a university lab running on a trusted local network, but it left any networked deployment or multi-robot fleet structurally exposed. And because every callback in ROS 1 executed inside a single-threaded spinner with scheduling that could not be predicted in advance, the platform never offered real-time guarantees of any kind. That one constraint alone ruled ROS 1 out for safety-critical work and industrial motion control from day one, long before the end-of-life date gave teams a reason to leave.

How ROS 2 is architecturally different: DDS, the executor model, and the security layer

The biggest change in ROS 2 is the removal of rosmaster and the custom protocol stack in favor of DDS, the Data Distribution Service. DDS is an industry standard, and it works as a fully decentralized, peer-to-peer publish-subscribe system in which nodes find each other dynamically through RTPS over UDP multicast. No central registry, no single process that can take the whole system down with it. DDS did not originate inside the ROS project. It already runs in aerospace and defense systems, and that history is part of why ROS 2 can point to its communication layer as something with an industrial track record rather than an untested promise. Teams building on ROS 2 also get to choose which DDS implementation fits their project: Fast DDS from eProsima ships under an Apache 2.0 license and serves as the default for general use, Cyclone DDS from Eclipse offers lower latency and is the implementation recommended for Nav2, and Connext DDS from RTI is a commercial option aimed at safety-critical and certified systems. A newer addition changes the calculus for wireless deployments specifically: Eclipse Zenoh became Tier 1 middleware in ROS 2 Kilted Kaiju, and unlike DDS it works natively over Wi-Fi, 5G, and low-bandwidth links without the discovery overhead that DDS carries, which speaks directly to long-standing complaints about running DDS across wireless links and multi-robot fleets. Alongside the middleware change, ROS 2 replaces the single-threaded spinner with an executor model that gives teams a choice of single-threaded, multi-threaded, or static single-threaded execution, and lets nodes run in true parallel across multiple cores rather than queuing through one thread. Real-time behavior gets support through PREEMPT_RT kernel integration and the rclc client library, written in C for microcontrollers running FreeRTOS, Zephyr, or NuttX, while micro-ROS extends ROS 2 nodes down onto hardware like the ESP32 and STM32 through a lightweight client that talks to a host-side agent. Security moves into the middleware layer itself, with authentication and encryption mechanisms that simply did not exist in ROS 1. That security layer needs active attention from whoever deploys it: encryption and signing are turned off by default, and a team has to enable them deliberately rather than assume ROS 2 is locked down out of the box. On top of all of this, ROS 2's quality-of-service policies let a team configure reliability, durability, deadline, and liveliness settings per topic, so a safety message and a logging stream moving through the same system can be treated according to how much they actually matter.

Where ROS 2 still requires deliberate engineering work

None of this makes ROS 2 a system that runs itself. The added capability comes with added failure modes, and a team has to design around them rather than assume they come handled by default. Hard real-time performance on a standard Ubuntu kernel is still out of reach: certain kernel code paths are protected by non-preemptible spinlocks, so a high-priority real-time thread can get blocked for an unpredictable stretch by something as mundane as a Wi-Fi interrupt or a disk flush. Running ROS 2 on an unmodified Linux kernel is not enough for hard real-time control; that requires a PREEMPT_RT-patched kernel or dedicated hardware built for the job. The most common architectural bug engineers run into is a QoS mismatch between a publisher and a subscriber. When their settings are incompatible, DDS blocks the connection right at the discovery phase, and the only sign is often a single log line naming the policy that failed to match, easy to miss in a busy log stream and one of the harder failure modes to track down after the fact. The ros1_bridge tool, meant to let ROS 1 and ROS 2 systems talk to each other during a transition, carries a limitation that catches teams off guard: ROS 1 cannot run on Ubuntu 24.04 (Noble), so ros1_bridge has no support there either. Teams running Jazzy or Kilted on Ubuntu 24.04 cannot use the bridge natively and have to fall back on containerized workarounds instead. Mixing DDS implementations from different vendors within one system is not guaranteed to work cleanly either, and edge cases appear once a deployment spans multiple vendors. And specialized real-time hardware, whether that means FPGAs, RT-patched kernels, or high-end GPUs, adds cost and can tie a team to a particular vendor, a real constraint for any migration running on a fixed budget.

What changes at the code and tooling level when porting from ROS 1 to ROS 2

Moving a codebase from ROS 1 to ROS 2 is a rework of the whole system rather than a line-by-line port. Build infrastructure, APIs, data formats, and the tools operators use day to day all change at once. The node API shifts from ROS 1's function-based rospy and roscpp to class-based rclpy and rclcpp, both built on the rcl C library, and state that used to live globally now lives inside each node instance. So that change alone affects how nodes get built, tested, and composed together. A ROS 1 node written as a loose collection of functions sharing global state becomes, in ROS 2, a class with its own constructor and its own instance variables, which makes the resulting node far easier to unit-test and reuse, but it also means every node that leaned on global rospy state has to be rewritten rather than simply recompiled. Recorded data needs attention too: ROS 2 rosbags use a different serialization format from ROS 1, so existing ROS 1 bag tooling cannot read ROS 2 recordings, and any archive of old logs or replay workflow built around them needs to be evaluated and, in many cases, converted. Robot description files bring their own friction. URDF and XACRO files often carry small inconsistencies that ROS 1 quietly tolerated but ROS 2 does not accept, and the JetAuto migration case study treated URDF and XACRO cleanup as its own distinct task, separate from and alongside the build system and API work. Hardware has to be checked independently of the software. Robotnik has pointed out that some sensors and components may be discontinued or may never receive updated ROS 2 support, which makes a hardware compatibility audit something to do before migration starts, not something to discover partway through it. Control PC specifications, covering processor, RAM, and storage, deserve the same review against ROS 2's requirements, especially for any workload that touches real-time control. The good news for teams doing this work in 2026 is that the ecosystem gap has mostly closed where it counts most. ros2_control's Jazzy documentation lists manufacturer-backed, officially supported drivers for robots from Fanuc, Universal Robots, Franka Robotics (the FR3), Clearpath Robotics, Denso, and Mitsubishi MELFA, among others, and MoveIt 2 is now a full-featured, actively maintained motion planning framework across ROS 2 Humble, Jazzy, and Kilted 00.

Choosing a ROS 2 Distribution to Target

Choosing a landing distribution is itself a migration decision, and getting it wrong means doing this work twice. As of mid-2026, four ROS 2 distributions are active, and which one fits depends on where a team already stands and what Ubuntu version its hardware runs. ROS 2 Humble Hawksbill is a long-term support release reaching end-of-life in May 2027 on Ubuntu 22.04, and it remains the right baseline for teams already running production systems on Humble; that 2027 end-of-life, however, means a further move to Jazzy or Lyrical cannot be put off indefinitely. ROS 2 Jazzy Jalisco, also long-term support, runs on Ubuntu 24.04 with end-of-life in May 2029, and it is the distribution most new migrations should target, since ros2_control's official manufacturer integrations are documented on it. ROS 2 Lyrical Luth, released May 22, 2026, is the newest long-term support distribution, running on Ubuntu 26.04 with end-of-life stretching to May 2031, the longest runway on offer, though support for Ubuntu 26.04 across the broader tooling ecosystem is still catching up. PAL Robotics gives migrating teams a concrete reference point here: its supported baseline is ROS 2 Humble on Ubuntu 22.04, available from the March 2026 release, version 26.03, onward. One team recently completed a full migration straight from ROS 1 Noetic to ROS 2 Kilted Kaiju, skipping Humble and Jazzy entirely, specifically to position itself for Lyrical Luth as the next long-term support release. That path works for a greenfield-style migration with enough engineering capacity to move fast, but Kilted's end-of-life in December 2026 puts a short clock on it. The availability of ros1_bridge adds another constraint to this decision. Jazzy, Kilted, and Lyrical all run on Ubuntu 24.04 or 26.04, and ros1_bridge does not work natively on either, so any team that needs bridge-based coexistence during its transition has to either containerize ROS 1 or stay on Ubuntu 22.04 with Humble until the transition is complete.

Two proven migration strategies: full cutover versus slow bridged transition

Picking between the two migration patterns that have worked in production is a practical decision, not a philosophical one. It comes down to the size of the codebase, how complex the hardware is, how much engineering capacity the team has on hand, and how much downtime the organization can tolerate.

A full cutover works by freezing ROS 1 development entirely, porting every package to ROS 2 at once, and validating the result in simulation before anything touches physical hardware. This path suits a team with a smaller codebase, strong engineering bandwidth, and the organizational room to pause feature work for the duration of the port. It avoids the overhead of running two systems side by side and skips the ros1_bridge limitations on Ubuntu 24.04 described earlier, because there is no interoperability period to manage. The tradeoff is concentration of risk: everything changes at once, and the team needs thorough simulation coverage and a rollback plan before it ever puts a cutover robot into a production environment.

The slower, bridged approach runs ROS 1 and ROS 2 side by side using ros1_bridge, porting packages incrementally while keeping a working system running throughout. This suits larger codebases, fleets with hardware that can't all be validated on ROS 2 at once, and organizations that cannot accept a hard freeze on ROS 1 development while the port is underway. It demands the Ubuntu version discipline described in the distribution section: because ros1_bridge does not run natively on Ubuntu 24.04, a team taking this route needs to either containerize ROS 1 or stay on Ubuntu 22.04 with Humble for as long as the bridge period lasts. Each pattern leads to the same place: a production robot running fully on ROS 2 with ROS 1 retired, and each has already proven itself with real teams and real hardware, not as a theoretical option.