Cosa si porta via davvero
| Elemento | Si esporta? | Note |
|---|---|---|
| I dati nelle tabelle | Quasi sempre | In formati standard, verificate prima |
| I file e gli allegati | Di solito, con più fatica | Spesso uno per uno, o via collegamenti |
| La struttura: quali campi, come collegati | Sì, riproducendola | È la parte che conta più del contenuto |
| Le automazioni | No | Vanno riscritte, ma sapete già cosa devono fare |
| I permessi e le viste | No | Si ridisegnano, di solito meglio |
| La cronologia delle modifiche | Raramente | Se vi serve, esportatela finché potete |
| Le integrazioni con altri servizi | No | Si rifanno, ed è l'occasione per farle bene |
La terza riga è quella che vale. La struttura dei dati — quali cose esistono, quali campi servono davvero, come si collegano — l'avete scoperta usando lo strumento per mesi. Nessun'analisi fatta a tavolino ci sarebbe arrivata con la stessa precisione.
Perché il lavoro fatto non è sprecato
Chi arriva a questo punto ha spesso la sensazione di aver buttato mesi. È il contrario: avete fatto la parte che di solito costa di più e riesce peggio, cioè capire davvero come funziona il processo. Un progetto che parte da uno strumento già usato per un anno parte con una specifica scritta dall'uso, non dalle riunioni.
Cosa consegnare a chi ricostruirà
- L'esportazione dei dati, così come sono.
- L'elenco dei campi con quelli che usate davvero segnati: quasi sempre sono meno di quelli che esistono.
- Le automazioni descritte a parole: «quando succede questo, deve succedere quello».
- Chi usa lo strumento e cosa deve poter vedere ciascuno.
- Le tre cose che non funzionano e vi danno più fastidio.
- Le due cose che funzionano bene e non vanno toccate.
Come si fa il passaggio senza fermarsi
- 01
Esportate tutto adesso, prima di decidere qualsiasi cosa
Serve a sapere in che formato escono i dati e cosa manca. Scoprirlo il giorno del passaggio è il modo di trasformare una migrazione in un'emergenza.
- 02
Costruite il nuovo mentre il vecchio è in uso
Nessuno spegne uno strumento su cui si lavora. Il nuovo si popola con i dati esportati e si prova in parallelo.
- 03
Fate lavorare una persona sola sul nuovo, per due settimane
Sui dati veri, in parallelo. È l'unico modo di scoprire le differenze che contano, e sono sempre poche e specifiche.
- 04
Spostate tutti in un giorno concordato
Con l'esportazione finale fatta la sera prima, e il vecchio strumento in sola lettura per un mese.
- 05
Tenete il vecchio accessibile per un periodo
In sola lettura, senza pagare più del necessario se possibile. Serve per le verifiche che vengono in mente dopo.
Quando conviene non uscire affatto
Vale la pena dirlo, perché è il caso più frequente e il meno raccontato: moltissimi strumenti no-code restano dove sono per anni e vanno benissimo così. Se il vostro fa quello che deve, lo usano poche persone e i dati non sono delicati, uscire è un progetto che costa e non risolve niente.
| Situazione | Uscire? |
|---|---|
| Funziona, poche persone, nessun limite raggiunto | No: non c'è ragione |
| Lento con i vostri volumi | Sì, ed è il segnale più oggettivo |
| Servono permessi che non riuscite a fare | Sì |
| Deve scrivere nel gestionale | Sì, o serve un pezzo su misura accanto |
| Il canone è cresciuto con gli utenti | Fate il conto su tre anni prima di decidere |
| Vi hanno detto che «non è professionale» | No: non è una ragione |
L'ultima riga capita più spesso di quanto si creda, e va detto chiaramente: uno strumento che risolve un problema è professionale, indipendentemente da come è stato costruito.
Se siete in una delle righe con «sì», la ricostruzione è più rapida di quanto temete proprio grazie a quello che avete già fatto: portateci l'esportazione e le sei cose della lista, e si parte da lì invece che da zero.