Is Openbravo Actually End of Life in 2026? What Running an Old Instance Really Means
Search “Openbravo end of life” and you mostly land on a SourceForge notice from 2020 and some scattered forum posts. That gap is part of the problem. Plenty of businesses are running Openbravo today, quietly, without a clear answer to a basic question: is this thing still supported, and if not, does that actually matter yet?
We were Applications Engineers at Openbravo before founding BeaverMinds, so we’ve watched this story from inside the company and from the outside as consultants fielding the anxious calls that follow. Here is the honest version.
What actually ended, and when
The Openbravo Community Edition, the free open-source version most people cut their teeth on, stopped receiving bug fixes, security patches, and any new development back in 2020. The projects came down from SourceForge. That part is old news and most people running Openbravo today already know it.
The newer, less-discussed piece: Openbravo the company pivoted hard into retail and restaurant commerce years ago, operating today as Orisha Commerce. Along the way, several core ERP modules that non-retail customers relied on, financial management, production management, material requirement planning, and project and service management, were declared end-of-sale in November 2022 and end-of-life at the start of 2024. If your business isn’t a retail or restaurant chain and you’re leaning on those modules, the vendor has told you plainly that this is not where their attention goes anymore.
Put together: if you’re on Community Edition, you’ve had zero patches for years. If you’re a non-retail commercial customer, several of the modules you built your operations around are past their own end-of-life date. Neither situation is hypothetical or looming. Both already happened.
Why this doesn’t feel urgent (and why that’s the trap)
An ERP system doesn’t stop working the day support ends. It keeps invoicing, keeps tracking inventory, keeps running payroll, right up until it doesn’t. That’s what makes end-of-life risk so easy to defer: there’s no crash to point at, just a slow accumulation of exposure. A CVE surfaces in a library your version depends on and nobody patches it. Your Java or PostgreSQL version falls further behind what anyone still tests against. The two or three people who understood your customizations move on, retire, or get hit by a bus, and the knowledge leaves with them.
None of these show up on a dashboard. They show up as a single very bad week, years from now, when something breaks at the worst possible time and there’s no vendor to call and no internal memory of why the system was built the way it was.
The actual decision in front of you
Doing nothing is a choice, and sometimes the right one, at least for now. A small, stable instance with no compliance pressure and a team that still understands it can reasonably wait. But that calculation changes fast once you’re touching customer payment data, operating in a regulated industry, or running modules that are already formally end-of-life.
The realistic paths from here are staying and self-supporting (accepting the security and staffing risk explicitly, with eyes open), or moving to Etendo, the platform that forked the Openbravo codebase and kept building: active releases, a modern stack, and an AI layer the original platform never had. We’ve written up what that migration actually involves, including the parts about custom modules that most guides skip, and separately covered what Etendo’s Copilot agents look like in production once you’re on the newer platform.
If you’re not sure which side of that line you’re on, that’s exactly the conversation worth having before the bad week arrives rather than after. Visit our Openbravo/Etendo practice page for how we work with instances like this, or book an assessment and we’ll tell you plainly where your risk actually sits.