Come cambiare fornitore software senza fermare il progetto

Per cambiare fornitore software senza fermare il progetto si procede in quattro tempi: prima metti al sicuro accessi, codice, dati e account intestandoli all'azienda; poi fai l'inventario di cosa esiste e dove gira; quindi fai leggere il codice al nuovo partner con una code review; infine passi le attività un pezzo alla volta, con un periodo di affiancamento. L'annuncio del cambio viene dopo il primo passo, non prima.

Se hai un gestionale, un'app o una piattaforma su misura che non viene più seguita come serve, con tempi di risposta lunghi, uno sviluppatore che non si trova o nessuna documentazione, alla fine di questa guida avrai l'elenco di cosa recuperare, l'ordine in cui farlo e i punti in cui questi passaggi si inceppano più spesso.

Cosa serve prima di iniziare

• Il contratto con il fornitore attuale, con le clausole su proprietà del codice, licenze, assistenza e preavviso. Ti dice cosa puoi chiedere e con quali tempi.
• Una persona interna di riferimento, anche non tecnica, che tenga l'elenco degli accessi e firmi le richieste. Senza un responsabile, le credenziali restano sparse nelle caselle di chi le ha ricevute.
• Un gestore di password aziendale o almeno un archivio protetto dove salvare ogni credenziale recuperata, intestato all'azienda e non a una persona.
• L'elenco di chi usa il software ogni giorno e per cosa: servirà per capire quali funzioni non possono fermarsi nemmeno un giorno.
• Le ultime fatture del fornitore, che spesso sono l'unico elenco completo dei servizi pagati: hosting, domini, licenze, servizi esterni.

Cosa mettere al sicuro prima di annunciare il cambio

Questa è la parte che decide se il passaggio sarà tranquillo o complicato. L'obiettivo è che ogni risorsa del software sia intestata all'azienda, con te o la persona di riferimento come amministratore, e il fornitore come utente con accesso, non come proprietario.

1. Chiedi per iscritto l'accesso amministratore al repository del codice. Indica che ti serve per un controllo interno sugli asset aziendali, che è vero. A questo punto vedrai la cronologia delle modifiche: se l'ultima risale a mesi fa ma il software è stato aggiornato di recente, la versione in produzione non coincide con quella salvata, e va recuperata.
2. Verifica l'intestazione di hosting, dominio e app store. Entra in ciascun pannello con credenziali tue, non con quelle che il fornitore usa. Se un account è intestato a lui, chiedi il trasferimento o l'aggiunta della tua utenza come amministratore: il risultato atteso è che tu possa vedere fatture, utenti e impostazioni.
3. Fatti consegnare una copia completa e recente del database e delle cartelle dei file caricati, come allegati, foto e documenti. Salvala fuori dal server di produzione. Ora hai i dati anche se domani qualcosa si interrompe.
4. Raccogli l'elenco dei servizi esterni a cui il software si appoggia: invio email, pagamenti, SMS, notifiche push, mappe, fatturazione elettronica. Per ognuno annota chi è il titolare dell'account e dove sono salvate le chiavi. Le chiavi si leggono di solito nei file di configurazione o nel pannello dell'hosting.
5. Chiedi la documentazione che esiste, anche parziale: come si installa, come si pubblica una nuova versione, quali operazioni pianificate girano di notte. Se non c'è, chiedi almeno un elenco a voce, da trascrivere.

Solo quando questi cinque punti sono coperti conviene comunicare il cambio. Un fornitore che riceve la notizia con gli accessi già in ordine ha meno lavoro da fare per uscire, e il rapporto si chiude in modo più semplice per entrambi.

Come fare l'inventario del software

L'inventario risponde a una domanda: che cosa fa davvero il software, e da cosa dipende. Non serve un documento tecnico lungo, serve un elenco che il nuovo partner possa verificare.

1. Elenca le funzioni usate ogni giorno, partendo dalle persone e non dai menu: chi entra, cosa fa, quale risultato si aspetta. A questo punto avrai la lista delle funzioni critiche, quelle che non possono fermarsi.
2. Annota le operazioni automatiche: esportazioni notturne, invii programmati, sincronizzazioni con altri programmi. Sono le più facili da dimenticare perché nessuno le vede.
3. Segna i collegamenti con altri sistemi: gestionale contabile, e-commerce, CRM, fornitori di dati. Per ciascuno indica in che direzione passano i dati e con quale frequenza.
4. Raccogli i problemi noti: errori ricorrenti, lentezze, funzioni che si usano con un trucco. Sono informazioni preziose per la code review.

Lo stesso metodo, applicato a un gestionale da sostituire, è descritto nella guida su come sostituire un gestionale aziendale obsoleto.

La code review iniziale del nuovo partner

Con accessi e inventario in mano, il nuovo partner legge il codice prima di toccarlo. Lo scopo non è giudicare chi ha scritto il software, ma capire su cosa si può costruire.

Una code review utile ti restituisce una fotografia in linguaggio comprensibile: quali parti sono solide e si possono tenere, quali frenano lo sviluppo o creano rischi, cosa manca per poter lavorare in sicurezza (ambiente di prova, backup verificati, procedure di rilascio). Chiedi che ogni punto abbia una priorità e una conseguenza pratica, non solo un giudizio tecnico.

È il punto da cui partiamo quando entriamo su un progetto avviato da altri: nel nostro servizio di partner di sviluppo software leggiamo il codice esistente, ti diciamo con franchezza cosa è solido e cosa frena, e da lì costruiamo una presa in carico graduale, con NDA incluso e accesso al codice nel modo che preferisci tu.

Passaggio di consegne e presa in carico graduale

1. Prepara un ambiente di prova separato dalla produzione, con una copia dei dati. Ogni modifica passa da lì prima di arrivare agli utenti. Se non esiste, è la prima cosa da costruire.
2. Pianifica un periodo di affiancamento, se il fornitore uscente è disponibile: qualche sessione in cui mostra come si pubblica una versione, dove guardare quando qualcosa si blocca, quali operazioni fa a mano. Alla fine il nuovo partner deve saper pubblicare una versione da solo.
3. Fai fare al nuovo partner un primo intervento piccolo: una correzione o una modifica circoscritta, portata fino in produzione. Serve a provare l'intera catena, dal codice al rilascio, con un rischio basso.
4. Passa le attività per aree, partendo da quelle meno critiche: prima la manutenzione ordinaria, poi le nuove funzioni, infine le parti che toccano dati delicati o altri sistemi.
5. Revoca gli accessi del fornitore uscente solo quando il nuovo partner ha dimostrato di gestire rilasci e problemi da solo. Il risultato atteso è un elenco di accessi aggiornato, in cui ogni utenza ha un nome e un motivo.

Dopo il passaggio, il software va tenuto in salute con un piano di manutenzione del software aziendale concordato fin dall'inizio.

Variante: il fornitore collabora

È il caso più semplice. Proponi una data di fine rapporto e, prima, un periodo di affiancamento con incontri brevi tra il fornitore uscente e il nuovo partner. Concorda per iscritto cosa viene consegnato: codice, documentazione, accessi, elenco dei servizi esterni. Chi esce di solito apprezza un passaggio ordinato, perché chiude le responsabilità con chiarezza.

Variante: il fornitore è irraggiungibile

Se lo sviluppatore non risponde più, parti da quello che controlli già: il pannello dell'hosting, se è intestato all'azienda, il dominio, l'account dello store. Dal server il nuovo partner può spesso recuperare il codice in produzione e la struttura del database. Quando un account è intestato al fornitore e non riesci a contattarlo, registrar e store prevedono in genere procedure di recupero per il titolare dell'attività, con documenti che provano l'uso del servizio. In questo caso l'inventario si ricostruisce leggendo il software in funzione, e la code review pesa di più.

Variante: l'app è pubblicata sugli store

Per un'app il punto critico è l'account sviluppatore. Se è intestato all'azienda, il nuovo partner viene aggiunto come utente e può pubblicare gli aggiornamenti. Se è del fornitore, l'app va trasferita al tuo account con la procedura prevista dallo store, che conserva recensioni e utenti; ripubblicarla da zero come app nuova significa perdere entrambi. Recupera anche i certificati di firma e le chiavi delle notifiche push: senza, gli aggiornamenti non partono.

Variante: il gestionale è collegato ad altri sistemi

Qui il rischio non sta nel gestionale ma nei collegamenti. Per ogni scambio di dati con contabilità, e-commerce o magazzino serve sapere dove gira, con quali credenziali e cosa succede se si interrompe. Il nuovo partner prende in carico prima il monitoraggio di questi flussi, poi il codice: un'interruzione notturna non rilevata costa più di qualunque modifica.

Metodo alternativo: affiancare prima di sostituire

Se non sei pronto a chiudere il rapporto, puoi affiancare al fornitore attuale un secondo partner, con un perimetro limitato: la code review, oppure una singola area del software. È utile quando il fornitore attuale segue bene una parte ma non ha tempo per il resto. Funziona a una condizione: un repository unico, regole chiare su chi pubblica in produzione e un ambiente di prova condiviso. Se lavori con un'agenzia senza reparto tecnico interno, lo stesso schema è descritto nella guida sullo sviluppo software white label.

Cosa sapere su proprietà del codice e licenze

Chi possiede il codice, e cosa puoi farne, lo stabilisce il contratto: proprietà piena al committente, licenza d'uso, oppure un modello misto in cui la parte specifica è tua e una base tecnica resta del fornitore. Vale anche per librerie e componenti di terzi inclusi nel software, che hanno licenze proprie. Prima di annunciare il cambio rileggi queste clausole: dicono cosa puoi consegnare a un nuovo partner. Un quadro più ampio è nella guida sulla tutela del software aziendale. Queste sono indicazioni generali: per il tuo caso specifico confrontati con il tuo consulente legale.

Errori comuni

Riscrivere tutto da zero d'impulso. Dopo un rapporto difficile la tentazione è ripartire da capo. Ma il software in uso contiene regole che nessuno ricorda, e riscriverlo significa ritrovarle in produzione. Rimedio: decidi dopo la code review, area per area.

Annunciare il cambio senza aver recuperato le credenziali. Da quel momento ogni accesso diventa una trattativa. Rimedio: completa la sezione sugli accessi prima di qualunque comunicazione.

Lavorare senza ambiente di prova. Il nuovo partner non conosce ancora il software, e ogni modifica fatta direttamente in produzione è un rischio per chi lo usa ogni giorno. Rimedio: l'ambiente di prova è il primo lavoro, non un extra.

Chi siamo

Obly è un'agenzia di sviluppo software su misura con sede a Casale Monferrato (AL) che progetta gestionali, app e integrazioni fra i sistemi aziendali. Seguiamo anche progetti avviati da altri: entriamo su codice esistente con una code review iniziale e una presa in carico graduale.

Quanto tempo serve e qual è il passo successivo

Mettere al sicuro accessi e dati richiede da qualche giorno a qualche settimana, a seconda di quanti account sono intestati al fornitore. Inventario e code review si sovrappongono e dipendono dalle dimensioni del software; il passaggio vero e proprio procede per aree, con il software sempre in funzione.

Ora che hai l'elenco di cosa recuperare, il passo successivo naturale è scegliere chi prenderà in carico il progetto: i criteri sono nella guida su come scegliere un'agenzia di sviluppo software. Se vuoi parlarne per un preventivo sul passaggio del tuo progetto, trovi come lavoriamo nella pagina partner di sviluppo software, con una prima call gratuita e un pacchetto di ore senza vincolo di durata.