[luoc]

Last time I worked with Odoo (v15/v16, enterprise, self hosted) we had to send a dump of the production database over to you to be migrated to the new version and then it was sent back. The upgrade path for third-party and custom addons was not defined. And since it is Odoo, everything is in that database: from employee's time tracking to customer support chats, from stock info to accounting data, from e-mail addresses to password hashes. I found this inacceptable but at that point we had no choice.

What's the state here?

[pinky07]

You can crypt the data before sending to the upgrade platform. Before it was an external script, and since Odoo 16 you can use the `oboo-bin obfuscate` command, before running the upgrade script.

See `./odoo-bin obfuscate --help` to check how to crypt your custom data and uncrypt after upgrade.

It's not perfect (crypt specific columns rather than full DB) but, unfortunatelly, to operate our upgrade service, we need access to the database. Upgrades are complex and requires testing, fine tuning scripts to your specific use cases, etc.

The other alternative is to not use our services, but do it yourself using upgrade scripts from the community: https://github.com/OCA/OpenUpgrade

[mavvvricks]

Small partner here who absolutely love Odoo for what it is and you can make it to be.

But - I can't wrap my head around why an on-prem customer cannot be allowed to run the upgrade scripts on-prem.

I have almost lost customers to it, and it's a super big headache delaying the upgrade process for both political and technical reasons.

Having tried to discuss the options and reasons with both Odoo support and employees at OXP has been an almost Kafkaesque experience.

Please explain to me like I am 5 years old.

[pinky07]

2 reasons:

1/ Upgrade are super complex: requires a service, not just a script

2/ We used it to monetize Odoo Enterprise

Upgrade: Even after 1000+ upgrades, we still run into issues regularly as every environment is different (set of modules, customizations, community apps, ...). So we need to test the database, and fix scripts when necessary. If we would just provide scripts, it would cost us a lot in support for issues... and a bad customer experience. At least, by having the control we can ensure a smooth customer experience; it just works - and you don't see everything we do behind. (most of the time)

Monetization: The open core business model is hard, when your goal is to do a maximum open source. Our main competitor being Odoo Community, we charge 5x less than competitors for a better software. (25€ vs 180€)

So, we had to pick a few apps and services to monetize Odoo Enterprise, like the accounting app, or the upgrade service.

Fortunetally, there is OpenUpgrade (scripts from the community) so that there is no lock-in on the upgrade. (you spend time with open-upgrade or go to Enterprise and we do it)

[mavvvricks]

Me and my customers are perfectly happy to even pay for the upgrade scripts, just allow us to run them on-prem.

Make it an encrypted binary for all I care, just allow us to run it on-prem.

Edit-due-to-pinky07-reply-edit:) 1+2 - I get all that. Perhaps provide enterprise customers with a GitHub repo to the upgrade scripts? Require the same subscription key like for Enterprise proper. Then you can continue to iterate on the scripts while still giving customers who wants (and pays extra!) for it as a white glove service to run it on their own servers.

Might be that me and some of my customers are old-school "server huggers", but I think it is holy to be able to decide on which CPU and disk my DB is processed on.

[furtfight]

Is it possible to pay to have an Odoo employee execute the migration script on the on premise server? I remember I heard about that but I don't know if it's still an option.

[pinky07]

We have done a few exceptions (e.g. Defense departments), but we usually refuse if not really justified.

[infogulch]

These approaches should be completely flipped, the default should be your upgrade engineers get remote access to the customer's database (vpn, etc) and run the standardized and ad-hoc upgrade scripts on their system. Shipping the customer's data back and forth for every upgrade is absurd and a privacy nightmare.