Migrazione dati e pianificazione cutover per software B2B
La settimana di lancio fallisce in silenzio quando i dati sono sbagliati: migliaia di record legacy importati con chiavi duplicate, timestamp spostati per timezone che rompono report SLA, o ERP ancora authoritative mentre gli operatori lavorano già nel nuovo tool. La migrazione dati per software B2B non è uno script ETL una tantum. È un programma con dry run, riconciliazione, rollback e comunicazione legata ai calendari business. Questa guida copre migrazione da fogli di calcolo, database legacy e sistemi paralleli verso SaaS custom, tool interni e portali. Completa modernizzazione legacy incrementale, design integrazione ERP e production readiness. Usala dopo la discovery tecnica quando sistemi sorgente e confini di ownership sono documentati.
Failure mode comuni nella migrazione B2B
Trattare migrazione come ultimo task pre go-live, senza dry run su volume produzione. Scoprire chiavi naturali duplicate venerdì sera. Assumere che ERP e legacy concordino sull'anagrafica clienti quando non si riconciliano da anni. Cutover nel picco stagionale perché il software era pronto, ignorando freeze business. Saltare formazione operatori su come la history migrata appare in ricerca e report. Nessun piano rollback quando il dual-write era promesso ma mai testato. Support sommerso da 'record mancanti' filtrati da regole migrazione mai comunicate.
- Collisioni chiave naturale tra sorgenti fuse
- Problemi encoding e locale su nomi e indirizzi
- Stati storici senza mapping alla nuova state machine
- Allegati su share di rete, non nel database
- Transazioni aperte durante finestra cutover
Inventario sorgenti e system of record
Elenca ogni sorgente: SQL legacy, export Access, liste SharePoint, estratti SAP, CSV da SaaS terzi. Per ogni entità (cliente, asset, ordine, contratto) nomina system of record durante transizione e dopo cutover. Nelle migrazioni strangler due sistemi possono possedere campi diversi temporaneamente. Documenta ownership a livello campo per evitare doppie modifiche e gap riconciliazione dual-write. Profila qualità dati presto: tassi null, foreign key orfane, lunghezze stringa massime, caratteri illegali. Condividi con business owner; alcuni dati 'sporchi' sono storia legalmente richiesta.
Regole mapping, transform e validazione
Mantieni mapping in spreadsheet o YAML in version control: campo sorgente, campo target, funzione transform, default se null, sign-off business owner. Code review su cambi mapping come migration schema. Valida con JSON Schema o vincoli DB più regole business (limite credito non negativo, data fine dopo inizio). Rigetta righe in tabelle quarantena con motivo errore, non drop silenziosi. Preserva history immutabile: ID legacy originale, batch import ID, imported_at. Gli operatori cercano per vecchio riferimento per anni. Per audit e compliance, logga chi ha approvato import massivi e parametri (cutoff data, siti inclusi).
- Tabella quarantena per righe fallite con export per fix business
- Checksum conteggi per tipo entità dopo ogni run
- Review manuale campionata per record finanziari ad alto rischio
- Unit test transform su date, valute e unità di misura
Dry run, performance e calendario prova
Esegui migrazione completa su copia staging dei dati produzione almeno due volte prima del go-live. Misura durata, crescita disco, rebuild indici e performance query applicative post-import. Prova il calendario cutover con ops cliente: chi è online, escalation, freeze modifiche legacy, comunicazione a utenti campo. Il dry run include drill rollback, non solo happy path. Automatizza report confronto: conteggi riga, somme importi, hash colonne chiave tra extract sorgente e tabelle target. Investiga ogni delta prima del via libera. Collega i gate prova alla strategia di test UAT su dati migrati, non solo seed sintetici.
Modelli cutover: big bang, a fasi e parallel run
Big bang: finestra unica, legacy read-only, import, verifica, switch DNS o formazione. Tempo calendario minimo, rischio massimo, prova impeccabile richiesta.A fasi: migra per sito, business unit o linea prodotto. Rischio minore, calendario più lungo, serve configurazione tenant o scope e confini dati chiari.Parallel run: operatori usano entrambi i sistemi con riconciliazione giornaliera. Costoso ma comune in contesti regolati o industriali. Definisci owner riconciliazione e soglie tolleranza. Abbina il modello alle milestone contrattuali: cutover a fasi mappano su gate accettazione e trigger fatturazione multipli.
ERP e anagrafiche durante la migrazione
Quando ERP resta system of record per clienti o articoli, la migrazione può caricare riferimenti non anagrafiche complete. Importa chiavi ERP, valida esistenza via API prima dell'insert, accoda create per master mancanti con workflow approvazione. Allinea ai pattern integrazione: upsert idempotenti, risoluzione conflitti se ERP cambia durante import lungo, freeze quando fine mese ERP blocca scritture. I job sync post-cutover devono gestire record creati nella nuova app prima che ERP li rifletta. Documenta lag tollerato nei runbook.
Rollback, comunicazione e hypercare
Criteri rollback definiti prima del cutover: soglia error rate, delta riconciliazione oltre tolleranza, journey critico rotto oltre N ore. Rollback significa ripristino DNS, riabilitazione modifiche legacy, comunicazione freeze inserimento dati nuova app. Se sono nati dati post-cutover, il rollback richiede strategia merge o accettazione esplicita perdita dati nel runbook (spesso inaccettabile; preferisci fix in avanti). Hypercare prime due settimane: report riconciliazione giornalieri, war room, SLA difetti prioritari. Includi playbook migrazione nella checklist go-live.
Uscire da fogli di calcolo e conoscenza tribale
Migrazione da spreadsheet è politica: il file non è solo dati, è workflow. Intervista owner su tab, macro, codici colore e colonne nascoste. Importa fogli raw in tabelle staging prima di normalizzare. Replica colonne calcolate critiche in logica applicativa con test. Gli utenti confronteranno totali report con Excel per mesi. Vedi build vs buy sui tool interni quando decidi quanto comportamento foglio codificare vs semplificare.
Budget e timeline per lavoro migrazione
La migrazione spesso consuma 20-40% sforzo totale su progetti sostitutivi, di più con sorgenti multiple o dati scarsi. Sottostimare migrazione si vede come slittamento go-live, non ritardo codice. Includi migrazione nelle stime costo sviluppo come workstream proprio con dry run, non weekend di un developer. Gli ingaggi contractor devono specificare numero cicli prova, formato report riconciliazione e obblighi cliente (extract puntuali, sign-off mapping).
Prossimi passi
Esporta un'entità da ogni sorgente questa settimana. Esegui query profiling. Nomina system of record per campo. Schedula prima data dry run prima di promettere go-live. Vedi altre risorse, case study, prenota una call o scrivi un messaggio con sistemi sorgente, volumi record, vincoli cutover e se ERP resta authoritative.
Domande frequenti
Quanti dry run migrazione sono sufficienti?
Almeno due prove complete su staging a scala produzione, più un drill rollback. Aggiungine se più siti fanno cutover indipendente o se il sync ERP è nel percorso.
Dobbiamo migrare tutta la history?
Migra ciò che operatori e compliance servono per lavoro quotidiano e audit. Archivio profondo può restare read-only su legacy o cold storage se ricerca e legal hold lo permettono. I business owner firmano lo scope retention.
La migrazione può girare con legacy ancora live?
Sì con sync incrementale o cutover a fasi, ma servono change data capture o delta schedulati e regole chiare per edit conflittuali. Big bang è più semplice tecnicamente, più rischioso operativamente.
Chi firma correttezza migrazione?
Il business owner confronta report riconciliazione con tolleranze concordate, non solo IT. Finance spesso firma totali importi; operations firma conteggi e test workflow campione su dati migrati.