Migrating from Openbravo to Etendo: A Practical Guide from an Ex-Openbravo Engineer

If you’re running Openbravo 3.x today, you already know the uncomfortable part: the platform you built your operations on stopped being the vendor’s main story years ago. Openbravo the company pivoted to retail commerce under Orisha, and the classic open-source ERP platform found its continuation in Etendo — a Spanish company that forked the codebase and kept building: modern stack, active releases, and an AI layer (Copilot) that the original platform never had.

We have an unusual vantage point on this. Before BeaverMinds, we were Applications Engineers at Openbravo itself — one of us on the core platform — and we’ve spent the years since implementing, customizing, and lately putting LLM features inside Etendo in production. So here is the guide we wish existed: what a migration actually involves, what makes one take weeks versus months, and when you shouldn’t migrate at all.

Where Openbravo users actually stand in 2026

Staying put feels free. It isn’t. An unmaintained ERP platform accrues three quiet costs: security patches you’re no longer receiving, a stack that drifts out of support underneath you (Java versions, PostgreSQL versions, Tomcat), and a shrinking pool of people who can work on it. None of these shows up as a line item — until the day one of them does, all at once.

The good news is that Etendo was designed as a continuation, not a rewrite. Your data model, your modules, and most of your team’s muscle memory carry over. This is a migration in the true sense — not a reimplementation wearing a migration costume.

What an Openbravo to Etendo migration actually involves

The official path is documented by Etendo, and it’s two hops, not one.

Hop one: get to Openbravo 21Q3.2. Etendo’s migration tooling expects an instance on Openbravo 21Q3.2, so anything older upgrades first. In practice this step is where you pay down years of deferred maintenance: you extract any custom patches applied to core (the docs sensibly tell you to skip patches that were bugfixes — those are in 21Q3.2 already), clone the 21Q3.2 sources, carry your modules across, reapply the patches that still matter, and run the full ant update.database compile.complete.deploy cycle until it comes up clean. If your instance is already on a recent Openbravo release, this hop is short. If you’re on something from 2017, this hop is the project.

Hop two: the actual migration. With a healthy 21Q3.2 instance, the Etendo migration itself is refreshingly mechanical: stop Tomcat, back everything up, extract the Etendo base sources, configure gradle.properties, and run ./gradlew expandCore and setup. You then move your custom modules across — excluding the couple dozen core modules Etendo already ships — and run ./gradlew update.database compile.complete.deploy. Post-migration, there’s a cleanup checklist people skip at their peril: remove the old web context, repoint Apache from /openbravo to /etendo, fix attachment paths, and — the one we’d underline twice — update your backup scripts to the new database and file paths. A backup script quietly backing up the old, dead instance is the kind of thing you discover at the worst possible moment.

That’s the official recipe. Notice what it doesn’t mention: your customizations are assumed to just work. Sometimes they do.

The real effort driver: your custom modules

In our experience, migration effort has almost nothing to do with database size or user count, and almost everything to do with three questions:

How many custom modules do you have, and how were they built? Modules built the way the platform intends — proper module packaging, DAL access, no direct core hacks — usually carry over with minor fixes. Modules that patched core classes directly, or that depend on APIs that drifted between your version and 21Q3.2, need real rework. This is why hop one is usually the expensive hop.

How far behind are you? Each Openbravo release between your version and 21Q3.2 is accumulated API drift your patches and modules must cross. An instance from 2020 crosses a stream; an instance from 2015 crosses an ocean.

Can anyone still explain your customizations? If the integrator who built them is long gone and there’s no documentation, someone has to read the code before anyone can migrate it. Budget for archaeology.

Rough tiers, from our migration experience — ranges, not a quote: a lightly customized instance on a recent version is a small project measured in days to a few weeks. A heavily customized instance several years behind is a staged project measured in weeks to months, where the majority of the effort is module remediation, not the migration commands themselves. Anyone who quotes you a precise number before auditing your modules is guessing.

When you should NOT migrate

An honest guide has this section. Don’t migrate if:

• You’re on a maintained commercial Openbravo edition and it serves you. The retail commerce product is alive and supported under Orisha. If that’s what you run and it fits, you don’t have this problem.
• The ERP itself is the problem. If the system never fit your business — wrong processes, wrong data model, users working around it in spreadsheets — a migration faithfully preserves everything that’s wrong. That situation calls for a replacement decision, not a migration. (It’s a harder conversation, and we’d rather have it before you spend money migrating.)
• Nobody is asking for anything new. If the instance is stable, air-gapped from risk, and the business it serves is winding down or steady-state, “run it until it drops” is a legitimate strategy — as long as you’re choosing it consciously, with backups you’ve actually tested.

For everyone else — and especially if the reason you’re looking at Etendo is what comes after the migration, like putting AI agents inside your ERP with Copilot — the migration is the toll booth, not the destination.

How to start without betting the company

Start with an audit, not a commitment. Twenty focused hours on your instance — version, module inventory, patch archaeology, database health — turns “somewhere between weeks and months” into a real plan with real stages, each of which is testable and reversible.

That audit is literally what our free ERP & AI Readiness Assessment is: one call, then a written report on your instance’s health, upgrade path, and where AI would genuinely pay off once you’re on the other side. If you’d rather first understand who you’d be dealing with, our Openbravo & Etendo consulting page covers what we do and why we’re opinionated about this particular platform.

We were there when this codebase was young. It’s genuinely good to see it have a future — and the path to that future is shorter than most Openbravo shops think, provided someone who knows the terrain walks it with you.