What Happens to Your ROS 2 Project When the Distro Goes End of Life?

Nothing breaks on the day support ends: you choose between upgrading to the next ROS 2 distro, buying commercial support, or freezing the machine. Upgrading is usually right, because the borrowed packages are why you are on ROS 2 and they move with the distro. The verdict flips when almost nothing on the robot is borrowed any more — then a smaller base like HORUS costs less to carry. The rest of this post is for a team running a robot on a distro whose support window is closing, deciding what to do before it closes.

It starts as an errand. A package you have installed a hundred times is missing from the mirror, and every answer online tells you to use a version of Ubuntu you are not running. You shrug and pin an older image. A month later a new depth camera arrives and its driver refuses to build, because the vendor only publishes for the current release. You shrug again and write a shim. Then a teammate's laptop dies, the replacement ships with a newer operating system, and setting it up takes three days instead of an afternoon.

None of that feels like a deadline. It feels like bad luck arriving in instalments. Somewhere in the middle of it, somebody asks the uncomfortable question in a review: if a serious vulnerability lands in the messaging layer next spring, who publishes the fix for the version we ship? Nobody has an answer. The robot works. The fleet is in the field. That is the real state you are in when you start reading about end-of-life dates, and it is a much later stage than the calendar suggests.

What happens to your ROS 2 project on the day the distro reaches end of life?

Nothing happens on the day. The robot on the bench runs exactly as it did the evening before, because end of life is an announcement about who is doing work, not a switch buried in your software. What ends is supply: no more rebuilt binaries for that distribution, no more patched releases of the packages inside it, and usually within the same season, no more free updates for the operating system beneath. The decay is slow and it arrives from outside. You buy a sensor whose driver only builds against the newer release. A replacement laptop ships with an operating system your distribution never supported. The build server rebuilds an image one morning and a mirror that used to answer now returns nothing. A security review asks who patches the middleware, and the honest answer becomes nobody. Each of those is an ordinary Tuesday, and not one of them is the day the distribution died. That is why teams miss the moment: the deadline has no event attached, so it passes unremarked and the bill arrives months later dressed as unrelated misfortune.

What does end of life actually mean for a robot's software base?

End of life means the people who assemble the collection stop assembling it. A ROS 2 distribution is not one program. It is a dated snapshot of hundreds of separate packages — drivers, planners, message definitions, visualisation and recording tools — built and tested together against one version of one operating system. Somebody has to keep that snapshot coherent: rebuild everything when a compiler changes, repair packages that break when a dependency moves, publish binaries so installing takes minutes. That labour is what a supported distribution buys, and it is why every distribution carries a name and a date. When the date passes, the snapshot still exists and still installs. What is gone is the coherence work, so the collection can only drift out of agreement with everything around it: new hardware, new compilers, new operating systems, new advisories. Software does not rot on its own. It rots relative to the world. The same is true of any dependency you did not write, but a distribution expires as one lump, so the drift arrives all at once instead of one package at a time.

What are your real options when support ends?

There are six moves available and only one of them is a rewrite. You can upgrade to the next long-term ROS 2 release, which is the default and usually correct. You can freeze deliberately: pin every version, keep the machine off open networks, and accept that this robot will never change again. You can buy extended maintenance from a vendor who sells patched builds of older ROS 2 distributions. You can maintain your own builds, which means becoming a distribution maintainer for one robot. You can wrap the old distribution in a container so it survives on newer hardware for another year. Or you can keep the parts you wrote and move them onto a smaller base such as HORUS, an open-source real-time middleware for Rust, Python and C++ where all three languages share the same shared-memory ring buffers, so messages between processes on one machine are not serialised — a move that only makes sense once the borrowed packages have stopped being the point of the robot. Read the table as a set of situations, not a ranking of software.

What should you do if you are a solo builder or a two-person team?

Upgrade, and do it early enough that the upgrade is a weekend rather than an emergency. Small teams have one real advantage: no customer is holding a machine you cannot touch, and no auditor is asking about patch provenance. Take that advantage. Pick a quiet week, stand the project up on the newer release from an empty folder, and note every place it refuses to build. The list is usually shorter than the dread suggests, and it is nearly always dominated by two or three third-party packages rather than by your own work. The failure mode for small teams is not the upgrade — it is postponement. Because nothing is forcing the issue, the old release stays until it becomes the reason a new sensor cannot be used, and by then the upgrade competes with the interesting work you actually wanted to do. If you are choosing which release to land on, land on a long-term one even when a newer short release is tempting, and read the difference between the distros before you commit.

What if the robot runs on hardware you cannot change?

Then the operating system, not the ROS 2 distribution, is your real constraint, and you should plan around the board rather than the calendar. Plenty of robots run on a single-board computer or industrial box whose vendor image is frozen at an old kernel, with a camera stack that exists only as a binary blob built for that image. Upgrading the distribution above such a board is not a matter of will; the newer release expects a newer operating system, and the newer operating system has no working driver for your hardware. In that situation the honest options narrow to three: run the old distribution inside a container on a newer host so the old libraries stay together while the outside world moves on, buy extended maintenance so somebody else patches what you cannot rebuild, or replace the board. Replacing the board sounds expensive and often is not, once you count the months spent working around the old one. What you should not do is pretend an upgrade is scheduled when the hardware has already decided otherwise.

What if the end-of-life date is only weeks away?

Do the smallest thing that is safe, and stop treating the date as a wall. Weeks is not enough time to move a fleet onto a new release with confidence, and rushing it is how a robot that has behaved the same way for two years starts surprising people on site. The right move is to buy time honestly. Freeze and record what you have: exact package versions, an image you can rebuild from nothing, a list of every third-party dependency and where it came from. That inventory takes days and is the thing you will wish you had at every later stage. Then decide whether the remaining exposure is real. A robot that never touches a public network, takes no code from outside, and does one repeatable job can sit on an unsupported release for a long time with a clear conscience. A robot on a customer network cannot, and there the fastest legitimate answer is usually a support contract rather than a migration. Either way, plan the real upgrade for a quarter when it can be tested on a machine nobody depends on.

What if nobody on the team has done a distro upgrade before?

Then budget for surprise, and do the first upgrade on a spare machine where breaking things costs nothing. A first distribution upgrade is less about ROS 2 than about everything the robot quietly depended on: the operating system version, a Python library that changed its interface, a message package renamed by an upstream author who moved on. None of that is difficult work. It is unfamiliar work, which is slower and feels worse. Do it as an experiment rather than a migration. Install the newer release on a spare board, build your own packages first, and let each failure teach you which dependency you never knew you had. Only when you can build everything twice from an empty folder should you touch the robot that matters. The skill you are actually acquiring is inventory: knowing what your robot is made of and who maintains each piece. That knowledge pays every year afterwards, and it is the same knowledge that lets you tell a healthy open-source project from a stalled one before you depend on it.

What does it look like when a team leaves an old distribution in place too long?

It looks like one machine that nobody is allowed to reinstall. The build only works on the laptop of the person who set it up, because that laptop still has an operating system nobody can install any more. New hires cannot get the robot running, so onboarding becomes a two-week apprenticeship in undocumented workarounds. Someone finds a fix for a real bug upstream, it does not apply to your version, and a hand-carried patch lands in a folder nobody dares delete. Every new sensor is evaluated first on whether it can be made to build, and the answer shapes what the product can do. Eventually the migration is not an upgrade at all but an archaeology project, and the estimate for it is a season rather than a week. The tell that you are in this state is emotional rather than technical: people describe parts of the system as haunted, and reinstalling anything feels dangerous. Software you cannot rebuild from nothing is not software you own; it is a machine you are borrowing from your past self.

What do you give up by moving off ROS 2 when support ends?

You give up other people's maintenance, which is the whole reason distributions exist. Moving your own code onto a smaller base means the mapping and navigation stacks are no longer yours to use, sensor drivers become your problem the moment a vendor only publishes a ROS 2 package, and the visualisation and recording tools you debug with have no direct replacement. You also give up hiring leverage: a person who knows ROS 2 can read a ROS 2 robot on their first day and cannot read your private architecture at all. And you give up the shared vocabulary of forum answers and years of advice about failure modes you have not met yet. Those losses are real and heavy, and they are the strongest argument for staying and upgrading. What you get back is a system small enough to hold in your head, a start-up sequence you can explain in one paragraph, and a dependency you upgrade when you choose rather than when a calendar says so. Whether that trade is good depends almost entirely on how much of the robot you already wrote yourself.

When is ROS 2 the better choice?

ROS 2 is the better choice whenever the borrowed packages are still the reason the robot works. If your machine maps a building and navigates to a goal using code you did not write, upgrading to the next long-term release is the cheap option and everything else is expensive theatre. If a sensor you depend on ships its driver as a ROS 2 package and nothing else, the ecosystem has already made the decision. If several computers on a network must agree — a robot, a workstation, a fleet gateway — ROS 2 was built for that and has been proven there for years. If your team is more than a handful of people who all learned the same tooling, the shared vocabulary is worth more than any property of a transport. HORUS is not the answer in those cases, and choosing it there swaps a maintained ecosystem for plumbing you would have to build and then maintain yourself, at exactly the moment you were trying to reduce maintenance. An end-of-life date is not a reason to leave an ecosystem. It is a reason to move to the next release of it.

Does end of life mean your robot stops working?

No, and here is why: nothing in a ROS 2 distribution checks a date or phones home. The binaries on your robot are the same binaries the day after the announcement as the day before, and a machine sealed in a cabinet doing a repeatable job can keep doing that job for years past the date without a single fault attributable to support ending. What changes is your exposure to the outside world. Security advisories keep being published and nobody is applying them to your version. Hardware you want to buy next year targets the release after yours. The people who would have answered your question have moved to newer releases and no longer remember your version's quirks. So the risk is not sudden failure; it is the slow removal of every option except the ones you have already taken. Treating end of life as a cliff leads to panicked migrations, and treating it as nothing leads to the haunted machine. The accurate framing sits between: an unsupported robot is one whose future choices are being made for it by circumstance.

Should you just stay on the old distribution forever?

Partly, but not the way you think. Staying is legitimate — genuinely, not as a consolation — when the robot is a closed system: no network exposure, no new hardware, no new code, a job that will not change. Industrial installations live like this for a decade, and that is a defensible decision, not a failure of discipline. What people usually mean by staying, though, is something else: leaving things as they are while continuing to develop the robot, add sensors, hire people and ship updates. That combination is where the cost lands, because you are trying to keep moving on a base that has stopped moving. If you intend to stay, make it a decision with artefacts: an image you can rebuild from scratch, a written inventory of dependencies, a note on who patches what and a defined trigger that ends the freeze — a new customer, a new sensor, a network requirement. Staying deliberately is cheap. Staying by default is the expensive version, and it always presents itself as the same thing.

How do you decide which move to make?

Count what fraction of the running robot is code your team wrote, and let that number decide. If most of what makes the machine valuable came from the ecosystem, upgrade to the next long-term release and stop deliberating; the packages are the product, and following them is the cheapest path available. If most of the value is yours — your control logic, your calibration, your state machine — then the distribution has quietly become overhead, and the question changes from when to upgrade into what you actually still need from the collection. Ask a second question to break ties: what is forcing your hand? New hardware pushes toward upgrading. An audit pushes toward paid support. A frozen board pushes toward containers. Nothing at all pushes toward doing the inventory now, while it is cheap, so that the next decision takes a day rather than a month. And be honest about what the answers imply for the next machine you build, because the same questions apply before betting a product on any open-source stack.

Decide by situation rather than by preference:

• If you are a small team holding no customer machines -> upgrade now, because it is a weekend today and a season later.
• If your board's vendor image is frozen -> container the old distribution or replace the board, because the operating system decided this, not you.
• If a fleet is in the field and an auditor is asking -> buy extended maintenance, because patched builds arrive sooner than a migration can.
• If the robot is sealed, offline and finished -> freeze deliberately and write the inventory, because a documented freeze is a real engineering choice.
• If almost every valuable line on the machine is yours -> move your code to a smaller base, because you are paying distribution costs for packages you barely use.

When two of those apply at once, weigh them on the five axes of the HORUS Fit Framework — ecosystem size, setup effort, team size fit, deployment target, and licence — and take the option that loses on the fewest. No scores: five plain questions about your situation rather than about the software. If your answers keep landing on one machine, more than one language, and code your own team wrote, star HORUS on GitHub so it is in your list when you start building the next robot.