Per decine di migliaia di anni l'uomo ha vissuto prevalentemente di raccolta di frutta e piante e della caccia di animali selvatici. Non esistendo nessuna forma di allevamento, coltivazione o metodi di conservazione, il cibo per la maggior parte dell'anno era scarso, scarso al limite della sopravvivenza.
In pochissimi altri periodi invece, per fortunate circostanze quasi sempre non prevedibili, il cibo era abbondante. Consci della precarietà della situazione gli antichi cacciatori-raccoglitori, quando il cibo era abbondante, erano soliti mangiare il più possibile facendo scorta di grassi per gli inevitabili periodi di magra successiva.
Questo comportamento è stato la norma per così tanto tempo che è restato scolpito nel nostro DNA. Si pensa infatti che una delle cause del problema dell'obesità moderna sia dovuto proprio a questo retaggio dei nostri progenitori cacciatori-raccoglitori. Se continuiamo a mangiare anche quando oramai la fame è un ricordo del passato è a causa del genetico terrore di periodi di magra che non arriveranno mai.
Spesso viene utilizzato il termine migrazione anche per il semplice aggiornamento di versione di un software (di solito ad una major version più recente). Questo perché in moltissimi casi i progetti di migrazione a versioni di software più recenti, sono terrificanti, nei modi, nei tempi e spesso anche nei risultati. Non puoi chiamarlo "aggiornamento" .. E' qualcosa di peggio. Migrazioni di questo tipo sono progetti talmente lunghi e faticosi che spesso hanno un costo più elevato dell'implementazione iniziale e quando si termina, la versione a cui si è migrati è già vecchia.
Negli anni sono stati coniati termini fantasiosi come Migrazione conservativa, parziale o temporanea, illudendosi di poter migrare solo alcune parti lasciando il resto alla versione precedente (come se si potesse traslocare selezionando solo pochi effetti personali e portando poi tutta la vecchia casa dentro una stanza del nuovo appartamento).
Tali abomini hanno portato a software mitologici (a volte denominati paleolitici più che monolitici [cit]) che non hanno fatto altro che rimandare (oltre che ingigantire) il problema.
Questo comportamento è stato adottato per così tanto tempo (e per molti lo è tuttora) che il timore della migrazione è oramai entrato nel DNA di ogniIT.
A causa di questo terrore ancestrale anche i progetti di nuova implementazione vengono strutturati affinché il software rilasciato duri il più possibile in modo che la migrazione o l'aggiornamento spetti a qualcun'altro (sperando di andare in pensione o di cambiare azienda prima). Questo approccio rende il software naturalmente repulsivo alla migrazione o a qualsiasi aggiornamento creando quindi ancora più problemi e ancora più terrore.
In questa situazione le aziende (a volte impropriamente chiamate clienti) vengono portate ad associare il software ad asset di durata decennale (come fosse una casa o un fabbricato) e non come un servizio così come naturalmente dovrebbe essere.
Per poter scardinare questo concetto bisogna partire delle cause ancestrali e quindi anche dal problema della migrazione.
Decidere di avere terrore di questo tipo di migrazione è una scelta. E' una scelta a volte conscia altre volte inconscia. Di come viene sviluppato il software, di che tipo di architettura adottiamo, del framework o del prodotto che abbiamo scelto, di quanto custom vogliamo, ecc..
Fortunatamente esistono delle scelte architetturali o dei prodotti, che aiutano a risolvere a monte questo tipo di problema. La politica della migrazione automatica di odoo ne è un esempio. Chi decide di utilizzare odoo enterprise ha la migrazione all'ultima versione sempre inclusa. odoo è sviluppato non per evitare la migrazione/aggiornamento ma per renderla semplice, veloce e automatizzabile anche per chi decide di avere il software in casa (on premise). Vi sono dei team appositi che mappano le differenze tra versioni e sviluppano/migliorando continuamente un tool automatico affinché la migrazione sia immediata.
Per fare un esempio l'ultimo progetto di migrazione a cui ho lavorato è stato per un'azienda che è passata dalla versione 8 odoo community alla versione 12 enterprise quindi 4 versioni. E grazie al tool automatico ci siamo potuti permettere di dare quel servizio gratuitamente (non caricandolo su altri costi).
Ci vorrà del tempo .. ma se tutti applicassero questa logica a monte, facendo anche questa valutazione nella scelta del software o dell'architettura corretta, il terrore della migrazione sarà un ricordo del passato. A quel punto bisognerà trovare il modo di estirparlo dal nostro DNA ma questo sarà un altro problema!