Apache OFBiz, modernised without migrating
340 undocumented customisations, documented. A nine-year-old OFBiz instance, not migrated.
- Company
- $150M wholesale distributor, 290 employees
- Platform
- Apache OFBiz 17.12, live since 2016
- Scope
- 340 custom extensions
- Shadow systems
- 41 Excel exports, 11 maintainers
- Build
- 8 weeks
- Migration
- None. Still on 17.12
Sits on top of
Pipeline
- Read API layer over the existing schema
- Service catalogue of all 340 extensions
- Quote assembly in one call
- Natural-language query layer
Delivers
Read-only for the whole build. Nothing writes to the general ledger.
Outcomes at a glance
What the build changed.
The arithmetic behind every one of these is further down this page.
0
Extensions documented
0 hrs
Quote turnaround
0/mo
Report tickets to developers
0
Excel exports retired, of 41
In plain terms
What this build actually is.
A nine-year-old Apache OFBiz instance had accumulated 340 custom extensions. The two engineers who built them had left, none of it was documented, and so none of it could be safely touched. Every new report became a developer ticket with a three-week queue, and the business routed around the ERP entirely.
So the build does not replace the ERP. It documents what the ERP already does, puts a read-only interface over the data that is already in it, and lets business users ask questions directly. The customisations stay. The version stays. What changes is that someone can now explain the system.
What the system does
- Reverse-engineers and documents every custom entity and service extension.
- Exposes the existing PostgreSQL schema through a read-only API layer.
- Assembles a quote from price, stock and ETA in one call instead of three screens.
- Answers business questions in plain language against the documented schema.
- Replaces the maintained Excel exports that were worth replacing.
The result that matters
Quote turnaround falls from 2.5 days to 3 hours, and report requests into the developer queue fall from roughly 14 a month to 2, with no migration.
The situation
A shadow ERP made of spreadsheets had grown around the real one.
A nine-year-old OFBiz instance carrying 340 custom entity and service extensions, last upgraded in 2019. The two engineers who built the customisations had left. There was no documentation of any of it.
Every new report was a developer ticket with a two-to-three week queue, so the business had routed around the ERP entirely: 41 Excel exports maintained by 11 people. Quote turnaround was 2.5 days because pricing lived half in OFBiz and half in a spreadsheet. There was no API surface at all, everything was screen-driven.
What the five-day diagnostic found
- The customisations were sound engineering, not a mess. They were simply undocumented, which had made them untouchable.
- Six years of fear of breaking something had produced a parallel shadow ERP made of spreadsheets, and that shadow was the real operational risk.
- The PostgreSQL schema underneath was clean and queryable. The problem was access, not data.
- Of 41 exports, 12 were genuinely ad-hoc analysis that should stay in Excel. Replacing those would have been activity, not progress.
- They were scoping a move to a tier-one ERP, principally because nobody could explain what the current one did.
Where we stopped
What we did not automate, and why.
The most valuable decision in this engagement was what to leave alone. Three of the four below are things a less careful scope would have bundled in.
Stays with a person
The OFBiz upgrade itself
Scoped and recommended, deliberately not bundled. Run a version upgrade and an agent rollout together and the first time something breaks you cannot tell which one caused it. Separate change, separate window.
Stays with a person
Twelve of the 41 Excel exports
Genuine ad-hoc analysis. Excel is the right tool and we left it alone. Replacing them would have been activity, not progress.
Stays with a person
Pricing approvals above standard discount bands
Commercial judgment, and it stays with the people accountable for the margin.
Hard stop
Anything writing to the general ledger
Read-only, by design, for the whole build. Nothing in this engagement can change a financial record.
What we built
An interface over the data they already had.
No migration. The pattern is to put an interface over the data you already have, not to move the data. Built over eight weeks.
Read API layer
Over the existing PostgreSQL schema and the OFBiz service engine, with no change to either.
Service catalogue
All 340 custom extensions reverse-engineered and documented. This is the artifact they had been missing for six years, and on its own it changed what they could safely do next.
Quote assembly
Price, stock and ETA pulled into one call instead of three screens and a spreadsheet.
Natural-language query layer
Over the documented schema, so business users stop filing report tickets to ask a question about their own data.
Twenty-nine live endpoints
Replacing the Excel exports worth replacing, and leaving the twelve that were not.
Where the model is actually used
One place: turning a business question into a query. It is read-only, runs against a documented schema, and carries a row limit and a query timeout. Everything else, including quote assembly, stock lookup and reorder suggestions, is plain service calls against the API layer, because those are fixed rules on fixed inputs.
When the query layer is not confident, or the question needs a multi-table join it cannot verify, it does not guess. It returns the relevant part of the catalogue and a suggested starting query. A wrong number delivered confidently would undo the entire point of the engagement.
Results
Every number the build moved.
340
Extensions documented
From zero. The two engineers who built them had left, and there was no documentation of any of it.
3 hrs
Quote turnaround
From 2.5 days, which was how long it took because pricing lived half in OFBiz and half in a spreadsheet.
2/mo
Report tickets to developers
From roughly 14 a month, each one entering a two-to-three week queue.
29
Excel exports retired, of 41
Twelve were kept on purpose. They are genuine ad-hoc analysis, Excel is the right tool, and we left them alone.
4 hrs
Monthly developer time on reports
From 22 hours a month spent writing one-off reports instead of building anything.
17.12
OFBiz version, unchanged
No migration, no re-platform, and no version upgrade bundled into the engagement.
How we know
One hundred and eighty real questions, answered by hand first.
Golden set: 180 real business questions harvested from six months of report tickets, each answered by hand by their one OFBiz-literate analyst.
Harvesting the questions from real tickets rather than writing them is what makes the number meaningful. These are the questions the business was already asking and already waiting three weeks for.
Scroll the table sideways for Week 6 and the note.
| Measure | Week 1 | Week 6 | Note |
|---|---|---|---|
| Natural-language query correctness | 71.0% | 93.3% | exact-value match |
| Declined rather than guessed | 19% | 6.7% | returns catalogue + starting query |
| Confidently wrong answers | 4 | 0 | the only number that had to reach zero |
Correctness is measured as exact-value match against the analyst answer, not as a plausible-looking result. A query layer that is usually right and occasionally confidently wrong is worse than no query layer, because the business cannot tell which answer it got.
What it is worth
Value, with the maths.
The smallest total in this set, and the one with the most carefully fenced revenue claim. The recurring figure below deliberately excludes most of the revenue effect we measured.
Excel maintenance eliminated
$20-32k
roughly 19 hrs/wk across 11 people x 50 wks x $33, discounted 30%
Developer capacity recovered
$11-15k
18 hrs/month x 12 months x $52
Quote-cycle margin on faster turnaround
$24-33k
a conservative slice only, roughly a quarter of the measured effect, see the note below
Recurring annual value
$55-80k
Plus a revenue effect we have deliberately under-claimed, because we would rather be checked and found conservative than checked and found wrong.
- Flagged as weakly attributed
- The client measured a 2.1 point win-rate improvement on quotes under $20k across two quarters against the prior-year cohort. On $28M of that band at 22% gross margin that implies about $129k. We have taken a quarter of it into the table and flagged the rest, because two quarters against a prior-year cohort is not a controlled comparison.
- Excluded entirely
- The tier-one ERP migration they were scoping has been deferred. We are not claiming an avoided migration cost: deferred is not cancelled, and counting it would be the kind of number that gets a case study thrown out.
- Not counted, and the most valuable thing in the engagement
- They can now explain what their own ERP does. There is no line for that, and it is the reason the migration conversation changed.
What we got wrong
What we would do differently.
We documented the 340 extensions as a deliverable alongside the build. It should have been the first deliverable, priced and shipped on its own.
It was the thing that unblocked every later decision, and they would have paid for it by itself.
Where this goes next
If you are on OFBiz and nobody left can explain the customisations, the catalogue is the first thing to buy and it is useful whether or not anything else follows. Five days is enough to scope how big yours is.
Tell us about your project.
A 30-minute discovery call with a senior engineer. Concrete next steps, honest scope, no boilerplate decks.