Da OpenERP a Odoo: cosa è cambiato e cosa fare se lo usi ancora

Le installazioni OpenERP ancora attive in Italia non sono poche. Spesso sono sistemi che funzionano, personalizzati negli anni da chi non lavora più in azienda, e proprio per questo raramente qualcuno li tocca.

Il punto non è se quel sistema vada sostituito, ma capire cosa si ha in casa, cosa comporta tenerlo e cosa comporta muoverlo. La decisione viene dopo, e a volte la decisione corretta è lasciare tutto com’è.

OpenERP e Odoo sono lo stesso prodotto

Il cambio di nome è avvenuto con la versione 8. Non è una ricostruzione di seconda mano: è scritto nel codice sorgente del progetto.

Nel ramo 7.0 il file che dichiara l’identità del prodotto riporta OpenERP Server come descrizione e OpenERP S.A. come autore. Nel ramo 8.0 lo stesso file dichiara product_name = 'Odoo' e Odoo Server. In mezzo non c’è altro.

Il changelog del pacchetto Debian data l’operazione: la voce odoo (8.0.0) stable porta la nota “Renamed package” ed è datata 17 settembre 2014. La voce immediatamente precedente è ancora openerp.

Il cambio di licenza è arrivato dopo, non insieme

È l’equivoco più diffuso su questo passaggio. Rinominazione e cambio di modello sono due eventi distinti, separati da una versione.

Le versioni 7 e 8 sono entrambe pubblicate in AGPLv3. Dalla versione 9 in avanti la licenza del codice base diventa LGPLv3, che è ancora quella in vigore su Odoo 19. È il cambio di licenza a segnare la discontinuità sul modello, non il cambio di nome.

Chi si ferma alla versione 8 quindi non ha mai vissuto la divisione in due edizioni. Se stai valutando quale delle due ti serve, la differenza è trattata in dettaglio nella guida su Odoo Enterprise e Community.

Le tracce del vecchio nome sono ancora nel prodotto

Il nome OpenERP non è sparito del tutto, e questo spiega perché la documentazione vecchia continua a circolare e a confondere.

• Nell’archivio dei sorgenti la cartella del codice si chiama odoo da Odoo 10 in avanti e openerp per tutte le versioni precedenti.
• Il file che descrive un modulo si chiamava __openerp__.py e oggi si chiama __manifest__.py. La riga di comando di Odoo 19 riconosce ancora entrambi i nomi.
• Il server di validazione degli abbonamenti on-premise risponde su services.openerp.com per Odoo 17 e versioni precedenti, e su services.odoo.com da Odoo 18 in avanti.

Come capire quale versione stai usando

È la prima informazione da recuperare, perché determina tutto il resto: cosa è ancora supportato, quali strade sono percorribili e quanto costa ciascuna.

• Dalla riga di comando del server. L’opzione --version restituisce la versione del server Odoo. È il metodo più diretto se hai accesso alla macchina.
• Dal nome della cartella di installazione. Se la cartella del codice si chiama openerp, sei su una versione precedente alla 10. Se si chiama odoo, sei sulla 10 o successiva. È un controllo che può fare anche chi non è tecnico, guardando il filesystem del server.
• Dai file dei moduli. Se dentro le cartelle dei moduli trovi file __openerp__.py, l’installazione appartiene alla generazione vecchia.
• Se il database è su Odoo Online. Nel gestore database il pulsante a forma di ingranaggio accanto al nome mostra il numero di versione. Non è il caso di chi ha OpenERP, che per definizione gira su server proprio.

Annota il numero completo, non solo la generazione. La distanza tra la versione di partenza e una versione supportata è la variabile che pesa di più su tutto il resto.

Cosa comporta restare su una versione fuori supporto

La politica di supporto di Odoo è pubblica e ha regole precise. Ogni versione maggiore riceve supporto standard per tre anni, che comprende assistenza, correzione dei bug e aggiornamenti di sicurezza.

Oltre i tre anni esiste un supporto esteso, soggetto a un costo aggiuntivo obbligatorio, che comprende assistenza e correzione dei bug nei limiti della fattibilità tecnica. Non è un prolungamento automatico e non copre tutto.

Una versione OpenERP si trova quindi molto oltre la finestra, e le conseguenze si distribuiscono su quattro piani diversi.

Sicurezza

Gli aggiornamenti di sicurezza fanno parte del supporto standard. Fuori da quella finestra le vulnerabilità note restano dove sono e l’unica difesa è perimetrale: rete, accessi, esposizione del server. Il peso cambia molto a seconda che il gestionale sia raggiungibile da internet o solo dalla rete interna, ed è una delle prime cose da stabilire.

Conformità fiscale italiana

È il punto più concreto per il mercato italiano, perché gli adempimenti cambiano nel tempo e una versione ferma non riceve gli aggiornamenti di localizzazione.

Sul fronte della comunità, la raccolta di moduli italiani mantenuta da OCA nel progetto l10n-italy è un buon indicatore dello stato reale delle cose. Questa è la situazione dei rami di manutenzione al 26 luglio 2026.

Due letture emergono da questi numeri. La prima: il ramo dell’epoca OpenERP non riceve interventi dal 2016, quindi su quelle installazioni la localizzazione italiana è ferma a com’era allora.

La seconda riguarda chi deve scegliere un traguardo: la comunità italiana concentra il lavoro sulle versioni pari. I rami 15 e 17 sono aperti ma vuoti, mentre 14, 16 e 18 sono popolati e aggiornati di recente. Il ramo 19 è appena partito.

Compatibilità con il resto del sistema

Moduli di terze parti, connettori verso e-commerce, integrazioni con macchinari o con software di reparto smettono progressivamente di essere mantenuti sulle versioni vecchie.

Il vincolo riguarda anche lo stack sottostante: Odoo 19 richiede PostgreSQL 13 o superiore e Python 3.10 o superiore, requisiti alzati rispetto al passato. Un server che ospita OpenERP da anni ha quasi sempre componenti troppo datate per reggere una versione recente senza interventi.

Competenze reperibili

Chi sa lavorare su versioni molto vecchie diventa raro, e l’effetto si vede sui tempi di intervento più che sulla tariffa oraria. Il rischio concreto non è il costo dell’assistenza ordinaria: è il tempo che serve a trovare qualcuno il giorno in cui il sistema si ferma e la fatturazione si blocca.

Le tre strade possibili

Sono tre, non due, e vanno considerate tutte prima di decidere.

1. Restare dove si è

È una scelta legittima, e la documentazione ufficiale la riconosce esplicitamente: su installazione in sede si può restare sulla stessa versione a tempo indeterminato, pur non essendo la strada consigliata.

Ha senso quando il sistema è stabile, i processi non stanno cambiando e l’orizzonte aziendale è breve. Un passaggio societario o una cessione previsti a due anni sono motivi validi per non muovere nulla adesso.

Se è questa la scelta, va accompagnata da backup verificati con un ripristino reale, dalla riduzione dell’esposizione di rete del server e da una mappa scritta delle personalizzazioni. L’ultima serve comunque il giorno in cui si deciderà di muoversi.

2. Migrare a una versione recente

Portare dati e configurazioni su una versione supportata mantenendo l’impianto attuale. Non è un aggiornamento nel senso comune del termine: è un progetto con analisi, test e collaudo. Ha senso quando i processi funzionano e si vogliono conservare, quando lo storico serve quasi tutto e quando le personalizzazioni sono poche o ben documentate.

3. Ripartire da una nuova installazione

Installazione pulita di una versione recente, riporto delle sole anagrafiche e dei saldi necessari, vecchio sistema archiviato in sola lettura per la consultazione. Ha senso quando le personalizzazioni accumulate rendono la conversione più costosa della ricostruzione, e quando i processi attuali sono lontani da quelli che l’azienda vorrebbe. In quel caso portarsi dietro il vecchio impianto significa pagare due volte.

Una volta scelta la direzione, la parte esecutiva ha regole sue: fasi, ambienti di test, collaudo e messa in produzione. È trattata nella guida alla migrazione Odoo. Il tema delle personalizzazioni accumulate negli anni, che è quasi sempre il nodo che decide, è approfondito nella pagina sulle personalizzazioni Odoo.

Cosa determina la fattibilità tecnica

Prima di parlare di tempi e costi vanno verificati quattro vincoli. Non sono opinioni di metodo: sono regole della piattaforma e valgono a prescindere da chi esegue il lavoro.

Il traguardo non lo scegli del tutto

Si può partire da qualsiasi versione, ma si può arrivare solo a una versione supportata. L’ultima versione uscita dal supporto resta un traguardo ammesso per sei mesi dopo la fine del ciclo, poi non lo è più.

Per chi parte da OpenERP significa che il punto di arrivo è una delle versioni recenti, non una versione intermedia scelta per comodità.

Il salto è diretto

Non serve attraversare una versione alla volta. La documentazione ufficiale descrive il passaggio come diretto dalla versione di partenza a quella di destinazione, e l’esempio che riporta salta due generazioni in un colpo solo. Questo cambia il calcolo dei tempi rispetto a quanto molti si aspettano.

I moduli custom sono il vincolo bloccante

Un database che contiene moduli personalizzati non può essere aggiornato finché non esiste una versione di quei moduli compatibile con il traguardo. Il codice custom va portato avanti in parallelo alla conversione dei dati, non dopo.

Questo è il motivo per cui la mappa delle personalizzazioni è il primo deliverable di qualsiasi valutazione seria, prima ancora di qualsiasi stima.

Cosa copre l’assistenza ufficiale e cosa no

Con un abbonamento Enterprise il servizio di upgrade verso la versione più recente è incluso. Copre le applicazioni standard, le personalizzazioni realizzate con Studio finché Studio resta installato e l’abbonamento attivo, e gli sviluppi coperti da un contratto di manutenzione delle personalizzazioni.

Non copre la pulizia dei dati preesistenti, i moduli aggiuntivi privi di contratto di manutenzione, siano essi interni o realizzati da terzi compresi i partner, e la formazione sulle funzionalità nuove. Restano fuori dal perimetro anche il ritorno a una versione precedente, il cambio di edizione, il cambio del tipo di hosting e la migrazione da un altro gestionale.

I dati, la parte più delicata

Su un sistema che gira da dieci anni la questione non è tecnica ma di selezione. Non tutto quello che c’è deve arrivare dall’altra parte.

Le anagrafiche di clienti, fornitori e articoli si portano quasi sempre, ma vanno ripulite prima e non dopo: duplicati, contatti non più attivi, codici articolo dismessi. Portare sporcizia significa pagarne la conversione e poi conviverci.

Lo storico dei documenti richiede una decisione esplicita: serve tutto nel sistema attivo o basta la consultazione? Molte aziende portano gli ultimi esercizi e tengono il resto in archivio, riducendo in modo sensibile il perimetro del lavoro.

I movimenti contabili hanno vincoli propri, legati alla chiusura degli esercizi e agli obblighi di conservazione, e vanno trattati con il commercialista prima di decidere. Gli allegati sono il punto che sfugge più spesso: risiedono su filesystem e non nel database, quindi richiedono un’operazione separata.

Dopo il passaggio serve una verifica sui numeri e non a campione visivo: saldi contabili, giacenze, partite aperte, totali per esercizio. Nel nostro metodo la migrazione dei dati è una fase dedicata con un proprio collaudo, non un’appendice dell’installazione.

Quanto dura e da cosa dipende

Una stima data prima di aver guardato il sistema non è una stima. Le variabili che determinano la durata sono però sempre le stesse quattro, e si possono valutare in poche giornate.

• Numero di moduli realmente in uso. Non quelli installati: quelli usati. La differenza è spesso ampia e riduce il perimetro.
• Quantità e qualità delle personalizzazioni. Codice documentato e ordinato si porta avanti, codice stratificato da autori diversi va spesso riscritto.
• Anni di storico da portare. Incide sui tempi di conversione e su quelli di verifica, che di solito sono i più lunghi.
• Qualità dei dati di partenza. È la variabile che sposta di più il risultato, ed è anche l’unica su cui l’azienda può lavorare da sola prima di iniziare.

Gli ordini di grandezza economici di un progetto Odoo in Italia, con le voci che li compongono, sono descritti nella guida su quanto costa implementare Odoo in Italia.

Domande frequenti

OpenERP e Odoo sono la stessa cosa?

Sì. È lo stesso software, con lo stesso codice di base e la stessa continuità di sviluppo. OpenERP è il nome usato fino alla versione 7, Odoo è il nome dalla versione 8 in avanti.

Da che versione OpenERP è diventato Odoo?

Dalla versione 8. Nel codice della 7 il prodotto si dichiara ancora come OpenERP Server, nella 8 come Odoo. Il pacchetto di distribuzione è stato rinominato il 17 settembre 2014. Il cambio di licenza da AGPLv3 a LGPLv3 è arrivato invece con la versione 9, quindi le due cose non coincidono.

Posso continuare a usare OpenERP senza aggiornare?

Tecnicamente sì: su installazione in sede non esiste una scadenza che blocchi il software. Restano fuori supporto gli aggiornamenti di sicurezza, le correzioni e gli adeguamenti di localizzazione fiscale, quindi la scelta va presa consapevolmente e accompagnata da misure di protezione del server.

Cosa succede alle personalizzazioni fatte negli anni?

Vanno portate sulla versione di destinazione prima che il database possa essere aggiornato: è un vincolo della piattaforma, non una scelta di progetto. Le personalizzazioni realizzate con Studio rientrano nel servizio di upgrade incluso in Enterprise, mentre i moduli sviluppati su misura sono coperti solo se esiste un contratto di manutenzione dedicato.

I miei dati storici si possono portare?

Sì, ma la domanda utile è quanto storico serve nel sistema attivo. Anagrafiche, documenti, movimenti contabili e allegati hanno percorsi e costi diversi, e gli allegati in particolare richiedono un’operazione separata perché non risiedono nel database. Una selezione fatta a monte riduce tempi e rischi.

Su quale versione conviene arrivare?

Il traguardo deve essere una versione ancora coperta da supporto standard. Nella scelta tra due versioni entrambe supportate pesa anche la disponibilità dei moduli italiani della comunità, che storicamente si concentrano sulle versioni pari, e la compatibilità delle integrazioni già in uso.

Serve rifare la formazione al team?

Tra una versione OpenERP e una recente l’interfaccia è cambiata molto, quindi una formazione va prevista. Va messa a budget a parte: la formazione sulle funzionalità della nuova versione non rientra nei servizi di upgrade inclusi nell’abbonamento Enterprise.

Come si arriva a una decisione

Non serve decidere subito tra le tre strade. Servono tre informazioni: il numero di versione esatto, l’elenco delle personalizzazioni con il loro stato, e quanti anni di storico devono restare nel sistema attivo. Con questi elementi la scelta si fa quasi da sola, e le opzioni si confrontano su numeri reali invece che su impressioni.