Cambiare fornitore IT: la migrazione che nessuno ti racconta

La decisione di cambiare fornitore IT arriva quasi sempre tardi rispetto a quando andava presa, e viene affrontata come un dettaglio operativo — “gli chiediamo di passare tutto al nuovo”. Non lo è. È un progetto con rischi propri, il più grande dei quali è che il fornitore che stai lasciando non ha nessun incentivo a farlo andare bene.

Perché il fornitore uscente non è il tuo alleato in questa fase

Anche il rapporto più corretto cambia natura nel momento in cui annunci l’uscita. Non è malafede: è che la priorità del fornitore uscente, da quel momento, sono i propri progetti in corso con clienti che restano. Il tempo che dedica al tuo handover è quasi sempre residuale, a meno che il contratto non lo preveda esplicitamente come attività dovuta e remunerata.

Cosa deve contenere un handover vero

• Codice sorgente completo, non solo l’ultima versione in produzione: storico, branch, configurazioni.
• Accessi e credenziali — dominio, hosting, servizi terzi, chiavi API — con verifica che siano tutte funzionanti, non solo elencate.
• Documentazione tecnica reale: architettura, dipendenze, procedure di deploy. Se non esiste, va ricostruita prima che il fornitore uscente sparisca dal radar.
• Dati storici, con la loro struttura originale — non un export “piatto” che perde relazioni, cronologia, responsabili.
• Un periodo di affiancamento in cui l’uscente resta disponibile per domande del nuovo fornitore. Va negoziato e messo per iscritto, non dato per scontato.

I rischi che si materializzano quasi sempre

La perdita di dati non è il rischio più frequente: lo è la loro degradazione silenziosa. I dati arrivano al nuovo sistema, ma senza lo storico che li accompagnava — pratiche senza cronologia, scadenze scollegate dai responsabili, documenti che perdono il collegamento con la pratica di origine. Il sistema sembra funzionare; scopri il problema mesi dopo, quando serve un dato che “dovrebbe esserci”.

Come si gestisce bene una migrazione

1. Validazione prima del passaggio. Ogni dato da migrare va controllato per anomalie ed errori, con una fase di bonifica se serve, prima — non dopo — di spostarlo.
2. Migrazione pilota su un sottoinsieme. Non tutto in un colpo: un batch limitato, verificato a fondo, prima del resto.
3. Periodo di parallel run. Vecchio e nuovo sistema attivi insieme per un tempo definito, con confronto dei risultati, prima di spegnere il primo.
4. Piano di rollback. Se qualcosa va storto in modo grave, deve esistere un modo di tornare indietro senza aver già smantellato il sistema precedente.

Cosa mettere in contratto fin dall’inizio

La finestra migliore per garantirsi un’uscita ordinata è prima di firmare con un nuovo fornitore, non quando decidi di lasciarlo. Una clausola di uscita che definisce tempi, formato dei dati, e obbligo di collaborazione dell’uscente ti evita di scoprire, nel momento peggiore, che il passaggio dipende dalla sua buona volontà.

In sintesi

Cambiare fornitore va trattato come un progetto a sé, con un piano, una validazione dei dati e un periodo di verifica in parallelo — non come un trasloco che finisce quando i file sono “passati”. Chi tratta la migrazione come un dettaglio la scopre come un problema serio esattamente quando è troppo tardi per correggerla senza danni.