Upcoming ROS 1 End of Life

Migration Paths for ROS 1 Users

ROS 1 Noetic Ninjemys goes End-of-Life 2025-05-31

If you have been directed to this page it was probably because you saw one of the notifications we slipped into the source code for ROS Noetic or RViz. We’ve heard from a number of users that they were unaware that ROS 1 Noetic, and consequently all of 1, will go end-of-life on May 31st, 2025. We’re sorry that we interrupted your work, but it is crucial that you know what happens once ROS 1 goes end-of-life.

ROS Noetic Ninjemys, the last ROS 1 release, will reach End of Life in May 2025. Over the past five years we focused our efforts on making ROS 2 a world class framework for professional robot development, and our user community seems to agree. According to September 2024 download data from our servers ROS 2 downloads now make up almost 80% of all ROS downloads. We’ve now seen ROS 2 used successfully in production by a large number of companies, across dozens of industries, and we think it is time for the last remaining ROS users to make the switch.

ROS Downloads by Distro, September 2024

What Does End-of-Life Mean?

End of life for ROS Noetic means that the ROS team will no longer support ROS 1. After May 31st of 2025, the ROS team will no longer provide the following for ROS 1:

  • New features or capabilities
  • Security updates
  • Bug fixes, patches or support
  • Updated binaries

After May 31st, 2025 ROS 1 Noetic users may find themselves exposed to un-patched security vulnerabilities and bugs, with few avenues of support short of fixing these issues themselves and recompiling Noetic from source. However, this isn’t an outright emergency, it is good to keep mind what won’t change after May of 2025.

ROS 1 going end of life does not mean:

  • ROS 1 binaries will suddenly disappear.
    • ROS 1 binaries will continue to be hosted on packages.ros.org
  • ROS 1 projects will suddenly stop working on May 31st.
    • ROS 1 will continue to work, as it does today.
  • Users must stop using ROS 1 immediately,
    • ROS 1 will continue to work, but you should have migration plan as soon as possible.


ROS 2 Migration Options

If you are still using ROS 1 it is time to consider switching to ROS 2 Humble Hawksbill (migration guide) or ROS 2 Jazzy Jalisco (migration guide). Which distro you choose as your migration target is going to depend on the complexity of your ROS 1 system. This migration heuristic tool can help you estimate the complexity of migrating your project to ROS 2. If you have a smaller ROS 1 project, or a reasonably de-coupled workspace, it is most likely that you can migrate to ROS 2 Jazzy Jalisco directly. The ROS community has produced a number of migration tools which you may find helpful, including this migration tool from AWS Labs, and this migration tool from ROS maintainer David Lu!

If your ROS 1 system is tightly coupled, has a number of un-ported dependencies, or is reasonably complex, you may want to take advantage of the ROS 1 to ROS 2 Bridge. The ROS 1 to ROS 2 Bridge performs automated translation between major ROS versions and should allow you to migrate your project one package at a time. The ROS 1 to ROS 2 Bridge was intended to only support ROS 2 distros prior to and including ROS 2 Foxy, and due to operating system constraints it is no longer fully supported by the current ROS 2 releases. However, with a little bit of work, it is still possible to use the ROS 1 / ROS 2 bridge with Noetic and a current ROS 2 distro. Users can either compile ROS 2 Humble from source for Ubuntu 20.04, which has Tier 3 support, or use ROS-O binaries to build their packages on a newer version of Ubuntu (i.e. 22.04 of 24.04).

Other Migration Options

We highly recommend you migrate your ROS 1 project to ROS 2 as soon as possible. Most users have found the migration process less difficult than they initially expected. If you simply can’t migrate your ROS 1 project right now, you do have a few options, however, none of these solutions are officially supported, and we can’t speak to their long-term robustness.

  • Canonical, offers extended security maintenance for a number of ROS 1 host operating systems for a fee.
  • ROS-O is a volunteer run effort to extend the support lifetime of ROS 1 projects.
  • If you simply need an extra set of hands to help with your migration you are welcome to use our jobs board on ROS Discourse to find some help.


What’s New in ROS 2?

Before you begin your ROS migration journey, we recommend you read up on some of the new and improved features in ROS 2. We’ve put together a collection of resources that outline some of the major changes in ROS 2. Almost all of these resources are readily available as part of our migration guide in the ROS 2 documentation. While understanding what has and hasn’t changed between ROS 1 and ROS 2 can make the migration process go a lot smoother, it really isn’t necessary to get started! There’s a lot to love in ROS 2, and we think you’ll find some of the new ROS 2 features make for a much better user experience.

Changes to the ROS API

Most of the ROS 2 API should look familiar to ROS 1 users with a few notable exceptions. Where things have changed, they have changed to address shortcomings in ROS 1. The exciting thing about ROS 2 is that it has given us the opportunity to address a number of user complaints about ROS 1! The list below outlines some of the larger changes to the ROS API found in version 2.

  • Nodelets in ROS 1 have been replaced with ROS 2’s composable nodes concept. ROS users can now compose their processing routines into the same process space using both compile time and run time composition.
  • Parameters in ROS 2 now support namespacing, and there is an improved interface for loading, saving, and reconfiguring your parameters. This migration guide provides guidance on how to migrate your parameter set.
  • ROS 2 supports three different types of launch files: YAML, Python, and XML. There is a complete guide to migrating your ROS 1 launch files available on docs.ros.org.
  • The ROS 2 lifecycle node API has standardized the lifecycle of ROS nodes. The process of starting and stopping ROS nodes is now much more robust. We recommend taking advantage of this feature when migrating your ROS 1 project.
  • ROSBag performance has improved significantly in ROS 2, and the new ROS 2 type adaptation makes it even easier to share data using ROS Bags. As of ROS 2 Humble MCap is now the standard ROSBag data format.
  • If you are looking for examples of common ROS 2 design patterns the ROS 2 Cookbook offers code samples for common ROS 2 tasks.


ROS Development

The ROS build and command line tools have also gotten a face lift in ROS 2. While there have been a few changes, the way you build and run your ROS application should feel familiar. All of our new tools are self-documenting, and you can learn a lot by simply passing them the --help option.

  • The ROS command line interface (CLI) syntax has changed slightly in ROS 2. All your favorite commands are still there, but the syntax has been modernized.
  • ROS 2 uses Colcon, rather than catkin build or catkin_make, as the build tool. The names have changed, but most of your favorite functionality is still there.
  • Ament is a collection of ROS build tool helper functions. Ament wraps common build tasks and exposes them to Colcon and ROS.


The ROS Middleware Layer (RMW)

ROS 1’s bespoke publish / subscribe layer was very simple to use, but also difficult to configure for more complex use cases. In ROS 2 users have a choice about which protocol they would like to use to move data across their network. This new abstraction layer is called a ROS Middleware Layer (RMW), and users can pick the vendor that best supports their application. If you don’t know which RMW is right for you, we suggest you use the default RMW that ships with your distro, however ROS 2 users now have multiple official and unofficial ROS RMWs to choose from, including:


Related Projects

Most of the major ROS packages and projects have already upgraded to ROS 2. Our sister project, Gazebo, is also in the process of migrating to its second major release, and many ROS users are also making the switch to a modern version of Gazebo. You don’t necessarily need to upgrade both ROS and Gazebo at the same time, but it is important to note that Gazebo Classic reached end of life in 2025 too. Other related ROS projects like MoveIt, Nav2, and ros2_control also have new and improved releases that are production-ready for your robotics application!


Where To Find Help

You don’t just have to take our word for it, a number of professional ROS users have already made the jump to ROS 2 and written about their ROS migration experience. We’ve collected a few relevant blog posts below:

At ROSCon 2024, our annual ROS developers conference, an overwhelming majority of the talks were about ROS 2. Below you find a collection of ROSCon talks that directly cover the process of migrating from ROS 1 to ROS 2.

Robotics is a tough field but the ROS community is always happy to help! Below you’ll find a list of community resources that can support you in migrating your ROS system. If you run into migration problem that you just can’t solve feel free to swing by our Discord server for some advice.