Sostituire una parte alla volta
La migrazione graduale è spesso chiamata Strangler Fig: una facciata può indirizzare alcune richieste al sistema esistente e altre al nuovo componente. Il modello comporta anche limiti da gestire: dipendenze tra i sistemi, dati condivisi e possibili colli di bottiglia. Se non si può intervenire sul codice o su un punto di instradamento, questa strategia può non essere praticabile: prima si valuta un altro confine o un accesso web al prodotto esistente.
Prima di sostituire codice bisogna chiarire il risultato che si vuole ottenere e trovare confini abbastanza piccoli da poter essere consegnati e verificati. Portare il prodotto online e sostituire un modulo sono decisioni separate: un Web Bridge può precedere la migrazione oppure rimanere una soluzione stabile quando soddisfa le esigenze dei clienti.
Fonti: Microsoft Learn — Strangler Fig pattern · Martin Fowler — Strangler Fig
Scegliere un modulo non significa scegliere una schermata
Una schermata «Ordini» può usare listini, anagrafiche, magazzino, fatture e autorizzazioni. Se il nuovo modulo prende in carico solo l'interfaccia, mentre cinque programmi continuano a modificare le stesse tabelle, il confine è ancora da definire. La domanda è: quale operazione di business potrà essere di competenza del nuovo componente? Consultare lo stato di una pratica è un perimetro diverso da crearla, modificarla e chiuderla.
Un buon candidato offre un valore percepibile, ha dipendenze ricostruibili, può essere provato su dati rappresentativi e consente di misurare le differenze. Il modulo più vecchio o difficile da mantenere non è automaticamente il primo da spostare. A volte conviene iniziare da una funzione periferica per capire il sistema; altre volte una funzione centrale genera abbastanza valore da giustificare il lavoro sulle sue dipendenze.
Prima di decidere, tracciamo chi invoca il modulo, quali regole applica, quali dati legge o scrive e quali processi successivi dipendono dal risultato. Le personalizzazioni dei clienti meritano una verifica separata: una procedura raramente usata può essere essenziale per un solo cliente.
Tre fasi leggibili anche dal cliente
Nella prima fase il modulo attuale gestisce tutte le operazioni. Fissiamo un riferimento per i flussi importanti: input, output, tempi accettabili, autorizzazioni e casi particolari. Il QA Assessment aiuta a distinguere comportamenti da conservare, difetti già noti e regole da chiarire con chi usa il prodotto.
Nella fase di convivenza introduciamo un contratto tra chiamante e funzione: cosa significa «confermare un ordine», quali errori sono previsti e chi può eseguire l'operazione. Una facciata o un adattatore può indirizzare il caso al vecchio o al nuovo modulo. Non occorre che ogni prodotto adotti un proxy di rete: talvolta il punto di scelta è nel codice applicativo, in un servizio o in un processo batch.
La fase finale arriva quando la nuova responsabilità è isolata e verificata. Per rimuovere il vecchio codice non basta vedere traffico sul nuovo: vanno controllati job notturni, report, integrazioni, installazioni dei clienti e procedure di assistenza. Dopo la rimozione degli oggetti e della sincronizzazione dei dati, tornare alla versione precedente può richiedere molto più lavoro.
Fonti: Microsoft Learn — coesistenza e dismissione nel pattern Strangler Fig
Il punto delicato: chi è proprietario del dato?
Instradare una richiesta è relativamente semplice. Evitare due fonti di verità è più impegnativo. Durante la convivenza dobbiamo dichiarare quale componente può scrivere un dato, come il secondo lo legge e quando una modifica diventa visibile. La doppia scrittura non controllata può creare divergenze difficili da correggere. Se servono copie o sincronizzazioni, definiamo il verso del flusso, i ritardi tollerabili, i controlli di coerenza e una procedura per gestire gli errori.
Questa scelta influenza anche il piano di ritorno. Se un cliente torna temporaneamente al vecchio modulo, quest'ultimo deve poter leggere le operazioni già eseguite sul nuovo. In caso contrario il ritorno dell'interfaccia rischia di mostrare dati incompleti. Per questo il piano si prova prima del rilascio, con dati non produttivi ma realistici e scenari di errore, non soltanto con una copia del codice precedente.
Un esempio illustrativo
Immaginiamo una software house con un gestionale verticale installato presso molti clienti. Il team vuole sostituire la gestione delle richieste di assistenza, ma non il motore di fatturazione. Parte dalla consultazione delle richieste nel browser; dati e logica restano nel prodotto esistente. In seguito introduce la creazione delle nuove richieste per un gruppo ristretto di clienti, mantenendo per un periodo il vecchio percorso. Solo dopo aver confrontato stati, notifiche e integrazioni trasferisce la chiusura delle pratiche.
È uno scenario inventato per mostrare le decisioni, non un caso cliente MadeInCode. Il primo accesso web avrebbe anche potuto coprire gran parte del prodotto senza migrare la logica: portare online e sostituire un modulo sono decisioni separate. Architettura, licenze, prestazioni e sicurezza determinano quanto del software possa essere reso disponibile così com'è.
Checklist prima di spostare il primo cliente
Un rilascio controllato rende visibile cosa cambierà, per chi e con quale possibilità di intervento se i risultati non corrispondono alle attese. Non promette assenza di interruzioni. Quando il primo passaggio è stabile, si sceglie il successivo sulla base di ciò che si è imparato.
- Il confine funzionale e il proprietario di ogni dato sono scritti e condivisi?
- Abbiamo provato i flussi critici, inclusi permessi e personalizzazioni?
- Sappiamo quali clienti riceveranno per primi il nuovo percorso e come riconoscerli?
- Possiamo vedere errori, tempi di risposta e differenze di risultato per cliente?
- Abbiamo una procedura per fermare l'attivazione e tornare al percorso precedente?
- I dati creati nel nuovo percorso restano disponibili se dobbiamo tornare indietro?
- Supporto e clienti pilota sanno cosa osservare e come segnalarlo?