Migrazione di sistemi legacy in Svizzera: un pilota di 90-180 giorni riduce il rischio

Per la maggior parte delle organizzazioni, una migrazione legacy incrementale, condotta con un pilota e una messa in produzione a fasi sotto controllo, offre un equilibrio migliore tra rischio, costi e valore per il business rispetto a un unico passaggio. Le decisioni su governance e protezione dei dati pesano sul risultato più della scelta del fornitore o della piattaforma. Fatta bene, porta un rischio operativo più basso durante la transizione e un quadro chiaro del costo totale di proprietà prima di impegnare altro budget.

---

TL;DR:

• Quasi tutte le organizzazioni traggono vantaggio da approcci di migrazione incrementali, con messe in produzione a fasi e MVP, invece di un unico passaggio big bang, perché il rischio operativo si riduce.

• La mappatura delle dipendenze deve concentrarsi sulle applicazioni dipartimentali non documentate e sui piccoli sistemi, che spesso tengono insieme flussi di lavoro critici invisibili negli schemi ufficiali.

• La classificazione dei dati e gli aspetti di conformità, in particolare per i dati personali secondo il diritto svizzero, richiedono una pianificazione anticipata e tutele contrattuali prima che la migrazione cominci.

• La scelta dell'approccio dipende dal debito tecnico del sistema attuale, dal grado di accoppiamento e da quanti tempi di fermo l'organizzazione può tollerare durante la transizione.

• Un piano strutturato con fasi di valutazione, pilota e messa in produzione progressiva, con una strategia di rollback chiara, funziona meglio di un piano guidato soltanto dalle date obiettivo.

---

Che cosa significa davvero migrare un sistema legacy (e quando iniziare)

La migrazione di un sistema legacy è il processo con cui dati, funzionalità e flussi di lavoro vengono spostati da una piattaforma invecchiata verso una nuova infrastruttura: un ambiente cloud moderno, una nuova applicazione o una versione ricostruita dello stesso sistema. È un termine più circoscritto di "modernizzazione", che comprende anche interventi senza spostamenti, per esempio l'aggiunta di uno strato API a un sistema che resta esattamente dov'è. Una migrazione implica sempre che dati e funzionalità cambino luogo o piattaforma. La modernizzazione è l'obiettivo più ampio; la migrazione ne è spesso lo strumento.

Non serve una crisi per giustificarne l'avvio, ma quasi tutte le organizzazioni aspettano comunque di trovarsi in una. I segnali più chiari arrivano dall'esterno: il fornitore annuncia la fine del supporto per la piattaforma, un audit di conformità segnala software non supportato, oppure una nuova integrazione è semplicemente impossibile perché il sistema legacy non ha un'API utilizzabile.

Alcuni campanelli d'allarme tendono a comparire prima dell'evento che fa scattare tutto:

• I tempi di rilascio delle modifiche continuano ad allungarsi. Una funzionalità che cinque anni fa richiedeva due settimane oggi ne richiede due mesi, perché nessuno conosce più fino in fondo le dipendenze.

• Il fornitore ha lasciato il mercato, ha smesso di rilasciare patch oppure è stato acquisito e ha declassato il prodotto.

• Gli incidenti di sicurezza, o i quasi incidenti, aumentano, spesso legati a componenti non aggiornabili senza rompere qualcos'altro.

• I costi di manutenzione crescono più rapidamente del valore che il sistema genera per il business.

• Le nuove persone non riescono a lavorare sul sistema senza mesi di passaggio di conoscenze informali da una o due persone che l'hanno costruito.

Se due o più di questi punti ti riguardano, vale la pena avviare una valutazione ancora prima di aprire la discussione sul budget. Aspettare che il fornitore ti costringa a muoverti significa quasi sempre migrare con una pressione temporale peggiore e con meno margine di negoziazione.

Confronto tra approcci: lift-and-shift, replatform, refactoring e strangler pattern

Non esiste un approccio "giusto" valido per tutti. Quello adatto dipende da quanto debito tecnico porta con sé il sistema attuale, da quanto è accoppiato ad altri sistemi e da quanto rischio il business può sostenere durante la transizione.

Il lift-and-shift sposta l'applicazione così com'è su una nuova infrastruttura, in genere server cloud, con modifiche minime al codice. È l'opzione più rapida ed economica all'inizio ed è una scelta ragionevole quando la logica applicativa funziona ancora bene ma il vero problema è l'hardware o l'hosting sottostante. Il rovescio della medaglia: erediti ogni difetto architetturale del vecchio sistema, semplicemente su infrastruttura più recente. Compra tempo, non miglioramenti.

Il replatforming introduce modifiche moderate, spesso la sostituzione del motore di database o l'adattamento dell'applicazione a servizi cloud-native, senza una riscrittura completa. Sta a metà strada su costi e rischio ed è spesso la scelta corretta quando la logica di business dell'applicazione è solida ma il collo di bottiglia è lo strato dati o il modello di distribuzione.

Refactoring o riscrittura completa significa ricostruire l'applicazione su un'architettura moderna, a volte ripensando del tutto modello dei dati e flussi di lavoro. È il percorso più costoso e lungo, ma è l'unico che elimina davvero il debito tecnico invece di spostarlo. Ha senso quando è la logica di business stessa a dover cambiare, non solo l'infrastruttura sotto.

Lo strangler pattern sostituisce il sistema legacy pezzo per pezzo: le nuove funzionalità vengono indirizzate a servizi moderni mentre il vecchio sistema continua a gestire le parti non ancora migrate. Col tempo l'impronta del legacy si riduce fino a poterlo dismettere. Questo approccio evita il rischio tutto-o-niente di un passaggio big bang e permette di generare valore in modo incrementale, invece di attendere anni per un'unica messa in produzione. Le Modernization guidance from Swisscom raccomandano esattamente questo: partire con MVP nel cloud pubblico, reintegrarli nell'ambiente legacy e costruire uno stato ibrido invece di tentare un unico grande salto.

La decisione dipende di solito da quanto sono accoppiati i tuoi sistemi e da quanti tempi di fermo il business può assorbire. Un monolite fortemente accoppiato con decine di punti di integrazione fa quasi sempre preferire lo strangler pattern o un replatforming a fasi rispetto a una riscrittura, semplicemente perché una riscrittura completa rinvia ogni integrazione dipendente fino alla fine.

Un piano di migrazione che regge l'impatto con la realtà

Un piano costruito interamente attorno a una data obiettivo, senza punti di controllo intermedi, tende a sfaldarsi nel momento in cui emerge la prima dipendenza inattesa. Una struttura migliore prevede tre fasi, ciascuna con un risultato concreto che apre la successiva.

1. Valutazione. Prima di scrivere una riga di codice per la migrazione ti servono un inventario completo delle applicazioni, una mappa delle dipendenze che mostri quali sistemi comunicano con quali, un lavoro di classificazione dei dati che separi i dati personali da quelli operativi e un profilo di costi e rischi dello stato attuale. Questa fase richiede regolarmente più tempo di quanto i team prevedano, soprattutto perché la mappatura delle dipendenze fa emergere integrazioni di cui nessuno ricordava l'esistenza.

2. Pilota o MVP. Scegli un carico di lavoro, idealmente a basso rischio ma rappresentativo della complessità complessiva del sistema, e migralo del tutto. L'obiettivo non è la velocità, è la convalida. Un pilota riuscito dimostra che l'approccio scelto regge i tuoi volumi di dati reali, i tuoi schemi di integrazione reali e i tuoi requisiti prestazionali reali, non un caso di test semplificato. Definisci i criteri di successo prima di iniziare: controlli di fedeltà dei dati superati, prestazioni entro una soglia concordata, rollback testato e funzionante.

3. Messa in produzione a fasi. Ordina i carichi di lavoro rimanenti in base al rischio, spostando per primi i sistemi a rischio e visibilità più bassi. Ogni fase ha bisogno del proprio runbook, del proprio pannello di monitoraggio e di un percorso di rollback testato prima dell'attivazione, non dopo. Il Migration Acceleration Program di AWS descrive questo percorso come una progressione in tre stadi, dalla valutazione alla mobilitazione fino a migrazione e modernizzazione, e indica esplicitamente l'impegno della direzione come fattore predittivo di successo più rilevante della piattaforma tecnologica scelta.

Consiglio pratico: tratta il piano di rollback come un risultato di prima categoria, non come un ripensamento. Se prima dell'attivazione non sai rispondere alla domanda "come annulliamo questa fase in meno di quattro ore?", non sei pronto ad attivare.

Nel piano va messa esplicitamente anche una riserva di budget. Le analisi collegate a Gartner sui progetti tecnologici falliti indicano come causa principale di abbandono lo scarso allineamento tra traguardi tecnici e obiettivi di business, insieme a un costo totale di proprietà che sfugge al controllo e supera quanto approvato dalla direzione. Legare ogni fase a un risultato di business misurabile, non solo a un punto di controllo tecnico, mantiene il progetto difendibile quando le discussioni sul budget si fanno tese.

Migrazione dei dati, privacy e ciò che il diritto svizzero richiede davvero

Catalogare e classificare i dati viene prima di qualsiasi lavoro tecnico di migrazione, non in parallelo. Separa presto i dati personali da quelli puramente operativi o aziendali, perché i due tipi comportano obblighi di conformità molto diversi nel momento in cui lasciano la tua infrastruttura attuale.

Secondo la Legge federale svizzera sulla protezione dei dati (LPD), l'organizzazione resta giuridicamente responsabile dei dati personali anche dopo aver affidato il trattamento a un fornitore cloud o a un partner esterno. L'esternalizzazione non trasferisce la responsabilità. Se la migrazione sposta dati personali su un servizio cloud, in particolare fuori dalla Svizzera, ti servono tutele tecniche o contrattuali documentate, e l'IFPDT (Incaricato federale della protezione dei dati e della trasparenza) si aspetta che siano in vigore prima del trasferimento, non aggiunte dopo. Tra i casi trattati dall'IFPDT figura un esame formale dell'esternalizzazione di dati personali da parte della SUVA verso un servizio cloud di Microsoft, che ha messo in evidenza come anche organizzazioni grandi e ben dotate di risorse abbiano bisogno di una valutazione indipendente dei rischi per la privacy prima di finalizzare una decisione di esternalizzazione nel cloud.

Tra i controlli pratici che reggono a un esame delle autorità ci sono:

• Pseudonimizzare o anonimizzare i dati personali ovunque il caso d'uso lo consenta, riducendo l'esposizione in caso di violazione.

• Cifrare i dati sia a riposo sia in transito, soprattutto per qualsiasi trasferimento transfrontaliero.

• Mantenere registri di controllo che mostrino chi ha avuto accesso a quali dati durante e dopo la migrazione.

• Compilare questionari di verifica sui fornitori prima di firmare qualsiasi contratto di esternalizzazione, non dopo.

• Prevedere clausole contrattuali su luogo di conservazione dei dati, tempi di notifica delle violazioni e ricorso a subappaltatori.

L'IFPDT esamina di norma le clausole standard di protezione dei dati entro qualche mese, secondo le sue stesse indicazioni sull'esternalizzazione, un dettaglio da considerare nella pianificazione se la migrazione dipende da un nuovo accordo di trattamento dei dati transfrontaliero. Inserisci quella finestra di esame nel piano, invece di scoprirla durante la fase pilota.

Sfide tecniche: dipendenze, database e modelli di integrazione

È nella mappatura delle dipendenze che la maggior parte delle tempistiche di migrazione va fuori strada, e i ritardi non arrivano quasi mai dai sistemi che tutti conoscono. Arrivano dalle piccole applicazioni dipartimentali, spesso chiamate Fachanwendungen negli ambienti di lingua tedesca, costruite anni fa da un'unità aziendale e mai documentate formalmente, che silenziosamente tengono insieme flussi di lavoro critici. Per trovarle bisogna parlare con le persone che usano il sistema ogni giorno, non solo leggere lo schema dell'architettura che qualcuno ha disegnato cinque anni fa.

La migrazione dei database porta con sé realtà che i team sottovalutano. Le modifiche allo schema richiedono controlli di fedeltà dei dati a ogni passo, confrontando conteggi dei record, checksum e record campione tra vecchio e nuovo sistema prima di fidarsi della migrazione. L'ottimizzazione delle prestazioni sulla nuova piattaforma richiede quasi sempre un approccio diverso da quello che funzionava sul database legacy, in particolare se passi da un database relazionale on-premise a un'alternativa cloud-native o in memoria. Anche la strategia sui dati di test conta: provare su una copia di produzione depurata fa emergere problemi che i dati sintetici non mostreranno mai.

Per l'integrazione, tre modelli coprono la maggior parte delle situazioni:

• Le facciate API avvolgono il sistema legacy in un'interfaccia moderna, permettendo alle nuove applicazioni di dialogarvi senza toccare il vecchio codice.

• Adattatori e bus di messaggi disaccoppiano sistemi che prima comunicavano direttamente, riducendo il raggio d'impatto quando una delle due parti cambia.

• I passaggi incrementali indirizzano una percentuale di traffico al nuovo sistema mentre il resto resta sul vecchio, così individui i problemi su piccola scala prima di impegnarti del tutto.

Consiglio pratico: automatizza il rollback come automatizzi il rilascio. Un rollback manuale sotto pressione, durante un incidente, alle due di notte: è lì che le migrazioni finiscono sui giornali. Infrastruttura come codice, catene di integrazione e distribuzione continua e suite di test automatizzate riducono tutte la probabilità che un passaggio a fasi si trasformi in un'emergenza. La migrazione a SAP S/4HANA di Bühler mostra bene il valore di un lavoro disciplinato sui dati: la transizione selettiva dei dati ha ridotto in misura significativa il volume dei dati operativi, partito da diversi terabyte, e questo ha determinato direttamente quanta infrastruttura di database in memoria l'azienda ha dovuto acquistare.

Governance, gestione del cambiamento e come si misura davvero il successo

Una migrazione senza uno sponsor a livello di direzione tende a perdere i finanziamenti nel momento in cui incontra il primo vero ostacolo, e ogni migrazione lo incontra. Un comitato di governance con dirigenti sia del business sia dell'IT, riunito a cadenza fissa, dà al progetto un luogo dove risolvere le dispute sull'ambito e gli sforamenti di budget prima che diventino politici.

La gestione del cambiamento corre in parallelo al lavoro tecnico, non dopo. Significa formazione pianificata intorno al pilota e a ogni fase di attivazione, un piano di comunicazione che dica ai team coinvolti cosa cambia e quando, e un rilascio agli utenti a scaglioni, così il supporto non si trova a rispondere alle domande di tutta l'organizzazione il primo giorno.

Misura il successo su un piccolo insieme di indicatori concreti:

• Disponibilità del sistema durante e subito dopo ogni fase di attivazione, confrontata con il valore di riferimento del sistema legacy.

• Integrità dei dati, verificata con i controlli di fedeltà costruiti durante la migrazione stessa.

• Variazione dei costi di supporto, per capire se volume e gravità dei ticket calano davvero dopo la migrazione.

• Indicatori di business legati alla giustificazione originaria della migrazione: evasione degli ordini più rapida, minore rischio di conformità o costi di licenza più bassi.

Una volta conclusa la migrazione conta altrettanto la disciplina FinOps. La spesa cloud, e sempre più i costi dei carichi di lavoro legati all'intelligenza artificiale, tende a crescere silenziosamente dopo l'attivazione se nessuno si occupa del monitoraggio continuo dei costi. Assegna quella responsabilità prima che la migrazione finisca, non dopo la prima fattura a sorpresa.

Due esempi svizzeri che dimostrano l'efficacia della migrazione a fasi

La migrazione dell'Amministrazione federale svizzera a SAP S/4HANA ha adottato deliberatamente un'attuazione a fasi, traendo insegnamenti da ogni fase di rilascio prima di estenderla alla parte successiva del sistema produttivo. Bühler ha seguito un percorso simile con la sua transizione selettiva dei dati, riducendo il volume dei dati prima di dimensionare l'investimento infrastrutturale su un insieme di dati più snello.

Alcune aziende applicano alle migrazioni legacy una filosofia a fasi, guidata da persone senior.

• Idealmente gli ingegneri senior restano coinvolti nei progetti dalla prima consulenza fino alla consegna, per evitare le riscritture a metà percorso che possono verificarsi quando i team cambiano.

• Il nostro lavoro su migrazioni legacy e replatforming segue la stessa struttura di valutazione, pilota e rilascio a fasi descritta qui sopra.

• Il lavoro correlato di integrazione di sistemi e sviluppo di API sostiene la mappatura delle dipendenze e i modelli a facciata su cui le migrazioni si appoggiano.

Un team compatto, con meno passaggi di mano, tende a conservare più contesto tra una fase e l'altra rispetto a team grandi con rotazioni frequenti.

I passi da fare prima di fissare una data di migrazione

Prima di stabilire una data di attivazione, mettiti in ordine su questi punti:

1. Completa un inventario di applicazioni e dati, comprese le Fachanwendungen che nessuno ha ancora documentato.

2. Nomina uno sponsor a livello di direzione e costituisci un comitato di governance con autorità sia sul business sia sull'IT.

3. Definisci l'ambito di un pilota su un carico di lavoro rappresentativo e a basso rischio, con criteri di superamento chiari.

4. Svolgi le verifiche sui fornitori, comprese le clausole di protezione dei dati, prima di firmare qualsiasi cosa.

5. Fissa una durata del pilota di 90-180 giorni con un punto di controllo vincolante per la decisione se procedere o no.

6. Coinvolgi sicurezza, ufficio legale, responsabili dei dati, operations e una guida tecnica senior dal primo giorno, non dopo l'avvio del pilota.

Prevedi una riserva di budget per almeno una dipendenza non pianificata. Ce n'è sempre una.

Come Ampersand Labs accompagna una migrazione legacy a fasi

Ampersand Labs conduce le migrazioni come qualsiasi altro incarico: ingegneri senior coinvolti dalla prima conversazione fino alla consegna, così nulla viene riscritto a metà percorso perché un nuovo team ha ereditato le supposizioni di qualcun altro. Quella continuità è il punto centrale quando una migrazione si estende su mesi e su più attivazioni a fasi. Se la tua organizzazione sta valutando se ai suoi sistemi convenga un lift-and-shift, un replatforming o un approccio strangler pattern completo, una chiamata conoscitiva è il modo più rapido per capirlo prima di impegnare budget. Possiamo aiutarti anche con il lavoro su API e integrazione di sistemi da cui dipendono quasi tutte le migrazioni legacy e con la manutenzione software e il supporto mensile una volta che il nuovo sistema è in funzione. Dai un'occhiata ai nostri casi di studio per vedere come la consegna a fasi ha funzionato per altre organizzazioni svizzere, poi scrivici dalla pagina del servizio di migrazione legacy per definire un audit di preparazione alla migrazione.

Domande frequenti

Perché nel 2026 i sistemi di sicurezza legacy non riescono a scalare?

I sistemi di sicurezza legacy in genere non sono stati progettati per il traffico su scala cloud, per gli standard di autenticazione moderni o per le integrazioni via API che le applicazioni attuali richiedono. Continuare ad applicare patch di solito aggiunge soltanto complessità, senza intervenire sull'architettura di fondo: per questo il rischio di sicurezza è uno dei motivi più frequenti per avviare una migrazione.

Che cos'è la migrazione di dati legacy?

La migrazione di dati legacy è il processo di estrazione, trasformazione e caricamento dei dati da un sistema obsoleto verso una nuova piattaforma, preservandone accuratezza e completezza. Richiede prima di tutto la classificazione dei dati, la separazione dei dati personali da quelli operativi e controlli di fedeltà che confrontino i record vecchi e nuovi prima del passaggio definitivo.

Come si trasferiscono i dati da un sistema legacy a SAP?

Il trasferimento dei dati verso SAP, compreso SAP S/4HANA, segue di norma una struttura con valutazione, pilota e rilascio a fasi, spesso abbinata a una transizione selettiva che migra solo i dati ancora necessari a livello operativo. Bühler ha usato esattamente questo approccio e ha ridotto in modo significativo il volume dei dati operativi prima di dimensionare la nuova infrastruttura.

Quante aziende usano ancora sistemi legacy?

Non esiste una cifra unica e universale, perché "legacy" comprende tutto: dai mainframe di decenni fa alle applicazioni di cinque anni prossime alla fine del supporto. Ciò che è costante in tutti i settori è che quasi tutte le organizzazioni di media dimensione e del settore pubblico hanno almeno un sistema abbastanza vecchio da creare rischi di integrazione, sicurezza o conformità: per questo la pianificazione di una migrazione a fasi resta attuale, indipendentemente dalla diffusione esatta.

Quanto costa una migrazione legacy con Ampersand Labs?

Il prezzo dipende dall'ampiezza dell'intervento, cioè se si tratta di un replatforming completo, di una migrazione di sistema o di un progetto di integrazione circoscritto, e le tariffe aggiornate si trovano direttamente nella pagina dei prezzi di Ampersand. Una chiamata conoscitiva è il modo più rapido per ottenere una stima definita sui tuoi sistemi specifici.

Da leggere

• Die Mitte: oltre 600 siti web di un partito politico svizzero gestiti da un unico sistema.

• Arthouse Kinos: un nuovo sito web e la vendita di biglietti per i cinema più iconici di Zurigo.

• Repa Immobiliare: un portafoglio immobiliare senza carta, con un software che non va mai online.