Manual Odoo upgrades mean the crash loop: start the server, hit an error, fix it, restart, repeat. We scan your whole codebase against every known change for your path — including upgrades to the new Odoo 20 — auto-fix the safe Python/XML issues, and verify the result on a real Odoo server, plus a calibrated effort estimate and a client-ready PDF for your quote.
No setup. Upload, scan, and export — usually in under two minutes.
Drop a ZIP of your custom Odoo module and choose the source and target versions.
Your code is checked against everything that changed in your target version — then each finding is confirmed against real Odoo before it counts.
Get effort, cost and a ranked findings list — export a branded PDF to quote your client.
Four versions behind? You don't have to scope 16 → 17, then 17 → 18, 18 → 19, then 19 → 20. VersionBridge scopes the jump you're actually making — 16 → 20 is a single piece of work.
Odoo 20 paths are in preview (built from Odoo's pre-release branch; refreshed at official release).
Analysis alone can only tell you what might break. Before any finding reaches your report, we put it to the test against real Odoo running your target version. What you get is what we observed actually break — not a list of possibilities — and each finding carries a confidence level from that same check.
A ranked, verified findings list you can act on — and a branded, board-ready assessment you can send as-is. Every figure below is the real output for the sample module, straight from the engine.
| Module | Findings | Critical | Effort | Cost |
|---|---|---|---|---|
| custom_sale | 8 | 2 | 8.2h | €472 |
| custom_crm | 4 | 0 | 1.4h | €80 |
| Total | 12 | 2 | 12.6h | €720 |
The report doesn't just find the breaking changes — VersionBridge's AI writes the fix. It generates the code change for each safe Python & XML break, applies it, and re-validates it on a real Odoo server — so the bulk of the migration is already done. You review and ship the rest.
A week of a developer's time becomes a few clicks — on a subscription that costs less than an hour of it.
Generated by the same engine that produces your reports — example module, illustrative figures.
A precise upgrade estimate normally takes days of digging through changelogs and core — and whoever gets the number wrong pays for it. Quote too high and the client overpays or walks; quote too low and the fixed price eats the partner's margin. Both sides carry that risk on every deal.
VersionBridge takes it off the table. We maintain a deep, continuously-updated map of what actually changes between Odoo versions and check your module against it, so every number traces to a specific, verified change — an estimate you can defend in minutes, not days. Never a guess, never a black box.
What we don't claim: the effort and cost figures are indicative — per-change-type hours with economy-of-scale batching, meant to be calibrated to your team's velocity and rate. A defensible baseline, delivered fast — not a black-box fixed price.
Python, XML, JS & manifest changes checked against our Odoo version intelligence.
Effort weighted by change type and repetition — apply your rate to get a client quote.
Every finding confirmed against your target version before it reaches your report.
Export a branded PDF with scope, effort, cost and detailed findings.
Your module is analyzed in an isolated, sandboxed Odoo environment that is wiped after each validation run. We never train on or share your code, and you can delete a project and its files at any time.
We’re honest about being early: no inflated numbers, no fake logos. Instead, judge it on the work — download the sample report and see the real output for yourself. Every finding is verified against real Odoo running your target version, so you can sanity-check it against your own experience. Scanning is always free — you only pay to apply fixes.
That’s exactly why we verify. Analysis surfaces candidates, but nothing reaches your report until it’s been confirmed against real Odoo running your target version — and candidates that turn out not to break are ruled out. Each finding shows its confidence and verification status: we’d rather show you uncertainty than fake certainty.
It’s per-change-type hours with economy-of-scale batching for repeated changes, and you apply your own hourly rate. It’s an indicative baseline to calibrate to your team’s velocity — designed to be defensible and fast, not a black-box number.
Yes — that’s the point. We scope the jump you’re actually making as a single piece of work, so you get the net effect rather than three hypothetical migrations stitched together. Available paths today are 15 → 18, 17 → 18, 16 → 19, 17 → 19 and 18 → 19, plus 16/17/18/19 → 20 in preview (built from Odoo’s pre-release branch, refreshed at the official 20 release) — covering Python, XML, JavaScript and manifests. If a pair isn’t supported yet, the upload form tells you up front rather than guessing.