In molti mi avete chiesto info in merito a la processo di migrazione Odoo, provo a scrivere qualche indicazione utile.
Si tratta di un processo non molto semplice e lineare, che chiede molta esperienza e (s)fortunatamente ho fatto molte sudate in merito :)
Sicuramente uno degli strumenti principali è OpenUpgrade (https://github.com/OCA/OpenUpgrade e https://oca.github.io/OpenUpgrade/) che si occupa di mettere a disposizione di tutti una vera e propria istanza di Odoo che contiene procedure e patch che migliorano quanto di già presente su Odoo standard.
Infatti il sistema standard nasce con delle cartelle dedicate alle procedure di migrazione interne (es. https://github.com/odoo/odoo/tree/ab7a2098f0f19b77d3251724650ee8f82f5f33ec/addons/website_hr_recruitment/migrations) in questa cartella si trovano script di pre e post migrazione che operano sul database ed apportano variazioni sulla struttura e manipolano i dati al fine di farli approdare correttamente nella versione di destinazione.
Dovrebbe essere tutto semplice e lineare, ma spesso ci si trova di fronte a vere e proprie odissee soprattutto se consideriamo codice custom e/o repository che contengono script di migrazione poco testati o per nulla presenti.
Il consiglio generale che posso dare è quello di disinstallare dalla versione sorgente quanta più roba possibile, in maniera da avere un database molto vicino allo standard. Ovviamente bisogna tenere presente che la disinstallazione dei moduli, nelle ulitme release di Odoo porta via anche i dati, per cui massima attenzione; I dati poi possono essere recuperati con delle query, ETL o script python scritti ad hoc (io spesso ho fatto in questo modo e ci ho messo meno tempo rispetto a quello che avrei potuto dedicare se mi fossi fermato a sistemare gli script pre e post, perchè questi vengono eseguiti durante l'avvio dell'istanza e quindi c'è del tempo di attesa non indifferente soprattutto in database corposi)
Tenete anche in considerazioni la presenza di eventuali view modificate a mano dal backend in modalità sviluppatore, queste potrebbero avere bisogno di essere eliminate e reinserite nella versione di destinazione, sempre che quelle necessità non siano già coperte e presenti nella versione di destinazione.
>>> Diamo per assodato che tutte le operazioni vengono fatte da terminale ed è fondamentale leggere tutti i warnings ed errors per capire cosa fixare. <<<
>>> Fate sempre un backup ad ogni passaggio, ogni step un backup, in questo modo se vi trovate al quinto passaggio di una migrazione che va dalla 10 alla 16 e cioè 7 step (V10-V11-V12-V13-V14-V15-V16) , non vi ritroverete con l'incubo di ricominciare dall'inizio in caso d'errore <<<
Per cui si procede mettendo in piedi una istanza Odoo utilizzando OpenUpgrade come repository per il core, si monta il database da trattare in questa istanza ed il primo passaggio fondamentale è un update all nella stessa versione di partenza. Per intenderci se devo migrare da V12 a V16, procedo con update all della V12 così mi assicuro che si parta da una V12 aggiornata all'ultima minor.
poi si passa alla versione successiva, mettendo in piedi una istanza dedicata OpenUpgrade alla release V13 (in questo esempio) e si continua sempre con un update all , così via fino ad arrivare alla versione finale.
>>> ogni istanza va messa in piedi con tutti i repository necessari ed in quella specifica release <<<
Alcuni intoppi possono nascere nel momento in cui ci sono moduli che cambiano nome da una release all'altra oppure cambiano completamente struttura, un caso è il modulo dei DDT che nel corso degli anni ha subito numerose variazioni e ad un certo punto si è deciso di riscriverlo completamente, mettendo a disposizione gli script per traslocare i vecchi ddt alla nuova gestione (operazione che merita un capitolo dedicato :) )
Per mia esperienza un bel po' di errori sono nati per via delle views che riportate pari pari dalla versione sorgente, si trovavano a non avere gli stessi campi nella versione di destinazione, in questo caso (ed è proprio successo con il database dell'associazione) l'unica salvezza è quella di eliminare la view da ir_ui_view insieme alle sue ereditiere e poi lanciare l'istanza con l'update del solo modulo in questione.
Durante la migrazione di Odoo-Italia.org è capitato proprio per il modulo eventi (proprio mentre dovevo pubblicare l'evento odoo days italia) per cui ho eliminato la view leggendo l'id dal terminale ed ho poi fatto un "-u event" con successo.
Prima di avventurarvi controllate che la release di destinazione sia coperta da OpenUpgrade, leggendo le issue aperte (https://github.com/OCA/OpenUpgrade/issues) perchè potrebbero esserci dei moduli in attesa di merge o che necessitano di essere ancora scritti, l'invito è ovviamente quello di contribuire a fare review o iniziare a prendersi in carico la migrazione del modulo per il beneficio di tutti.
Prendete sempre nota di tutti i passaggi, fix, query che lanciate manualmente durante il corso della migrazione, io per esempio sono abituato a tirare fuori quello che poi diventa un vero e proprio script a supporto della migrazione che riutilizzo quando il test è riuscito e devo procedere in produzione.
Altra soluzione può essere quella di acquistare una licenza Odoo Enterprise (anche solo per un mese) dare in pasto il db a casa madre upgrade.odoo.com e attendere che restituiscano il db da avviare sull'istanza di destinazione, in questo caso va tenuto presente che subito dopo il primo avvio (se avviene senza intoppi) è necessario disinstallare il modulo web_enterprise per tornare ad essere community.
Ho cercato di essere sintetico :) se mi viene in mente altro che può tornare utile lo aggiungo.
Mi raccomando - vi aspetto agli Odoo Days Italia 2024 https://www.odoo-italia.org/r/KBF
Ottimo, sarebbe interessante sapere come hai fatto. Credo che molti siano interessati.
Grazie per il lavoro
Effettivamente come ha detto Luca sarebbe veramente interessante