Migrare da .NET Framework a .NET moderno: costi, strategie e rischi

Se la tua azienda usa da anni un gestionale, un portale o un programma di magazzino scritto da uno sviluppatore che "lavorava in .NET", è probabile che dietro le quinte giri .NET Framework. Funziona, nessuno lo tocca, e per questo è facile dimenticarsene. Prima o poi, però, qualcuno pone la domanda: "Ma questo software è ancora aggiornabile? Quanto costerebbe portarlo su qualcosa di più moderno?"

Questa guida è scritta per chi quella domanda deve rispondere senza essere uno sviluppatore: titolari, responsabili IT di una PMI, project manager. Spiega che cosa cambia tra il vecchio e il nuovo mondo .NET, quali parti si portano via con relativa facilità e quali no, quali strategie esistono, quanto costa con ipotesi dichiarate e dove restano indispensabili le persone, anche ora che gli strumenti di intelligenza artificiale aiutano molto.

Che cosa sono .NET Framework e .NET (senza gergo)

.NET è la piattaforma di Microsoft su cui girano moltissimi software aziendali: fornisce i mattoni di base (gestione dei dati, della rete, delle pagine web, della stampa) su cui lo sviluppatore costruisce il programma. Esistono due "generazioni":

• .NET Framework: la prima generazione, nata nei primi anni Duemila. Funziona solo su Windows. L'ultima versione è la 4.8: Microsoft la mantiene e la corregge, ma non la fa più evolvere.
• .NET (senza "Framework", chiamato in passato anche ".NET Core"): la generazione attuale, riscritta da zero. Funziona su Windows, Linux e macOS, è molto più veloce, si installa in modo più semplice e riceve le novità. Ogni anno esce una nuova versione; alcune hanno supporto lungo (chiamate LTS, Long Term Support) e altre breve.

L'analogia più vicina: .NET Framework è un'automobile affidabile di vent'anni fa che il costruttore continua a tenere in garage per i ricambi; .NET moderno è il modello attuale, con un motore diverso. Non si cambia il motore con un cacciavite: si valuta se conviene riparare, ristrutturare o sostituire.

Verifica sempre le date ufficiali. Il calendario di supporto di ogni versione è pubblico sul sito di Microsoft (cerca "ciclo di vita .NET"). Qualsiasi cifra o scadenza che leggi in un articolo, compreso questo, va confrontata con quella pagina prima di prendere decisioni.

Perché ci si pone il problema: le ragioni vere

Un software che funziona non va toccato "perché sì". Le ragioni per cui conviene valutare una migrazione sono concrete:

1. Vincolo di piattaforma. .NET Framework richiede Windows. Se vuoi spostare il programma su un server economico Linux, su container, su un servizio cloud moderno, non puoi.
2. Costi di hosting e prestazioni. Le versioni moderne usano meno memoria e processore a parità di lavoro. Su un software con molti utenti, la differenza si vede nella bolletta del server.
3. Difficoltà a trovare persone. Chi inizia oggi studia .NET moderno. Trovare qualcuno che voglia lavorare su WebForms o su tecnologie di quindici anni fa è sempre più difficile e più caro.
4. Librerie e integrazioni che si fermano. Sempre più componenti di terze parti (pagamenti, firma digitale, fatturazione elettronica, servizi cloud) offrono novità solo per .NET moderno. Le versioni per Framework smettono di essere aggiornate.
5. Sicurezza e conformità. Un sistema operativo o un componente fuori supporto è un problema per le assicurazioni, per i clienti che ti auditano e per il GDPR (una violazione su un sistema non aggiornato è difficile da giustificare).
6. Evoluzione del prodotto. Nuove funzioni (accesso da telefono, interfaccia moderna, integrazione con servizi esterni) sono più semplici da costruire sulla piattaforma attuale.

Esistono anche ragioni sbagliate per migrare: "perché la tecnologia è vecchia" senza un danno concreto, "perché lo fanno tutti", "perché il nuovo fornitore preferisce lavorare così". Se il software gira da dieci anni su un server stabile, serve a venti persone e non deve cambiare, lasciarlo com'è può essere la scelta più razionale. Ne parliamo più avanti.

Che cosa si porta via e che cosa no

La buona notizia è che molta parte del lavoro scritto in .NET Framework si trasferisce. La parte cattiva è che alcune tecnologie non hanno un equivalente diretto e vanno riscritte.

Si porta con relativa facilità

• La logica di business (calcoli, regole, validazioni) scritta in C# "pulito", cioè senza dipendenze dal sistema operativo o da componenti vecchi.
• Le librerie condivise (progetti che contengono codice riutilizzabile).
• L'accesso ai dati fatto con Entity Framework (lo strumento che collega il programma al database), con alcune differenze da gestire.
• I servizi in background e le attività pianificate.

Va riscritto o ripensato

Una conseguenza pratica: la migrazione non è un solo progetto, ma tre. Una parte è quasi meccanica (aggiornare file e riferimenti), una parte è adattamento (sistemare le differenze), una parte è riscrittura. I costi stanno quasi tutti nella terza.

Le strategie possibili

1. Tutto in una volta ("big bang")

Si congela il vecchio software, si migra tutto in un unico progetto e a una certa data si passa al nuovo.

• Quando funziona: il software è piccolo, ben conosciuto, con test affidabili e una finestra in cui si può fermare.
• Rischi: se qualcosa va storto, va storto tutto insieme. Spesso emergono problemi nell'ultima settimana, quando c'è meno margine.

2. A tappe ("incrementale")

Il vecchio e il nuovo software convivono. Un componente fa da "vigile urbano" (si chiama reverse proxy): le richieste che riguardano le parti già migrate vanno al nuovo sistema, le altre al vecchio. Si migra un modulo alla volta (fatturazione, anagrafiche, magazzino…) e il vecchio si spegne solo alla fine. In gergo si chiama approccio "strangler", cioè "a soffocamento": il nuovo cresce intorno al vecchio finché lo sostituisce.

• Quando funziona: sistemi grandi o critici, che non possono fermarsi, con budget distribuito nel tempo.
• Rischi: per un periodo bisogna far convivere due sistemi (accesso, sessioni, dati condivisi); il costo totale può superare quello di un big bang, ma ogni passo è piccolo e reversibile.

3. Riscrittura da zero

Si decide che il vecchio codice non vale la pena di essere portato e si ricostruisce il sistema con tecnologie e un disegno nuovi.

• Quando funziona: il software è confuso, privo di test, i processi aziendali sono cambiati molto e comunque andrebbe ripensato.
• Rischi: è la strada più costosa e quella dove più spesso ci si dimentica che il vecchio codice contiene anni di regole di business mai scritte altrove (quel caso particolare del cliente X, quell'arrotondamento chiesto dal commercialista). Ripartire da zero significa riscoprirle una a una, di solito a spese tue.

Per la grande maggioranza delle PMI la strada più sensata è la seconda, oppure la prima per i software piccoli. La terza va scelta con la consapevolezza che non è una migrazione ma un nuovo progetto (vedi "Quanto costa sviluppare un gestionale su misura" e "Come si svolge un progetto software, fase per fase").

Le fasi di un progetto di migrazione, in parole semplici

1. Inventario e valutazione. Si elencano progetti, librerie, database, integrazioni e tecnologie usate. Esistono strumenti di Microsoft (il .NET Upgrade Assistant e analizzatori di compatibilità) che segnalano automaticamente cosa non è portabile. Questo passaggio produce una mappa dei rischi: da qui in poi le stime sono molto più affidabili.
2. Rete di sicurezza. Prima di toccare il codice, si scrivono test che fissano il comportamento attuale: "con questi dati in ingresso, il risultato deve essere questo". Senza test, a fine migrazione nessuno può dire se il nuovo software fa le stesse cose del vecchio.
3. Aggiornamento "tecnico". Si portano i progetti al formato moderno, si sostituiscono le librerie obsolete, si adegua la configurazione.
4. Adattamento e riscritture. Si sistemano le differenze di comportamento e si riscrivono le parti che non hanno equivalenti (tipicamente interfaccia e comunicazione tra servizi).
5. Verifica con dati reali. Si fa girare il nuovo sistema in parallelo al vecchio, con copie dei dati veri, confrontando i risultati.
6. Passaggio in produzione. Con un piano per tornare indietro, se qualcosa non va.
7. Stabilizzazione. Alcune settimane di assistenza ravvicinata.

Quanto costa: un modo di ragionare

Chi propone un prezzo fisso senza aver visto il codice sta indovinando. La stima onesta parte da cosa c'è dentro il software. Quello che segue sono ordini di grandezza con ipotesi dichiarate, da non usare come preventivo.

Ipotesi di calcolo: costo medio di una giornata di lavoro di un professionista senior, tra 400 e 500 euro (si usa 450 euro come valore centrale); software scritto in modo ordinato, con una persona che conosce il dominio disponibile per le domande; nessun cambiamento di funzioni durante la migrazione.

Che cosa fa salire il costo:

• Interfaccia da riscrivere. Di solito è la voce più grossa. Un'interfaccia WebForms con decine di schermate pesa più di tutta la logica sottostante.
• Mancanza di test. Costruirli a posteriori è lavoro in più, ma è il lavoro che protegge dal rischio.
• Librerie senza versione moderna. Ognuna è una piccola riscrittura.
• Codice che nessuno conosce più. Se l'autore non c'è e la documentazione manca, una parte del tempo è archeologia.
• Dati e database. Se anche il database va ripulito o spostato, aggiungi un progetto a sé.
• Coesistenza. Nella strategia a tappe, va aggiunto il costo del "ponte" tra vecchio e nuovo.

Che cosa tiene basso il costo:

• codice organizzato a strati, con la logica separata dall'interfaccia;
• test già presenti;
• una persona interna che sa dire "questo caso esiste, quest'altro no";
• il coraggio di non migrare funzioni che nessuno usa più. Un'analisi dei log d'uso, prima di partire, spesso elimina un quinto del lavoro.

Ricorda infine di mettere a bilancio il costo dell'alternativa: restare dove sei ha un costo, fatto di rischio, di hosting più caro, di difficoltà a trovare persone e di interventi urgenti a prezzi da emergenza. Quel costo non compare su nessuna fattura, finché non arriva.

E l'intelligenza artificiale?

Gli strumenti di IA aiutano davvero in questo tipo di lavoro, e vale la pena dirlo con precisione:

• Aiutano a capire. Possono riassumere cosa fa una porzione di codice sconosciuta, elencare le dipendenze, proporre una traduzione di una funzione da vecchia a nuova sintassi.
• Aiutano a scrivere bozze. Una prima versione di test, di documentazione, di codice di conversione, da rivedere.
• Fanno risparmiare tempo sulle parti ripetitive.

Ma non decidono cosa conviene migrare, non conoscono le regole non scritte della tua azienda, non possono garantire che il risultato sia equivalente, e a volte sbagliano in modo convincente: un calcolo tradotto con un arrotondamento diverso passa tutti i controlli visivi e sbaglia le fatture. Il lavoro che resta alle persone è quello decisivo: valutare, disegnare la strategia, scegliere cosa tenere, verificare i risultati, rispondere dell'esito. Ne parliamo in dettaglio in "L'IA non scrive il software al posto tuo" e, per il caso specifico del codice vecchio, nell'articolo dedicato alla modernizzazione con l'IA.

Come scegliere con chi farlo

Alcune domande utili da fare a un fornitore o a un freelance prima di accettare un'offerta:

1. "Hai già migrato software simili? Posso parlare con chi l'ha commissionato?"
2. "Come fai la valutazione iniziale?" Una risposta seria include l'analisi del codice e un prezzo separato per questa fase.
3. "Come garantisci che il nuovo software faccia quello del vecchio?" La risposta giusta parla di test e di esecuzione in parallelo.
4. "Cosa succede se a metà strada cambiamo idea?" La strategia a tappe permette di fermarsi senza perdere il lavoro fatto.
5. "Chi risponde del risultato?" Un nome e un ruolo, non "il team".
6. "Come usi l'IA in questo lavoro e chi controlla il risultato?"

Se stai cercando la persona giusta, su LancerJob puoi pubblicare una richiesta di progetto descrivendo cosa hai (versione, tecnologie, dimensione) e ricevere proposte da freelance .NET specializzati. Prima di farlo, la guida "Come scrivere una richiesta di progetto efficace" ti aiuta a non lasciare fuori l'essenziale.

Quando non migrare

Per equilibrio, i casi in cui lasciare tutto com'è è una scelta sensata:

• il software ha pochi utenti, nessun cambiamento in vista e gira su un sistema isolato dalla rete;
• il costo della migrazione supera di molto il costo di sostituire il software con un prodotto standard;
• l'azienda sta per cambiare processo o gestionale entro uno o due anni.

In questi casi vale la pena fare comunque tre cose a basso costo: copie di sicurezza verificate, documentazione minima (dove gira, come si riavvia, chi ha le credenziali) e un piano scritto per il giorno in cui qualcosa si romperà.

Errori da evitare

• Partire dal codice invece che dall'obiettivo. "Vogliamo migrare" non è un obiettivo. "Vogliamo spostarci su un server Linux entro marzo per dimezzare i costi" lo è.
• Chiedere un prezzo fisso prima della valutazione.
• Aggiungere funzioni durante la migrazione. Si perde il riferimento: non si sa più se una differenza è un errore o una novità.
• Saltare i test.
• Dimenticare chi usa il software. Se l'interfaccia cambia, serve formazione.
• Dare per scontato che "con l'IA si fa in una settimana". Può ridurre alcune attività, non elimina valutazione e verifica.

Dove servono ancora le persone

In un progetto di migrazione, le persone sono necessarie in ogni passaggio che conta. L'analista che ricostruisce le regole di business non scritte. Il progettista che sceglie tra strategia a tappe e big bang. Lo sviluppatore che riscrive le parti senza equivalente. Il tester che confronta vecchio e nuovo con dati reali. Il project manager che tiene insieme tempi, budget e collaudo. L'IA fa guadagnare tempo sulle parti ripetitive; la responsabilità del risultato resta di chi lo firma.

In sintesi

• .NET Framework funziona ancora, ma non evolve: la domanda è se i suoi limiti ti costano più della migrazione.
• La logica di business si porta spesso con facilità; interfacce WebForms, servizi WCF e componenti legati a Windows vanno riscritti e sono la voce di costo principale.
• Per la maggior parte delle PMI la strategia migliore è a tappe, con vecchio e nuovo in convivenza.
• Un prezzo serio nasce da una valutazione iniziale, non dall'intuito.
• L'IA accelera alcune attività, ma valutare, decidere e verificare restano compiti delle persone.

Hai un software in .NET Framework e vuoi capire da dove cominciare? Iscriviti alla waitlist di LancerJob: al lancio potrai descrivere il tuo progetto e ricevere proposte da professionisti .NET che hanno già affrontato migrazioni simili. Nel frattempo, leggi anche "Quanto costa sviluppare un gestionale su misura" e "I ruoli di un progetto software".