Se domattina il gestionale non si aprisse, il team saprebbe dove trovare le consegne in corso, i contatti dei clienti e le scadenze della settimana? Per molte piccole e medie imprese la risposta onesta è no: anni di preventivi, pratiche e telefonate vivono dentro un unico programma, e finché tutto funziona nessuno si chiede cosa accadrebbe se venisse a mancare. Cambiare software gestionale diventa urgente proprio nel momento peggiore, quando gli aggiornamenti si fermano, il fornitore ritocca il listino o il programma smette di reggere il volume di lavoro.
Cambiare software gestionale, operazione detta anche migrazione del gestionale, significa trasferire i dati dei clienti, i processi e le abitudini quotidiane da un sistema in dismissione a uno nuovo, senza interrompere il servizio. Riguarda qualsiasi realtà che gestisce clienti, commesse o scadenze all'interno di un software: studi professionali, agenzie, imprese di servizi, reparti commerciali. Il momento di agire arriva quando il vecchio programma non è più supportato, quando il contratto diventa insostenibile o quando le funzioni non coprono più il modo in cui il team lavora davvero. Con un piano di uscita strutturato, il passaggio si chiude in circa 90 giorni e lascia un archivio pulito, flussi ricostruiti e un team che non teme più il lunedì in cui il vecchio programma non parte.
Questa guida segue una timeline di 90 giorni divisa in tre fasi da 30 giorni, con le attività di ogni fase, chi ne risponde e un punto di non ritorno dichiarato: il momento oltre il quale tornare indietro costa più che andare avanti. Prima della timeline servono due passaggi preliminari: capire quale guasto impone il cambio e mettere al sicuro ciò che non può andare perso.
La decisione di cambiare software gestionale nasce quasi sempre da uno di tre guasti, e riconoscere quale dei tre ti riguarda cambia le priorità del piano. Il guasto tecnico è il più visibile: il fornitore annuncia la fine degli aggiornamenti, il programma gira solo su un sistema operativo ormai fuori supporto, l'integrazione con la fatturazione elettronica smette di funzionare. Un software non più supportato non muore in un giorno: si degrada un pezzo alla volta: prima si fermano le patch di sicurezza, poi la compatibilità con gli altri strumenti, alla fine l'assistenza risponde che “il supporto non è più previsto”.
Più silenzioso è il guasto contrattuale. Il fornitore viene acquisito e la nuova casa madre raddoppia il canone, oppure sposta il prodotto su un piano cloud con condizioni diverse, oppure comunica che la tua versione verrà chiusa entro fine anno. Il programma funziona ancora, ma le condizioni per continuare a usarlo non sono più sostenibili. In questo scenario la data di uscita non la scegli tu: la fissa il contratto, e il piano dei 90 giorni va fatto partire contando all'indietro da quella scadenza.
Il terzo guasto è funzionale, ed è quello che le aziende ignorano più a lungo. Il programma fa ancora quello che faceva dieci anni fa, ma il lavoro è cambiato: i clienti scrivono su canali che il gestionale non registra, metà delle informazioni vive in fogli di calcolo paralleli, il commerciale tiene i contatti sul telefono personale. Quando i file sparsi contengono informazioni più aggiornate del sistema ufficiale, il cambio è già avvenuto nei fatti: manca solo la decisione formale.
Distinguere il guasto serve a stabilire il grado di urgenza. Un blocco tecnico impone scadenze rigide, un problema contrattuale comporta una scadenza già definita, un limite funzionale lascia il tempo di preparare bene l'uscita. In tutti e tre i casi il primo gesto operativo è identico, e non riguarda la scelta del nuovo programma.
Prima di confrontare i fornitori e valutarne le demo, metti al sicuro ciò che nessun nuovo contratto potrà restituirti: i dati e i flussi in corso. Se il guasto è tecnico, questa mossa protegge dal rischio che il vecchio sistema smetta di aprirsi prima del previsto; se è contrattuale, evita che l'accesso venga limitato dopo la disdetta. La sequenza pratica è questa:
Questo lavoro preliminare produce un effetto collaterale prezioso: costringe a guardare i dati per quello che sono. Doppioni, contatti inattivi, campi compilati a metà emergono adesso, quando c'è ancora tempo per pulirli, invece che a metà migrazione. Un'anagrafica ripulita prima del trasloco fa risparmiare ore di correzioni successive e alleggerisce ogni fase successiva del piano.
[BANNER type="lead_banner_1" title="Kit diagnostico adozione strumenti: sondaggio, punteggio, piano" description="Inserisci il tuo indirizzo e-mail per ricevere una guida completa e dettagliata passo dopo passo" picture-src="/upload/medialibrary/c0f/04zrwoo0jpzvirn15czqu595pynw0yl9.webp" file-path="/upload/medialibrary/c43/zogrpcw1auu5p3veevd5xqo13oeuynsj.pdf"]Con i dati al sicuro, parte la fase uno, dal giorno 1 al giorno 30: scegliere il sostituto e preparare l'esportazione completa. Il responsabile naturale di questa fase è il titolare o un responsabile di progetto con potere decisionale, perché le scelte fatte qui vincolano tutto il resto della timeline.
La selezione funziona meglio se viene condotta al contrario rispetto al solito: prima l'elenco dei flussi che il team usa davvero, poi le demo. Scrivi i cinque processi che il vecchio programma copre oggi, per esempio: anagrafica clienti, preventivi, commesse, scadenzario e reportistica, e valuta i candidati solo in base a quei processi. Le funzioni che nessuno userà nei primi sei mesi non devono pesare sulla decisione. Chi sceglie di cambiare software gestionale in base alla brochure, invece che ai propri flussi, compra un nuovo problema per sostituirne uno vecchio.
La prova che vale più di ogni demo è l'importazione nel nuovo sistema di un campione reale. Prendi 50 clienti dall'esportazione già effettuata e caricali nel sistema candidato: se i campi si allineano, gli accenti rimangono intatti e le condizioni commerciali vengono importate integralmente, hai una base solida. Se il campione presenta errori dopo l'importazione, meglio scoprirlo con 50 record che con cinquemila.
Sul piano economico, i costi della migrazione vanno messi in fila prima della firma. Un esempio concreto: un'agenzia di 10 persone paga 250 euro al mese per il vecchio gestionale e ne pagherà 490 per il nuovo. Dal giorno della firma allo spegnimento del vecchio sistema passeranno circa due mesi di licenze sovrapposte, quindi 740 euro al mese per due mesi: 1.480 euro. La pulizia dei dati richiede a una persona interna tre giornate da 8 ore, 24 ore in tutto, e la formazione richiede due sessioni da due ore. Sono cifre da adattare al tuo caso, ma la struttura resta identica: licenze doppie per il periodo di transizione, ore interne di pulizia, ore di formazione.
Il punto di non ritorno della fase uno è la firma del contratto con il nuovo fornitore. Prima della firma puoi ancora cambiare candidato senza perdere nulla; dopo, ogni ripensamento costa denaro e credibilità interna. Firma solo quando il campione di prova è stato importato in modo pulito.
Dal giorno 31 al giorno 60 il team lavora su due sistemi in parallelo: è il doppio binario operativo, il tratto più delicato dell'intero passaggio. Il vecchio gestionale resta acceso per consultare le pratiche storiche, il nuovo diventa il sistema in cui viene avviata ogni nuova attività. Senza una regola chiara su chi scrive dove, questo periodo genera esattamente il caos che il piano voleva evitare. La responsabilità della fase passa a un referente interno della migrazione: una persona sola che risponde dello stato dei dati e a cui i colleghi segnalano ogni anomalia.
La regola che tiene in piedi il doppio binario sta in una riga: a partire dalla data concordata, ogni nuovo dato si inserisce solo nel nuovo sistema. Le pratiche aperte in precedenza si chiudono dove sono nate oppure si trasferiscono in blocco, ma la stessa regola deve valere per tutte, non pratica per pratica. Quella data è anche il punto di non ritorno della fase due: superata la soglia, il vecchio sistema non riceve più inserimenti, e chi lo aggiorna “per abitudine” crea due verità parallele.
La migrazione dei dati vera e propria avviene in questa finestra, e conviene organizzarla a ondate: prima le anagrafiche, poi lo storico selezionato nella fase preliminare, per ultime le pratiche aperte. Dopo ogni ondata, il referente confronta dieci record scelti a caso tra vecchio e nuovo sistema: nomi, importi, date. Dieci controlli puntuali scoprono più errori di un'occhiata generale su mille righe.
La formazione sul nuovo strumento rende di più se segue il lavoro reale invece di anticiparlo. Una sessione di due ore sui flussi di tutti i giorni, poi il team usa il programma su pratiche vere, poi una seconda sessione per rispondere ai problemi incontrati. Chi organizza un corso enciclopedico prima ancora della migrazione si ritrova, al giorno 60, con colleghi che hanno dimenticato tutto.
Resta la comunicazione interna del cambio, la parte che i piani tecnici trascurano più spesso. Ogni persona del team deve sapere tre cose: da quale data si lavora solo nel nuovo sistema, a chi segnalare un dato mancante, cosa rispondere a un cliente se una pratica risulta momentaneamente incompleta. La continuità del servizio dipende da questi tre punti più che dalla tecnologia: i clienti non devono accorgersi del trasloco, e non se ne accorgono se ogni collega sa dove guardare e cosa dire.
[BANNER type="lead_banner_2" blockquote="\"La possibilità di avere statistiche in tempo reale sull'andamento delle vendite, sulle performance individuali e la disponibilità di una vasta gamma di altri dati ci ha permesso di ottimizzare le risorse e orientarci verso processi di successo, scartando altre opzioni meno adatte.\"" user-picture-src='/upload/optimizer/converted/upload/iblock/163/f8n9vwxcwthl77rvthpl57xcdfeli2vs.png.webp?1745406769899' user-name="Proprietario, Emiliano Vicaretti" user-description="SunPark Srl"]Gli ultimi 30 giorni, dal 61 al 90, trasformano il trasloco in normalità. Il lavoro corrente vive ormai nel nuovo sistema; ciò che manca è la verifica finale e lo spegnimento ordinato del vecchio. Saltare questa fase per stanchezza è l'errore che lascia le aziende con due gestionali accesi per anni, un doppio canone e i dati distribuiti tra due sistemi.
Prima di spegnere qualsiasi cosa, il referente ripassa una checklist di chiusura:
Superata la checklist, lo spegnimento diventa un atto formale: revoca degli accessi a tutto il team, disdetta al fornitore secondo i termini del contratto, archivio finale congelato in sola lettura. La revoca degli accessi è il punto di non ritorno della fase tre, ed è una tutela più che una perdita: finché qualcuno può ancora scrivere nel vecchio sistema, la tentazione di tornarci resta viva.
Le nuove abitudini si consolidano con un rito leggero: per quattro settimane, una revisione da quindici minuti in cui il team segnala cosa risulta più lento di prima e cosa manca. Quasi sempre il problema dipende da una configurazione da ritoccare, non da un difetto del programma. La timeline completa, vista in un colpo solo:
|
Fase |
Attività principali |
Chi ne risponde |
Punto di non ritorno |
|
Giorni 1-30 |
Backup dei dati, scelta del sostituto, prova di importazione su un campione di 50 clienti |
Titolare o responsabile di progetto |
Firma del contratto con il nuovo fornitore |
|
Giorni 31-60 |
Migrazione dei dati a ondate, doppio binario operativo, formazione sul nuovo strumento |
Referente interno della migrazione |
Data unica: i dati nuovi entrano solo nel nuovo sistema |
|
Giorni 61-90 |
Verifiche incrociate, spegnimento del vecchio sistema, consolidamento delle abitudini |
Referente interno insieme a tutto il team |
Revoca degli accessi al vecchio gestionale |
Le migrazioni che sforano i 90 giorni inciampano quasi sempre negli stessi punti, e ognuno di questi errori manda un segnale riconoscibile settimane prima di provocare danni. Ecco i più frequenti, ciascuno con il suo campanello d'allarme.
Migrare tutto lo storico è l'errore più diffuso. Dieci anni di preventivi scaduti e contatti inattivi allungano i tempi di pulizia e trasferimento senza apportare valore al nuovo sistema. Il segnale: la fase di preparazione dei dati supera le due settimane e nessuno sa dire quali record servano davvero. Il rimedio è tornare alla selezione fatta a mente fredda: si trasferisce ciò che serve a lavorare, il resto rimane nell'archivio in sola lettura.
Un doppio binario senza scadenza è il secondo errore per frequenza. Se la data unica di passaggio non viene fissata o viene rinviata “di un'altra settimana”, il team mantiene due sistemi per mesi e i dati divergono ogni giorno di più. Il segnale precoce: al giorno 45 qualcuno chiede ancora “questo dove lo inserisco?”. A quel punto non serve aspettare con pazienza, ma fissare una data scritta e comunicarla a tutti.
Seguono a poca distanza la migrazione senza referente, riconoscibile dai dati che invecchiano perché ognuno pensava che spettasse a un altro, e la formazione rimandata a dopo il trasloco, che lascia i colleghi capaci di aprire il nuovo programma, ma non di lavorarci. C'è poi chi decide di cambiare software gestionale senza dirlo ai clienti nemmeno quando servirebbe: se un cliente deve reinviare un documento o riceverà fatture con un layout nuovo, un preavviso di due righe evita le telefonate dei clienti irritati.
La timeline in tre fasi copre la maggior parte delle piccole e medie imprese, ma ha limiti precisi che conviene dichiarare subito. Chi ha il gestionale profondamente integrato con la produzione, il magazzino fisico o i macchinari di reparto deve aggiungere una fase di test tecnico che può raddoppiare i tempi. Chi lavora con dati sanitari, bancari o comunque sottoposti a vincoli normativi stretti deve inserire una verifica di conformità prima dello spegnimento, con tempi che dipendono dal consulente più che dal piano. E chi ha lo storico intrappolato in un formato proprietario chiuso, senza funzione di esportazione, deve mettere in conto un recupero dei dati assistito dal fornitore uscente, da negoziare prima della disdetta e non dopo. Nei periodi di picco stagionale conviene rinviare l'intera timeline: un doppio binario a dicembre, per chi fattura metà dell'anno in quel mese, è un rischio che nessun piano giustifica.
Chi arriva alla fase di scelta può valutare Bitrix24 come sistema di approdo, perché copre i tre fronti affrontati in questa guida: i dati, il piano stesso e i flussi con i clienti. L'importazione dei dati nel CRM parte dai file CSV preparati nella fase preliminare, anche salvando in questo formato i dati raccolti in Excel: i contatti e le aziende entrano con i loro campi, compresi quelli personalizzati creati per le condizioni commerciali o le note operative. Durante l'importazione è inoltre possibile definire come gestire i duplicati e verificare che ogni colonna del file corrisponda al campo corretto nel CRM. Il campione di 50 clienti della fase uno serve così da collaudo immediato.
L’area di gestione delle attività e dei progetti serve a pianificare la migrazione stessa: le tre fasi della timeline diventano un progetto con attività, responsabili e scadenze, il referente vede a colpo d'occhio quali attività sono in ritardo e la checklist di chiusura rimane accanto alle attività, invece che in un foglio separato. I moduli e le regole di automazione ricostruiscono poi i flussi con i clienti: un modulo web pubblicato sul sito inserisce la richiesta nel CRM e una regola di automazione può creare e assegnare l'attività di ricontatto alla persona giusta.
Crea un account Bitrix24, importa un campione dei dati e verifica subito se il nuovo flusso può sostituire quello che usi oggi.
Con Bitrix24 importi dati, assegni attività e ricostruisci i flussi CRM, mantenendo team e clienti allineati durante la migrazione.
Provalo gratisConviene cambiare software gestionale quando si manifesta uno dei tre guasti descritti in questa guida: il programma non è più supportato dal fornitore, le condizioni contrattuali sono diventate insostenibili oppure le funzioni non coprono più il lavoro reale del team. Se metà delle informazioni vive già fuori dal gestionale, è il momento di decidere.
Per cambiare software gestionale senza perdere i dati dei clienti, la sequenza sicura è: esportare anagrafiche e storico in formati aperti prima di ogni altra mossa, ripetere il backup ogni settimana, provare l'importazione su un campione di 50 clienti verificando i campi uno a uno, e solo dopo migrare il resto a ondate con controlli a campione dopo ogni ondata.
La migrazione a un nuovo gestionale dura circa 90 giorni con la timeline di questa guida: 30 giorni per scegliere il sostituto e preparare l'esportazione, 30 giorni di doppio binario con la migrazione dei dati e la formazione, 30 giorni di verifiche e spegnimento del vecchio sistema. Integrazioni profonde o vincoli normativi possono allungare il percorso.
Per mantenere il servizio ai clienti durante la transizione servono tre accorgimenti: una data unica a partire dalla quale ogni dato nuovo entra solo nel nuovo sistema, la mappa delle pratiche aperte con stato, responsabile e scadenza e un referente a cui il team segnala ogni dato mancante.
Lo storico che il nuovo gestionale non importa non va perso: resta nell'ultimo backup completo, conservato in due copie di cui una fuori sede, e in un archivio in sola lettura consultabile al bisogno. Nel nuovo sistema si trasferisce solo ciò che serve a lavorare: pratiche aperte, contratti attivi, anagrafiche attive.
Il cambio del gestionale in una piccola impresa richiede due figure: chi ha potere di firma decide nella fase di scelta e un referente interno unico è responsabile dei dati durante la migrazione e fino allo spegnimento del vecchio sistema. Il referente non deve essere per forza una persona tecnica: serve qualcuno che conosca i flussi con i clienti e che i colleghi ascoltino.
Oltre alla licenza del nuovo programma, il cambio comporta tre voci: le licenze sovrapposte dei due sistemi per il periodo di transizione, di solito un paio di mesi, le ore interne di pulizia ed esportazione dei dati e le ore di formazione del team. Metterle in fila prima della firma evita che il costo più elevato emerga solo in un secondo momento.