# ROS 2 vs ROS 1: what changed and how to migrate

> ROS 1 reached end of life in 2025. Compare ROS 1 and ROS 2, see what changes in code and plan a realistic migration timeline.

Canonical: https://roboticsengineering.in/ros2-vs-ros1/ | Published: 2026-10-27 | Updated: 2026-10-27 | Author: Jignesh Panchal

**ROS 1 is finished as a supported platform, but plenty of robots still run it.** The practical question in 2026 is not which is better — ROS 2 is — but how much of your stack can move, and what you do with hardware that cannot.

This comparison covers the real differences that affect projects: middleware, launch, parameters, lifecycle, security and migration effort. Numbers and time estimates are indicative, not promises.

## The short answer

Start new work on ROS 2. ROS 1 Noetic reached end of life in May 2025, which means no security patches and no binary updates for new Ubuntu releases. ROS 2 Jazzy is the current long-term support release for most teams, with the next LTS arriving in 2026.

| Aspect | ROS 1 | ROS 2 |
| --- | --- | --- |
| Build system | catkin | ament and colcon |
| Middleware | Custom TCP/UDP transport | DDS with configurable vendors |
| Launch files | XML only | Python, XML and YAML |
| Parameters | Global parameter server | Per-node parameters with callbacks |
| Node lifecycle | None | Managed nodes with states and transitions |
| Security | None built in | SROS2 with certificates and access control |
| Real-time | Limited | Executors and DDS QoS designed for it |
| Platforms | Mainly Ubuntu | Linux, Windows and macOS |
| Multi-robot | Namespaces as a workaround | Namespaces and contexts as first-class features |
| Python API | rospy | rclpy |
| C++ API | roscpp | rclcpp |

## What actually changes in your code

The concepts survive: nodes, topics, services, parameters, TF. The APIs do not. A ROS 1 node that works perfectly needs its includes, initialisation, spin model and message headers rewritten. Plan for a rewrite of the entry points, not a search-and-replace.

| ROS 1 pattern | ROS 2 replacement | Effort |
| --- | --- | --- |
| `ros::init` and `ros::NodeHandle` | `rclcpp::init` and a node class | Small per file |
| `ros::spin()` | `rclcpp::spin(node)` or an executor | Small |
| `ros::param` server | Declared parameters on each node | Medium, touches config design |
| `.launch` XML | Python launch files | Medium |
| Actionlib | ROS 2 actions | Medium |
| Custom message packages | Same ideas, new build files | Small |
| rosbuild or old catkin tricks | Clean ament package | Large if the package is old |

## Why the middleware change matters

ROS 2 does not ship its own transport; it uses DDS. That brings discovery, QoS, and the ability to choose a vendor implementation. It also brings configuration: two nodes that should talk may not, because their QoS settings disagree or their DDS domains differ.

For a single robot on a bench, this looks like extra complexity. For a fleet on a shared network, it is the feature that makes isolation possible: separate domain IDs or namespaces keep robots from hearing each other.

## Migration effort by project type

| Project | Realistic effort | Approach |
| --- | --- | --- |
| Student project, 5–10 nodes | 1–3 weeks | Rewrite on ROS 2; faster than porting |
| Research stack with custom messages | 1–3 months | Port packages one at a time behind a bridge |
| Small AMR fleet, ROS 1 drivers | 3–6 months | Keep drivers, bridge topics, replace navigation with Nav2 |
| Industrial cell with vendor software | Not worth it | Keep the vendor stack; integrate at the PLC or API level |
| Legacy platform with no source | Cannot migrate | Freeze, isolate on its own network, plan replacement |

## If you must stay on ROS 1 for now

- **Freeze the OS image.** Noetic will not receive updates, so keep a known-good image and do not upgrade the base system.
- **Isolate the network.** No security patches means no exposed services. Keep ROS 1 traffic on a dedicated VLAN.
- **Bridge deliberately.** The `ros1_bridge` package lets ROS 2 nodes talk to ROS 1 topics; use it as a transition path, not a permanent architecture.
- **Document the hardware interfaces.** When the controller board or sensor is discontinued, the interface notes are what let you replace it.

## What to learn in 2026

1. ROS 2 command line and workspace layout with colcon.
2. Publishers, subscribers, services and actions in rclpy or rclcpp.
3. Launch files in Python, including arguments and namespaces.
4. URDF, TF2 and robot_state_publisher.
5. Nav2 for mobile robots or ros2_control for arms.
6. Enough DDS to debug discovery and QoS.

That list maps closely to what Indian robotics job ads ask for. Legacy ROS 1 work still exists in older AMR fleets, but new projects and interviews assume ROS 2.

## Mistakes during migration

| Mistake | Result | Better approach |
| --- | --- | --- |
| Porting every package before testing | Months of work with nothing running | Get one node and one topic working end to end first |
| Keeping ROS 1 parameter habits | Hidden global state, surprising defaults | Declare parameters per node and validate them |
| Ignoring QoS | Silent message loss | Set profiles deliberately for sensors and commands |
| Bridging everything forever | Two systems to debug | Bridge only while replacing, with a removal date |
| Assuming simulation ports cleanly | Gazebo classic models break | Rebuild models for the new Gazebo early |

Related: [ROS 2 for beginners](https://roboticsengineering.in/ros2-tutorial-beginners/), [topics, services and actions](https://roboticsengineering.in/ros2-topics-services-actions/), [ROS 2 launch files](https://roboticsengineering.in/ros2-launch-files-tutorial/), [URDF tutorial](https://roboticsengineering.in/urdf-ros2-tutorial/), [Nav2 tutorial](https://roboticsengineering.in/ros2-nav2-tutorial/).

**Is ROS 1 still supported in 2026?**

No. ROS 1 Noetic reached end of life in May 2025, so there are no more security patches or binary updates. Existing installations keep running but should be isolated and planned for replacement.

**Should I learn ROS 1 or ROS 2 in 2026?**

Learn ROS 2. New projects, courses and job listings assume ROS 2. ROS 1 knowledge is useful only for maintaining existing fleets.

**How long does it take to migrate from ROS 1 to ROS 2?**

A small student project can move in one to three weeks by rewriting. Research stacks take one to three months, and production fleets with custom drivers can take three to six months.

**What is the ros1_bridge used for?**

It lets ROS 2 nodes exchange messages with ROS 1 topics during a transition. It is a migration tool, not a long-term architecture.

**Is ROS 2 harder to learn than ROS 1?**

The basics are similar, but ROS 2 adds launch files in Python, QoS and DDS configuration. Most beginners find the first week harder and everything after that cleaner.

## Sources and further reading

- [ROS 2 documentation](https://docs.ros.org/) — current distributions, tutorials and migration guides.
- [REP 2000](https://www.ros.org/reps/rep-2000.html) — supported distributions and end-of-life dates.
- [ROS 2 design](https://design.ros2.org/) — the reasoning behind DDS, lifecycle and QoS.
- [Migrating from ROS 1](https://docs.ros.org/en/jazzy/How-To-Guides/Migrating-from-ROS1.html) — official guidance and bridge instructions.