Go-live e adozione
Migrazione dati e cleanup
Quale storia si sposta in Gfacility, cosa scarta, cosa archivia, e come valida che tutto atterri correttamente? Salti il cleanup e porta il vecchio disordine nella nuova casa.
Aggiornato il 18 mag 2026
Go-live · 5.1
Perché prima questo
Migrazione e cleanup sono inseparabili. “Migrare tutto” sembra sicuro, finché non avvia Gfacility con 14.000 ticket del 2017 di cui nessuno capisce più lo stato. Importare dati cattivi rende inattendibile ogni report e inutile ogni suggerimento AI. Prima si ripulisce, poi si migra.
Cosa consegna?
Matrice di migrazione
Per entità sorgente: entità target, regole di trasformazione, data di riferimento, ambito.
Elenco azioni di cleanup
Duplicati, record obsoleti, riferimenti rotti, chi ripulisce cosa prima della migrazione?
Strategia di archivio
Ciò che non migra e come resta consultabile in base agli obblighi di conservazione.
Report di dry-run
Risultato di almeno due esecuzioni di dry-run: conteggi, discrepanze, tempi di esecuzione.
Le cinque famiglie di entità
La migrazione segue sempre gli stessi passi, indipendentemente dal sistema sorgente:
Dati anagrafici
Utenti, organizzazioni, sedi, centri di costo. Prima, perché tutte le altre entità vi fanno riferimento.
Configurazione
Classificazioni, campi personalizzati, gruppi di lavoro, workflow. Manuale o via export, di solito poco voluminosa.
Dati transazionali
Ticket aperti, prenotazioni in corso, attività pianificate. Volume basso, valore alto, li porti tutti.
Storia
Ticket chiusi, vecchie prenotazioni. Decida quale periodo (12 o 24 mesi) e come preserva la linea di reporting.
Knowledge base
Articoli, FAQ, template. Spesso l'occasione per ripulire e ristrutturare subito.
Allegati
Foto, PDF, documenti legati a ticket e asset. Di solito i più pesanti.
Domande chiave
- 1Quali sistemi sorgente contengono dati che devono andare in Gfacility, TOPdesk, ServiceNow, elenchi Excel, tool interni, risorse Outlook?
- 2Limiti di scope per entità, solo record attivi, solo ultimi 24 mesi, solo reparti specifici?
- 3Cleanup prima della migrazione, chi rimuove i duplicati, disattiva gli utenti dormienti, chiude i ticket "orfani" senza owner?
- 4Regole di trasformazione, come mappa le vecchie categorie alle nuove classificazioni? Cosa fa con "sconosciuto"?
- 5Strategia allegati, migrarli, storage separato o recupero on-demand dall'archivio?
- 6Data di riferimento e freeze, quando la sorgente viene "congelata" (nessuna modifica) e cosa fa con i nuovi record che arrivano nel frattempo?
- 7Validazione, quali controlli esegue dopo la migrazione (totali, campioni, record firma rivisti a mano)?
- 8Soluzione di archivio, per i dati che non migrano, il vecchio strumento resta in read-only? Con quale periodo di retention, owner e modello di accesso?
- 9Ripetibilità, può fare dry-run almeno due volte prima del cutover reale? Idempotente (rilanciare non cambia nulla)?
- 10Impatto GDPR, sta portando dati personali la cui retention è già scaduta? Controllo del DPO prima della migrazione.
Template — Matrice di migrazione per entità
| Entità | Sorgente | Volume | Ambito | Azione di cleanup | Owner | Validazione |
|---|---|---|---|---|---|---|
| Utenti | Entra ID | ~2.400 | Attivi (login 90g) | Disattivare i dormienti | IT-Identity | Totale +/- 1% |
| Sedi | Excel + M365 Rooms | ~180 | Tutte le prenotabili | Ri-validazione capienza | FM | Controllo manuale 100% |
| Ticket aperti | TOPdesk | ~340 | Tutti aperti | Chiudere > 6m | Service Manager | Campione di 50 |
| Ticket chiusi | TOPdesk | ~14.200 | Ultimi 24m | Redazione PII > 12m | Service Manager + DPO | Totali mensili |
| Storico prenotazioni | M365 | ~85.000 | Ultimi 12m | Nessuna, read-only | Workplace lead | Aggregati |
| Articoli KB | Wiki SharePoint | ~220 | Top-150 più letti | Riscrittura + tag | Service Manager | Revisione contenuti |
| … | … | … | … | … | … | … |
Passi
- 1Inventari i sistemi sorgente e assegni un responsabile per ciascuna entità.
- 2Esegua sprint di cleanup, duplicati, account dormienti, più vecchi della retention. Meglio nella sorgente che durante la migrazione.
- 3Scriva il mapping di trasformazione: campo sorgente → campo Gfacility, con regole esplicite per "sconosciuto" e "vuoto".
- 4Primo dry-run sull'ambiente di accettazione, con volume atteso, solo per misurare conteggi, runtime ed errori.
- 5Corregga gli errori, affini il mapping e rimandi le azioni di cleanup alla sorgente.
- 6Secondo dry-run con uno stato di cleanup rappresentativo, gli end user verificano un campione.
- 7Definisca la strategia di archivio, la sorgente resta read-only per 12 mesi, poi export verso cold storage.
- 8Consegni il report go/no-go al comitato direttivo: conteggi corretti, errori < X, sign-off degli owner di entità.