Ciao, provo a sintetizzare. Per i passaggi di versione ci sono 2 strade:

1. Il servizio di upgrade di Odoo SA

2. OpenUpgrade

Ho utilizzato e visto utilizzare entrambi. La scelta dipende da moltissimi fattori. Per installazioni con moduli OCA + moduli personalizzati, si tratta in entrambi i casi di progetti non banali.

Odoo SA

Nel primo caso, il progetto di upgrade in sé costa tipicamente un po' meno, visto che di tutta la parte odoo core se ne occupa Odoo SA. Bisogna però avere un contratto Odoo Enterprise, quindi il costo del servizio di upgrade viene spalmato sul canone.

Per la parte OCA + moduli personalizzati, dovrai invece occupartene tu o il tuo fornitore: se usi moduli che necessitano di script di upgrade e non li hanno, dovrai scriverli.

Odoo SA ha anche un servizio di upgrade dei moduli personalizzati, ma lo sconsiglio (l'ho provato qualche anno fa, magari nel frattempo sono migliorati).

OpenUpgrade

Nel caso di OpenUpgrade, il costo dell'upgrade dei moduli odoo core dipende dalla copertura dei moduli di OpenUpgrade: per quelli non coperti, se ti servono, dovrai scrivere gli script.

Per la parte OCA + moduli personalizzati, vale quanto sopra.

Il processo di aggiornamento

Infine ci sono ovviamente i costi/tempi del processo di upgrade in sé: fare un upgrade di test, correggere eventuali bachi degli script, fare i test funzionali, correggere eventuali malfunzionamenti, fare l'aggiornamento definitivo.

Progetti non banali appunto.

Brutalmente ... un progetto che preveda codice custom è bloccato alla versione, questo indipendentemente da quale versione di odoo tu usi CE o ENT, o anche da quale prodotto tu usi ... lo stesso discorso andrebbe bene anche per un plugin per office.

Purtroppo la relativa semplicità con cui si puo' personalizzare odoo porta a realizzare troppe soluzioni custom senza poi prevedere la successiva fase di evoluzione ... generalmente il codice custom non e' coperto da canone di evoluzione/migrazione. Il motivo, odoo e' usato in piccole realtà salvo casi eccezionali.

Se hai codice custom devi prevedere te ad una strategia di upgrade, che usi la versione ENT oppure openupgrade nessuno dei due strumenti potrà mai prevedere la migrazione del tuo codice.

 Per quando riguarda l'obsolescenza tecnologia e/o il rischio di esporre in rete prodotti che ormai resi inaggiornabili espongono a rischi potremmo stare a parlarne per i prossimi giorni o forse mesi. Noi abbian clienti, alcuni dei quali proprio per eccessivo custom usano la versione 8, ed una strategia only cloud ... e' stata una nostra scelta ed abbiam messo a disposizione un framework tale da rendere sicuro il cliente, ma questo esula il semplice prodotto, odoo, o la singola versione. Ed aggiungo, dipende dal singolo contratto che fai con il cliente, mi sembra ovvio che determinate garanzie abbiano dei costi cosi' come e' ovvio che non tutte le adozioni di odoo possano permettersi questi costi.

Odoo SA di suo, con la versione ENT, copre le ultime 3 versioni (3 anni) solo per il core ... eventuale custom viene quotato un tot a linea di codice.

OpenUpgrade e' un prodotto community da usare come aiuto, ma l'onere di migrazione spetta al singolo.

Da questo punto di vista odoo ha gli strumenti di ogni altra piattaforma ... certo si puo' discutere sul supporto a soli 3 anni, sulla mancanza di uno strumento automatico nella ENT etc etc ma di fatto un progetto con molto custom e' destinato a rimanere ancorato alla versione sulla quale nasce ma meno di non avere budget per la sua continua evoluzione.

Cio' premesso, un progetto custom fatto sulla 12 senza necessita' di funzioni 13 non ha senso migrarlo ... potresti pensare ad una migrazione solo quando cessera' il supporto odoo per la 12 (avvento della 15) ... potrei pure sbagliarmi ma un progetto 12 in esercizio difficilmente verrebbe migrato prima della 16.