Perché la migrazione è una decisione architetturale, non un task tecnico

Come Solution Architect PL-600, la migrazione dati non è l’ultimo step del progetto: è un flusso di lavoro che progetti fin dalla fase di envisioning, perché determina rischi, tempistiche di go-live e la fiducia del business nel nuovo sistema. In Dataverse i dati non sono un semplice payload: attivano business rule, calculated/rollup column, plugin, flussi di Power Automate e vincoli di lookup/alternate key. Migrare significa quindi far passare i dati sorgente attraverso lo stesso modello di regole che governerà l’operatività — ed è qui che nasce il rischio principale.

Big-bang vs incrementale: il primo trade-off

Big-bang (cutover unico) è preferibile quando i volumi sono contenuti, la finestra di downtime è accettabile e non serve tenere sincronizzati sorgente e target. È più semplice da riconciliare perché esiste un solo momento di verità.

Incrementale / a fasi (per entità, per business unit o per delta successivi) è la scelta raccomandata quando i volumi sono elevati, il downtime deve essere minimo o la sorgente resta attiva durante la transizione. Richiede però una strategia di sincronizzazione delta e la gestione delle scritture concorrenti.

Guardando al pilastro Reliability dell’Azure Well-Architected Framework, l’incrementale riduce il blast radius: un errore colpisce un lotto, non l’intero dataset. Il costo è maggiore complessità di orchestrazione e riconciliazione. Regola di design: sotto qualche centinaio di migliaia di record con downtime tollerato, big-bang; oltre, o con sorgente viva, incrementale.

Scelta degli strumenti

Non esiste uno strumento unico. Mappa lo strumento al requisito:

  • Dataverse dataflows (Power Query): ideali per trasformazione self-service, cleansing dichiarativo, sorgenti eterogenee e carichi periodici. Ottimi per volumi medi e per team funzionali.
  • Azure Data Factory / Synapse pipelines: la scelta per volumi elevati, orchestrazione complessa, staging intermedio e trasformazioni pesanti. Usa il connettore Dataverse; per throughput massimo valuta lo staging su Azure Data Lake e l’uso delle API bulk.
  • Connettori e API (Web API, CreateMultiple/UpdateMultiple, ExecuteMultiple): per logiche custom, upsert su alternate key e controllo fine del throttling Dataverse service protection limits.
  • Import da Excel/CSV: solo per volumi piccoli, dati di configurazione o reference data.

Design tip: per abbattere i tempi, disabilita temporaneamente plugin, flussi sincroni e audit non necessari durante il bulk load, poi riattivali. Rispetta i service protection limit usando le operazioni multiple e il parallelismo controllato, non richieste one-by-one.

Mapping, cleansing e validazione (da fare per primi)

Il cuore del piano è la data quality anticipata. Sequenza raccomandata:

  1. Data profiling della sorgente: completezza, formati, duplicati, referential integrity, valori fuori dominio.
  2. Source-to-target mapping: ogni campo mappato a colonna Dataverse, con gestione di option set, lookup, owner e chiavi.
  3. Cleansing e deduplica prima del load, con alternate key per l’upsert idempotente.
  4. Validazione contro le business rule del target, non solo contro lo schema.

Riconciliazione e rollback nel go-live

Un piano di go-live credibile include sempre exit criteria misurabili:

  • Riconciliazione: conteggi record per entità, checksum/hash su campi chiave, controlli di totali finanziari e verifica delle relazioni (nessun lookup orfano).
  • Rollback: definisci il punto di ripristino. Nel big-bang, mantieni la sorgente in sola lettura come fallback fino al sign-off. Nell’incrementale, progetta lotti reversibili e la possibilità di ripetere un batch senza duplicare (grazie all’upsert su alternate key).
  • Cutover runbook: sequenza, responsabili, finestra, criteri go/no-go.

Trappole tipiche d’esame

  • Data quality rimandata a fine progetto → progetta profiling e cleansing come attività di envisioning/early design; scopri subito se i dati sorgente non reggono le regole del target, non a UAT.
  • Requisito: 5M di record + downtime minimo → NON big-bang con import Excel: usa Azure Data Factory con staging e migrazione incrementale a lotti con delta sync.
  • Requisito: caricare milioni di record senza incorrere in throttling → usa CreateMultiple/UpdateMultiple (API bulk) e disabilita temporaneamente plugin/flussi sincroni; evita ExecuteMultiple riga-per-riga.
  • Requisito: evitare duplicati su re-run del batch → definisci alternate key e usa upsert, non insert cieco; abilita il replay idempotente dei lotti.
  • Requisito: “come dimostriamo che la migrazione è corretta?” → includi riconciliazione (conteggi, checksum, integrità referenziale) e un piano di rollback con sorgente read-only come exit criteria del cutover, non un semplice “abbiamo caricato tutto”.