Migrazione ERP standard a sistema custom

La migrazione da un ERP standard a un sistema custom integrato è il passaggio da un gestionale a licenza, pensato per adattarsi a molte aziende diverse, a un software costruito su misura attorno ai processi reali di una singola impresa. Si sceglie questa strada quando l'ERP a pacchetto ha smesso di seguire il modo in cui l'azienda lavora davvero, e ogni personalizzazione aggiuntiva costa più di quanto renda.

Cosa significa migrare da un ERP standard a un sistema custom integrato

Un ERP standard nasce per coprire un ventaglio ampio di casi d'uso. Magazzino, contabilità, produzione, vendite: tutto dentro un'unica suite pensata per funzionare, con qualche adattamento, in aziende molto diverse tra loro. È un compromesso ragionevole quando l'azienda è giovane o i processi sono ancora simili a quelli standard di settore.

Il problema nasce quando l'azienda cresce, si specializza, apre nuovi canali di vendita o integra macchinari IoT, e il gestionale continua a chiedere di piegare l'operatività dentro i suoi moduli predefiniti.

Migrare verso un sistema custom integrato significa ribaltare il rapporto tra software e processo. Non è più l'azienda ad adattarsi alle funzionalità disponibili nel pacchetto, ma è il software a essere progettato attorno al modo in cui l'azienda produce, vende e gestisce i propri dati.

Questo non significa necessariamente buttare via tutto quello che già esiste: spesso la migrazione riguarda solo i moduli più critici, mentre altri sistemi restano al loro posto e vengono collegati tramite un layer di integrazione dedicato, costruito sulla logica di business specifica e senza i costi ricorrenti di licenza tipici delle suite a pacchetto.

Perché i limiti di un ERP standard emergono dopo i primi anni

Nei primi due o tre anni di utilizzo, un ERP standard funziona quasi sempre bene: copre i flussi base, riduce il caos dei fogli Excel sparsi tra i reparti e dà una prima vista unificata sui dati. I problemi arrivano più avanti, quando l'azienda ha continuato a evolversi e il gestionale è rimasto ancorato al proprio impianto originario. Non è un difetto del prodotto: è la natura stessa di un software pensato per adattarsi a molte aziende diverse, che non può inseguire ogni evoluzione specifica di ciascun cliente.

Tre limiti in particolare tendono a manifestarsi in sequenza, quasi sempre nello stesso ordine. Il primo è economico, e riguarda il modo in cui crescono i canoni di licenza e i moduli aggiuntivi. Il secondo è organizzativo, e riguarda quanto i processi aziendali vengono piegati dentro un template che non gli appartiene. Il terzo è tecnico, e riguarda la difficoltà crescente di far dialogare il gestionale con il resto dell'ecosistema digitale dell'azienda. Vale la pena guardarli uno per uno, perché raramente arrivano isolati.

I costi di licenza e dei moduli aggiuntivi che crescono nel tempo

Un ERP a pacchetto si paga per utente, per modulo o per entrambi, e ogni funzionalità aggiuntiva che l'azienda scopre di avere bisogno, dalla gestione di un nuovo canale di vendita a un cruscotto di reportistica più avanzato, spesso significa attivare un modulo a parte con un canone ricorrente proprio. Nel tempo questi costi si sommano in modo silenzioso: non c'è una singola voce che sembra eccessiva, ma la somma dei canoni annuali per moduli, utenti aggiuntivi e personalizzazioni fatte dal fornitore diventa una cifra rilevante, senza che l'azienda abbia mai davvero deciso di spendere quella cifra in un'unica soluzione.

A questo si aggiunge un secondo effetto meno visibile ma altrettanto costoso, quello del lock-in. Più moduli proprietari vengono attivati, più diventa difficile e oneroso cambiare fornitore in futuro, perché dati, configurazioni e integrazioni sono legati a un ecosistema chiuso. Un sistema custom integrato, al contrario, non prevede canoni di licenza per funzionalità: il costo è concentrato nello sviluppo iniziale e nella manutenzione evolutiva, e l'azienda resta proprietaria del codice e dell'architettura, senza dipendere dalle scelte commerciali di un vendor terzo.

Processi aziendali forzati dentro un template che non rispecchia il lavoro reale

Ogni ERP standard incorpora assunzioni implicite su come dovrebbe funzionare un'azienda del suo settore di riferimento. Quando i processi reali si discostano da quelle assunzioni, e succede quasi sempre man mano che l'azienda si specializza, gli utenti iniziano a trovare soluzioni informali: un foglio Excel parallelo per gestire un'eccezione che il gestionale non contempla, una procedura manuale per un controllo che il sistema non fa, un doppio inserimento perché due reparti hanno bisogno dello stesso dato con un livello di dettaglio diverso.

Questi aggiustamenti informali, presi singolarmente, sembrano innocui. Sommati, creano un secondo sistema informativo parallelo, fatto di file sparsi e conoscenza tribale che vive solo nella testa di chi lo usa ogni giorno.

Quando quella persona cambia ruolo o lascia l'azienda, il processo si spezza. Un sistema custom integrato viene invece costruito partendo dal modello dati reale dell'azienda, non dal template del fornitore: il magazzino ha il livello di dettaglio che serve al magazzino, l'ufficio acquisti quello che serve a lui, senza che nessuno dei due debba forzare il proprio modo di lavorare dentro una struttura pensata per un'altra azienda.

La difficoltà di integrare ERP gestionale ecommerce CRM e dispositivi IoT

Un terzo limite, spesso il più concreto tra tutti, riguarda l'integrazione ERP con il resto dell'ecosistema digitale dell'azienda. Molti ERP standard offrono connettori preconfigurati verso i CRM e le piattaforme e-commerce più diffuse, ma quei connettori funzionano bene solo finché ci si muove dentro i casi d'uso previsti dal fornitore. Appena servono trasformazioni dati particolari, sincronizzazioni condizionali o il collegamento con dispositivi IoT e macchinari di produzione, il connettore preconfezionato smette di bastare.

A quel punto l'azienda si trova davanti a due strade. La prima è affidarsi a un middleware di terze parti, con un ulteriore canone ricorrente e un ulteriore punto di fragilità nella catena. La seconda è costruire un layer di integrazione su misura, pensato sulla logica di business specifica: API RESTful o GraphQL documentate, message broker per i flussi ad alto volume, protocolli dedicati per i dispositivi sul campo.

È esattamente il tipo di lavoro su cui si basa un servizio di integrazione sistemi costruito su misura, ed è spesso il primo passo concreto verso una migrazione più ampia, perché mette in evidenza quanto il gestionale standard sia distante dal modo in cui i sistemi dell'azienda devono davvero parlarsi.

Le differenze tra ERP standard e sistema custom integrato

Mettere a confronto le due strade aiuta a capire dove si gioca davvero la decisione. Non è una questione di qualità del software, ma di adattamento tra strumento e organizzazione: un ERP standard è pensato per essere implementato rapidamente su una base di casi d'uso comuni, un sistema custom integrato è pensato per seguire esattamente i processi di una singola azienda, con tutto quello che questo comporta in termini di tempi, costi e flessibilità.

Le differenze principali che emergono confrontando le due opzioni sono queste.

• Modello di costo. L'ERP standard prevede canoni ricorrenti per utenti e moduli, che crescono nel tempo. Il sistema custom concentra l'investimento nello sviluppo iniziale e nella manutenzione evolutiva, senza licenze per funzionalità.
• Adattamento ai processi. L'ERP standard richiede di adattare i processi aziendali al software, con eccezioni gestite fuori sistema. Il sistema custom viene costruito attorno ai processi reali, comprese le eccezioni operative.
• Tempi di attivazione iniziale. Un ERP standard può essere operativo in poche settimane sui moduli base. Un sistema custom richiede una fase di analisi e sviluppo più lunga, compensata da una minore necessità di adattamenti futuri.
• Integrazione con altri sistemi. L'ERP standard si integra bene con i software per cui esistono connettori preconfezionati. Il sistema custom nasce con un'architettura API pensata per l'ecosistema specifico dell'azienda, CRM, ecommerce e dispositivi IoT inclusi.
• Proprietà e dipendenza dal fornitore. Con l'ERP standard l'azienda dipende dalle scelte commerciali e dalla roadmap del vendor. Con il sistema custom l'azienda resta proprietaria del codice e dell'architettura.

Nessuna delle due opzioni è oggettivamente superiore. Un'azienda giovane, con processi ancora simili a quelli standard del proprio settore, trae valore reale da un ERP a pacchetto. Un'azienda che ha superato quella fase, e che vede i propri processi diventare sempre più un'eccezione rispetto al template del fornitore, inizia invece a pagare più di quanto riceve in cambio, ed è lì che la conversazione sul sistema custom diventa concreta.

I segnali che indicano che è il momento di valutare un sistema custom

Non esiste un momento oggettivo e universale in cui un'azienda deve necessariamente lasciare il proprio ERP standard. Esistono però alcuni segnali ricorrenti che, quando si presentano insieme, indicano che vale la pena avviare una valutazione seria, prima che i costi nascosti del sistema attuale continuino ad accumularsi silenziosamente.

I segnali più frequenti, riscontrati nei progetti di migrazione reali, sono questi.

• L'azienda mantiene fogli di calcolo paralleli per gestire eccezioni operative che il gestionale non prevede.
• Ogni nuova funzionalità richiesta al fornitore dell'ERP comporta un preventivo separato e tempi di attesa lunghi.
• I reparti reinseriscono manualmente gli stessi dati in più sistemi perché i connettori standard non coprono il caso specifico.
• La somma dei canoni per moduli, utenti aggiuntivi e personalizzazioni è aumentata in modo significativo negli ultimi anni.
• L'azienda ha introdotto dispositivi IoT, un nuovo canale ecommerce o un CRM che il gestionale fatica a integrare in modo stabile.
• Le decisioni strategiche vengono rallentate perché i dati sono frammentati tra sistemi diversi e nessuno si fida del numero che vede a schermo.

Quando due o tre di questi segnali coesistono, il costo dell'immobilismo, misurato in ore di lavoro qualificato perse in copia e incolla e in decisioni prese su dati non allineati, tende a superare rapidamente il costo di un progetto di migrazione ben pianificato.

Non è un caso isolato: le PMI italiane che lavorano con sistemi non integrati perdono, secondo l'Osservatorio Digital Innovation del Politecnico di Milano, una quota rilevante della produttività amministrativa in attività di inserimento dati ridondante, tempo che un'architettura integrata restituisce quasi interamente.

Come si svolge un progetto di migrazione verso un sistema custom integrato

Una migrazione da ERP standard a sistema custom non è un intervento che si fa dall'oggi al domani, né dovrebbe esserlo: la sua forza, rispetto a un'implementazione ERP a pacchetto, sta proprio nel tempo dedicato a capire come l'azienda lavora davvero, prima di scrivere una sola riga di codice. Un progetto ben condotto si articola in fasi distinte, ciascuna con un obiettivo preciso e un output verificabile, così da ridurre al minimo le sorprese lungo il percorso.

Le cinque fasi descritte di seguito, analisi e progettazione, sviluppo, integrazione, migrazione dei dati e assistenza dopo il go live, non sono un modello teorico ma il percorso seguito nei progetti IT che toccano gestionali ERP, CRM e sistemi legacy. Ogni fase produce un output concreto che il cliente può verificare prima di passare alla successiva, invece di scoprire lo stato reale del progetto solo al momento della consegna finale.

Analisi e progettazione mappatura dei processi e dei dati esistenti

Tutto parte da una fase di analisi e progettazione approfondita, in cui il team tecnico mappa i processi reali dell'azienda, non quelli descritti nella documentazione ufficiale, ma quelli effettivamente seguiti ogni giorno, comprese le eccezioni gestite fuori sistema. Questa fase include anche un censimento del patrimonio dati esistente nell'ERP attuale, per capire quali informazioni sono affidabili, quali duplicate e quali andranno pulite prima ancora di iniziare il trasferimento.

L'output di questa fase è uno studio di fattibilità che definisce perimetro, obiettivi, tempi indicativi e criteri di successo del progetto. È il momento in cui si decide anche cosa migrare davvero e cosa invece può restare nell'ecosistema esistente, integrato tramite API piuttosto che sostituito. Una mappatura fatta con cura in questa fase riduce in modo significativo il rischio di scope creep più avanti, quando cambiare idea sui requisiti costa molto di più.

Sviluppo del sistema secondo la logica di business reale

Con il modello dati e i processi mappati, si passa allo sviluppo vero e proprio del sistema custom. In questa fase la scelta dell'approccio incide molto sui tempi e sulla qualità del risultato: un framework di sviluppo già predisposto a configurare moduli, servizi e integrazioni comuni permette di costruire soluzioni digitali flessibili senza dover ripartire da zero su ogni singolo componente, contenendo sia i tempi sia i costi rispetto a uno sviluppo interamente custom dalla prima riga di codice.

Il lavoro procede tipicamente per micro team autonomi e multidisciplinari, con analisti, sviluppatori backend e frontend ed esperti DevOps coordinati da un project manager dedicato, secondo un approccio agile orientato a rilasci frequenti e verificabili piuttosto che a un'unica consegna finale dopo mesi di sviluppo isolato. Questo permette all'azienda cliente di vedere progressi concreti lungo tutto il percorso, e di correggere la rotta presto se qualcosa non corrisponde alle aspettative, invece di scoprirlo solo al momento del collaudo finale.

Integrazione con ERP CRM ecommerce e dispositivi sul campo

Un sistema custom raramente sostituisce in blocco tutto l'ecosistema software di un'azienda. Più spesso convive con un CRM che funziona bene, una piattaforma e-commerce già consolidata o dispositivi IoT distribuiti sul campo. La fase di integrazione costruisce il livello di comunicazione tra il nuovo sistema e tutto ciò che resta al suo posto, tramite API RESTful o GraphQL documentate, protocolli dedicati per i dispositivi IoT come MQTT e HTTP, e bus di messaggistica per i flussi di dati ad alto volume che richiedono affidabilità anche nei picchi di carico.

Questa fase è spesso quella che genera il ritorno più immediato e misurabile, perché elimina i doppi inserimenti manuali e i disallineamenti tra reparti che più fanno percepire, giorno per giorno, l'inefficienza del sistema precedente. È anche la fase in cui la sicurezza va progettata con attenzione, tramite protocolli di autenticazione avanzati come OAuth2 e JWT e canali di comunicazione cifrati, così che l'apertura verso nuovi sistemi non diventi un punto debole nella protezione dei dati aziendali.

Migrazione dei dati test e cut over

Il trasferimento dei dati storici dal vecchio ERP al nuovo sistema è, nella pratica, il momento più delicato dell'intero progetto. Non si tratta di un semplice export e import: ogni tabella va mappata sulla nuova struttura dati, ogni record duplicato o incompleto va gestito con una regola chiara, e ogni personalizzazione presente nel vecchio sistema va valutata caso per caso, replicata nel nuovo standard oppure sostituita con una logica più solida.

Prima del passaggio definitivo, la fase di test verifica l'integrità dei dati migrati con controlli automatizzati e riconciliazioni contro i totali di origine, in particolare sui dati finanziari e di magazzino, dove un errore non rilevato in tempo si traduce in un problema reale sul campo. Il cutover, il momento in cui l'azienda smette di usare il vecchio ERP e passa in modo definitivo al nuovo sistema, va pianificato nei dettagli e con un piano di rollback chiaro, così che un imprevisto in quella finestra critica non si trasformi in un blocco operativo.

Manutenzione evolutiva e assistenza dopo il go live

Il lavoro non finisce al momento del go live. Un sistema custom integrato, proprio perché costruito su misura, ha bisogno di un presidio continuativo che ne segua l'evoluzione insieme a quella dell'azienda: nuove esigenze che emergono con l'uso quotidiano, normative che cambiano, integrazioni aggiuntive che si rendono necessarie col tempo. È il compito della manutenzione e assistenza, che affianca l'azienda ben oltre la messa in produzione.

Questa fase copre anche la gestione dei rischi legati a sistemi di terze parti collegati: quando un CRM o una piattaforma e-commerce aggiorna le proprie API, il layer di integrazione va monitorato e adattato di conseguenza, senza che l'azienda debba occuparsene direttamente. Un sistema documentato fin dall'inizio, con ogni integrazione tracciata e isolata rispetto al core applicativo, rende questi aggiornamenti gestibili invece che rischiosi, ed è uno dei motivi per cui la documentazione tecnica va considerata parte integrante del progetto, non un extra facoltativo.

I rischi di una migrazione ERP e come ridurli

Ogni progetto di migrazione comporta dei rischi, ed è onesto riconoscerli invece di presentare il passaggio a un sistema custom come privo di complessità. La differenza tra un progetto che va a buon fine e uno che accumula ritardi e costi non pianificati sta quasi sempre nel modo in cui questi rischi vengono anticipati, non nella loro assenza.

I rischi più frequenti, e le contromisure che li riducono in modo concreto, sono questi.

• Qualità dei dati di partenza. Dati inconsistenti o duplicati nel vecchio ERP compromettono la migrazione se non vengono puliti in anticipo. La contromisura è avviare la validazione dei dati fin dalla fase di analisi, non a ridosso del trasferimento.
• Scope creep. L'aggiunta continua di nuovi requisiti durante lo sviluppo è la causa più comune di sforamenti di budget e tempi. Un perimetro definito con chiarezza all'inizio, e un processo formale per gestire eventuali cambiamenti, contiene questo rischio.
• Change management sottovalutato. Un sistema tecnicamente perfetto fallisce se le persone che devono usarlo ogni giorno non sono coinvolte fin dall'inizio. Coinvolgere i key user dei reparti principali già in fase di analisi riduce le resistenze al momento del rilascio.
• Cut over mal pianificato. Il passaggio dal vecchio al nuovo sistema è il momento di maggiore esposizione operativa. Un piano di rollback definito con precisione, insieme a una finestra di passaggio concordata con tutti i reparti coinvolti, riduce il rischio di blocchi.
• Dipendenza da un solo fornitore per lo sviluppo. Un sistema custom senza documentazione tecnica adeguata crea una nuova forma di dipendenza. Documentazione API completa e codice ben strutturato mantengono l'azienda libera di cambiare partner tecnico in futuro, se necessario.

Vale la pena inserire qui un dato di contesto, utile a inquadrare la dimensione del rischio anche nei progetti ERP tradizionali: secondo le analisi di Gartner sulle implementazioni ERP, una quota molto ampia dei progetti recenti rischia di non centrare gli obiettivi di business originari entro pochi anni dal go live. Questo non significa che ogni migrazione sia destinata a incontrare difficoltà, ma conferma che una pianificazione rigorosa, e non l'entusiasmo iniziale, è ciò che separa un progetto riuscito da uno che si trascina.

ERP standard o sistema custom quale scegliere in base al contesto aziendale

Non esiste una risposta valida per tutte le aziende, e diffidare di chi la propone come tale è un buon primo criterio di valutazione. La scelta dipende da quanto i processi aziendali si sono allontanati dal template standard del proprio settore, da quante integrazioni complesse servono con l'ecosistema digitale esistente, e da quanto pesa, nel tempo, il costo cumulato di licenze e personalizzazioni rispetto a un investimento concentrato nello sviluppo su misura.

Un'azienda con processi ancora vicini agli standard di settore, con un numero contenuto di integrazioni e con l'esigenza di essere operativa in tempi brevi, trova spesso nell'ERP a pacchetto la soluzione più pragmatica, almeno in questa fase della propria crescita.

Un'azienda che invece riconosce nei segnali descritti in questa pagina, canoni crescenti, processi forzati dentro un template, integrazioni sempre più complicate, la propria situazione attuale, ha buone probabilità di ottenere un ritorno concreto da un sistema costruito attorno al proprio modo di lavorare, con un'architettura modulare pronta ad accogliere l'evoluzione futura senza dover essere ricostruita da capo.

La strada più solida per decidere resta una valutazione tecnica indipendente, che confronti i costi reali, oggi e nei prossimi anni, delle due opzioni sul caso specifico dell'azienda, prima di impegnarsi in una direzione o nell'altra.

Domande frequenti sulla migrazione da ERP standard a sistema custom

Le domande raccolte qui sotto rispondono alle obiezioni più comuni che emergono nella fase di valutazione, quella in cui un'azienda ha già riconosciuto i limiti del proprio ERP standard ma non ha ancora deciso se e come muoversi verso un sistema custom integrato.

Sono le stesse domande che tornano, con parole diverse, in quasi ogni primo colloquio conoscitivo con un cliente che sta considerando questo passaggio, ed è per questo che vale la pena affrontarle qui in modo diretto, senza rimandare ogni dettaglio a una fase di preventivo successiva.

Le risposte che seguono non sostituiscono un'analisi preliminare costruita sul caso specifico, ma danno un quadro realistico su cui iniziare a ragionare, prima ancora di contattare un fornitore per un primo confronto.

Quanto costa migrare da un ERP standard a un sistema custom integrato

Il costo dipende dal numero di processi coinvolti, dalla complessità dei dati da migrare e dal numero di sistemi terzi da integrare, per questo motivo, qualunque cifra generica va presa con cautela. Quello che si può dire con certezza è come si distribuisce il costo nel tempo: mentre un ERP standard comporta un investimento iniziale più contenuto seguito da canoni ricorrenti che crescono con ogni modulo aggiuntivo, un sistema custom concentra l'investimento nella fase di sviluppo iniziale, per poi richiedere principalmente costi di manutenzione evolutiva, senza licenze per funzionalità.

Nel confronto sul lungo periodo, tipicamente da tre anni in su, il sistema custom recupera spesso la differenza iniziale proprio grazie all'assenza di canoni crescenti e alla riduzione delle ore di lavoro perse in attività manuali e ridondanti. Una stima realistica va comunque costruita sul caso specifico, a partire da un'analisi preliminare dei processi e dei sistemi coinvolti, non da un listino generico applicabile a qualsiasi azienda.

Quanto tempo richiede la migrazione da un ERP standard a un sistema custom

I tempi variano molto in base al perimetro del progetto. Una migrazione che riguarda un singolo processo critico, con un numero limitato di integrazioni, può essere completata in poche settimane dalla fase di analisi al go live. Un progetto più ampio, che tocca contabilità, magazzino, vendite e integrazione con CRM, e-commerce e dispositivi IoT, richiede tipicamente diversi mesi, distribuiti tra analisi, sviluppo, migrazione dati e test.

Il primo incontro di valutazione serve proprio a costruire una stima realistica su questi tempi, ed è parte dell'analisi preliminare che precede qualunque avvio dei lavori. Un elemento che incide molto sulla durata complessiva è la qualità dei dati di partenza: un ERP con anni di dati inconsistenti o duplicati richiede una fase di pulizia più lunga rispetto a un sistema già ben tenuto, ed è un fattore che vale la pena valutare fin dai primi colloqui con il fornitore.

Anche il numero di reparti coinvolti pesa sulla stima: un progetto che tocca un solo processo si pianifica con margini più stretti rispetto a uno che attraversa contabilità, magazzino e vendite insieme, dove ogni reparto porta le proprie eccezioni operative da mappare.

È possibile migrare senza fermare l'operatività dell'azienda

Sì, ed è quasi sempre l'approccio preferibile rispetto a un passaggio unico e totale. Un approccio graduale, che migra prima i processi meno critici e solo in seguito quelli centrali per l'operatività quotidiana, riduce sensibilmente il rischio percepito e permette a persone e sistemi di adattarsi progressivamente al nuovo strumento. In molti casi, alcuni sistemi esistenti restano semplicemente al loro posto e vengono collegati al nuovo sistema custom tramite un layer di integrazione, senza bisogno di sostituirli.

Questo approccio richiede una pianificazione più attenta rispetto a un passaggio unico, perché per un periodo di transizione il vecchio e nuovo sistema convivono e devono restare sincronizzati. È un costo di coordinamento aggiuntivo, ma nella maggior parte dei progetti reali vale ampiamente la riduzione del rischio operativo che ne deriva, soprattutto per le attività che l'azienda non può permettersi di interrompere nemmeno per un giorno.

La scelta di quali processi migrare per primi va discussa fin dalla fase di analisi, dando priorità a quelli meno critici per l'operatività quotidiana, così da testare l'approccio prima di affrontare i processi che davvero non possono permettersi un fermo.

Cosa succede ai dati storici presenti nel vecchio ERP

I dati storici vengono mappati sulla nuova struttura dati e trasferiti attraverso un processo di migrazione controllato, che prevede verifiche di integrità su ogni modulo e riconciliazione contro i totali di origine, in particolare per i dati finanziari e di magazzino. Le personalizzazioni e le configurazioni uniche presenti nel vecchio sistema vengono valutate caso per caso, alcune vengono replicate nel nuovo sistema, altre sostituite con una logica più solida se quella originaria era un rimedio temporaneo diventato permanente per necessità.

Il vecchio ERP, nella maggior parte dei progetti, non viene disattivato immediatamente al momento del cutover, ma resta accessibile in sola lettura per un periodo definito, così da poter consultare lo storico in caso di dubbi o discrepanze emerse dopo il passaggio. Questo margine di sicurezza fa parte di una pianificazione prudente e riduce lo stress del momento del passaggio definitivo, e permette al team interno di verificare con calma che ogni informazione critica sia arrivata correttamente nel nuovo sistema prima di considerare chiuso il progetto.

Un sistema custom integrato è più rischioso di un ERP di un grande fornitore

Non necessariamente, ma il tipo di rischio è diverso e va gestito con strumenti diversi. Un ERP di un grande fornitore riduce il rischio tecnologico legato allo sviluppo, perché il prodotto è già testato su migliaia di installazioni, ma introduce una dipendenza dalle scelte commerciali e dalla roadmap del vendor, oltre al rischio, non teorico, che l'implementazione non rispecchi davvero i processi dell'azienda. Un sistema custom elimina quella dipendenza esterna, ma sposta la responsabilità sulla qualità del partner tecnico scelto per costruirlo.

La contromisura principale, in questo secondo caso, è la documentazione. Un sistema custom con documentazione tecnica completa, API documentate secondo standard aperti come Swagger o OpenAPI, e un'architettura modulare ben strutturata, resta gestibile e trasferibile anche se in futuro l'azienda decidesse di cambiare fornitore per la manutenzione. È questo, più della tecnologia scelta, il vero indicatore della qualità e della sostenibilità nel tempo di un progetto custom.