Blazor e migrazione aziendale: quando conviene passare da WebForms, WPF o ASP.NET MVC nel 2026

La migrazione a Blazor comincia sempre nello stesso modo: con un sistema che funziona e che nessuno vuole toccare.

In produzione dal 2008, ogni modifica rischia di rompere qualcosa, e la persona che lo ha scritto ha lasciato l'azienda nel 2014.

I nuovi arrivati lo guardano come si guarda un reperto archeologico, con rispetto misto a disagio.

Il CTO lo sa.

Sa che prima o poi andrà sostituito.

E ogni anno, quando arriva il momento del budget, la voce "migrazione" scivola all'anno successivo, perché c'è sempre qualcosa di più urgente.

Questa storia si ripete in centinaia di aziende italiane.

WebForms del 2008, WPF del 2011, ASP.NET MVC 4 del 2012 hanno fatto il loro lavoro per anni e continuano a farlo, ma che ogni anno costano di più da mantenere, diventano più difficili da estendere e più rischiose da modificare.

Nel frattempo, Blazor, il framework Microsoft per applicazioni web moderne in C#, è diventato abbastanza maturo da essere una destinazione concreta.

La domanda, quindi, non è se Blazor sia all'altezza, perché nel 2026 la risposta è sì e non serve dibatterla.

La domanda è: nel mio caso specifico, quando ha senso migrare, quanto costa e come si struttura il progetto per non paralizzare il business durante la transizione?

Qui dentro non trovi un tutorial su Blazor.

Trovi i segnali che dicono che il momento è arrivato, il caso specifico di WebForms, di WPF e di MVC che sono tre storie diverse.

I costi con ordini di grandezza verificati su progetti italiani, la scelta tra le due modalità di esecuzione, i quattro passi del progetto e le metriche con cui si difende in consiglio di amministrazione.

La migrazione a Blazor non è una questione tecnica: è una decisione di business che ha un costo immediato e un ritorno misurabile nel tempo. Ignorarla non la fa sparire: la rende più cara.

Cos'è Blazor e perché non è l'ennesimo framework del mese

Chi lavora da vent'anni in questo settore ha sviluppato un riflesso sano: quando sente "nuovo framework", pensa a quanto durerà.

Ha visto AngularJS morire e Angular nascere con lo stesso nome e un'altra anima, ha visto interi team riscrivere tutto due volte in cinque anni.

Lo scetticismo, qui, è esperienza.

Blazor è diverso per un motivo strutturale, non stilistico: permette di scrivere l'interfaccia web in C#, condividendo codice e competenze con il backend che hai già.

Per un'azienda che ha un team .NET non è una novità tecnologica, è un cambio nella struttura dei costi.

Con un frontend JavaScript, ogni funzionalità richiede due persone che si parlano, due repository, due modi di validare gli stessi dati, e la persona che conosce il frontend è sempre una sola e sempre occupata.

Con Blazor quella conversazione sparisce, perché ai due lati del confine c'è lo stesso linguaggio e spesso la stessa persona.

Microsoft lo usa internamente per strumenti di produttività e portali aziendali.

L’ecosistema di componenti copre tutti i pattern di interfaccia aziendale standard.

La documentazione è estesa, i problemi noti sono documentati con soluzioni consolidate.

Non è un framework in versione sperimentale usato da qualche startup: è tecnologia che banche, assicurazioni e manifatturiero europeo hanno in produzione.

Come funziona Blazor, in sintesi, per chi deve decidere, non implementare

I componenti dell'interfaccia si scrivono in C# dentro file .razor, dove il HTML e la logica convivono, e Blazor si occupa di aggiornare la pagina quando l'utente fa qualcosa.

Questo è tutto quello che serve sapere per decidere.

Esistono due modalità di esecuzione con conseguenze molto diverse su architettura, costi di infrastruttura e scalabilità, e ci arriviamo più avanti perché è una scelta che va fatta dopo, non prima.

Quello che conta adesso, per chi firma, è un altro numero: il tuo team .NET comincia a produrre valore in Blazor in settimane, non in mesi, e senza assumere specialisti di frontend.

Il che porta subito alla domanda successiva, quella che nessuna scheda tecnica risponde: come faccio a sapere se il momento per il mio sistema è adesso, o se posso rimandare ancora un anno senza pagarlo?

I segnali che indicano che è ora di migrare: la lista concreta

Nessuno decide di migrare guardando un grafico.

Si decide quando succedono tre cose nello stesso trimestre e qualcuno finalmente le mette in fila.

Il momento è arrivato quando il costo di tenere in vita il vecchio sistema supera quello di sostituirlo, e questo si riconosce da segnali precisi: quattro tecnici, che dicono che la piattaforma ti sta chiudendo le porte, e quattro organizzativi, che dicono che stai perdendo le persone.

Segnali tecnici

Il primo lo conosci già: il sistema gira solo su .NET Framework.

La 4.8 è l'ultima versione e riceve solo correzioni di sicurezza, niente funzionalità nuove.

Vuol dire niente API moderne di .NET 8 e .NET 9, prestazioni inferiori rispetto al runtime attuale, e una distanza che cresce ogni mese rispetto all'ecosistema NuGet, dove i pacchetti nuovi puntano solo alle versioni moderne.

Il secondo arriva di conseguenza e fa più male: le dipendenze di terze parti smettono di aggiornarsi.

Ti ritrovi con librerie ferme, vulnerabilità CVE non corrette perché la versione che le risolve richiede .NET moderno, e componenti bloccati a versioni vecchie solo per non rompere la compatibilità con altri componenti bloccati.

È un nodo che si stringe da solo.

Il terzo si vede il giorno del rilascio.

L'applicazione gira su IIS con configurazioni fatte a mano, quindi non puoi metterla in container, non puoi usare Azure App Service con una configurazione standard e non puoi costruire una pipeline moderna senza aggirare qualcosa.

Ogni rilascio è un evento manuale, e ogni evento manuale è un errore umano in attesa del suo turno.

Il quarto non dipende da te: il browser ha smesso di supportare qualcosa che l'applicazione usa.

ActiveX, plugin specifici, comportamenti che funzionavano solo su Internet Explorer.

Quando la tua applicazione WebForms dipende da funzionalità che i browser moderni hanno rimosso, non stai gestendo un debito: stai correndo su un timer che qualcun altro ha impostato.

Segnali organizzativi

Questi non compaiono in nessun report tecnico, ed è il motivo per cui arrivano tardi in riunione.

Il primo è il ricambio del personale che porta via conoscenza mai scritta.

Ogni persona che se ne va si porta dietro pezzi di comprensione del sistema che non esistono in nessun documento.

Se l'inserimento di una persona nuova richiede più di tre mesi per arrivare a una produttività accettabile, il costo del ricambio è già insostenibile e nessuno lo ha ancora messo a bilancio.

Il secondo lo senti nelle stime.

Quando un team esperto stima una funzionalità in una settimana e ne impiega tre, il problema non è il team: è la complessità accidentale che il sistema ha accumulato.

E quella complessità si traduce direttamente in tempo di risposta al mercato.

Il terzo arriva dal business e suona come una richiesta banale: API REST per l'app mobile, integrazione con un servizio cloud, esportazione dei dati in tempo reale per l'analisi.

Ogni richiesta che il sistema legacy non può soddisfare è un costo opportunità, e la differenza con gli altri costi è che questo non compare da nessuna parte.

Il quarto è quello che fa più male da leggere.

Gli sviluppatori bravi, quando scoprono in colloquio che lavoreranno su WebForms o su WPF legacy, dicono di no.

Non stai solo pagando di più per mantenere il sistema: stai perdendo la possibilità di assumere le persone che potrebbero migliorarlo.

Tre di questi segnali insieme e la discussione è chiusa.

Il punto è che la risposta giusta dipende da cosa hai in casa, perché WebForms, WPF e MVC sono tre malati con tre diagnosi diverse.

Prima di scoprire quale delle tre diagnosi è la tua, conta i segnali in cui ti sei riconosciuto leggendo.

Se sono tre, la decisione l'hai già presa e ti manca solo la strada per arrivarci senza fermare l'azienda.

Il corso Blazor comincia esattamente da lì: analisi del vostro stack attuale, architettura di riferimento costruita sul vostro progetto, e solo dopo il codice.Un'architettura di riferimento costruita sui vincoli veri: postazioni bloccate dall'IT, rete di reparto, hardware da raggiungere, utenti che non possono fermarsi.

Scoprirlo da soli si misura in mesi.

Impararlo si misura in sessioni.

WebForms: quando la migrazione a Blazor è urgente

Su WebForms non c'è ambiguità, e Microsoft l'ha detto senza giri di parole: non verrà portato su .NET Core e non riceverà nuove funzionalità.

WebForms è il caso con l'urgenza più alta, e non perché smetta di funzionare: continuerà a girare finché .NET Framework 4.8 è supportato, quindi fino al 2029.

È il divario tra quello che il business chiede e quello che la piattaforma può dare a crescere ogni anno, e a un certo punto quel divario diventa la ragione per cui perdi un cliente.

Il problema specifico di WebForms: il codebehind

C'è però una complicazione tecnica che rende WebForms più difficile da migrare rispetto ad altri sistemi legacy, e ha un nome preciso: il codebehind.

Apri un file .aspx.cs di un'applicazione tipica e trovi tutto insieme.

Un solo metodo Button_Click che interroga il database, esegue calcoli di business, formatta l'output e aggiorna l'interfaccia, senza nessuna separazione.

Non era una cattiva idea nel 2005: era il modo in cui la piattaforma chiedeva di lavorare.

Il risultato, vent'anni dopo, è che la migrazione diretta non esiste.

Prima che Blazor entri in scena, qualcuno deve estrarre la logica di business in servizi separati, isolare l'accesso ai dati e ridurre il codebehind a pura presentazione.

È un lavoro che costa, si chiama rifattorizzazione preliminare, e ha un effetto collaterale che nessuno mette nel preventivo: rende il codice testabile e comprensibile ancora prima che si scriva una riga di Blazor.

Nelle aziende che l'hanno fatto sono saltati fuori bug e comportamenti non documentati che stavano nascosti là dentro da anni, e in due casi su tre quei comportamenti erano diventati funzionalità su cui qualcuno faceva affidamento.

Cosa si porta in Blazor e cosa si butta di un'applicazione WebForms

La domanda che decide il preventivo di una migrazione WebForms non è quante pagine .aspx ci sono, è quanto di quelle pagine sopravvive al passaggio.

La risposta onesta è: meno di quanto sembra, e la parte che non sopravvive è anche quella che nessuno ha mai documentato.

Si porta quasi tutto quello che sta sotto la presentazione.

Le regole di business, una volta estratte dal codebehind, diventano servizi C# che il progetto Blazor usa senza modifiche.

Il database resta dov'è, le stored procedure continuano a girare, i report generati lato server si ricollegano, e le librerie di dominio scritte in C# si ricompilano su .NET moderno con interventi che nella maggior parte dei casi si contano in giorni, non in settimane.

Su questo pezzo il lavoro è di trasloco, non di riscrittura, e segue le stesse regole della migrazione da .NET Framework 4.8 a .NET moderno.

Non si porta niente di quello che WebForms ha inventato per gestire l'interfaccia.

Il ciclo di vita della pagina, in Blazor non esiste: al suo posto c'è un componente con un ciclo di vita diverso, e il codice scritto per il primo non si adatta al secondo, si ributta.

I controlli server, si sostituiscono con i componenti della libreria che sceglierai.

I master page diventano layout.

I controlli commerciali non hanno un percorso di conversione: si ricomprano nella versione Blazor e si riscrivono le pagine che li usano.

Poi c'è il ViewState, e merita un paragrafo suo perché è la sorpresa più cara.

Per vent'anni ha tenuto lo stato della pagina nascosto dentro un campo HTML, e questo ha permesso di scrivere pagine che funzionano senza che nessuno abbia mai deciso dove sta lo stato.

In Blazor lo stato è esplicito: o appartiene al componente, o appartiene a un servizio.

Ogni pagina che si appoggiava al ViewState per ricordare qualcosa tra un PostBack e l'altro va riprogettata, non tradotta.

La verifica costa mezza giornata e la fa il tuo team senza consulenti.

Si cercano nel progetto tre cose: quante pagine contengono un UpdatePanel, quante righe ci sono dentro i Page_Load, e quante volte compare l'accesso alla Session.

Quel terzo numero è il miglior predittore del costo che conosca, meglio del conteggio delle pagine: dove la sessione è usata come memoria condivisa tra pagine.

La migrazione non è una traduzione, è una riprogettazione del modo in cui l'applicazione tiene i dati tra un passo e l'altro.

Quando la migrazione WebForms a Blazor è urgente

L'urgenza scatta quando si verifica almeno una di quattro condizioni:

• Il sistema non funziona su browser moderni senza modalità di compatibilità,
• Usa componenti commerciali che il fornitore ha dichiarato a fine vita,
• Non può essere messo in sicurezza per vulnerabilità nelle dipendenze non aggiornabili,
• Oppure il team non riesce più a rilasciare funzionalità a una velocità accettabile per il business.

In questi quattro scenari ogni mese di rinvio ha un costo diretto e misurabile.

Fuori da questi quattro, hai tempo per pianificare, ed è la posizione migliore in cui si possa affrontare un progetto del genere.

C'è però un vincolo di calendario che vale la pena mettere in fila, perché cambia il senso della parola "tempo".

Il supporto di .NET Framework 4.8 arriva al 2029, e tre anni sembrano tanti finché non li dividi: un anno per far approvare il budget e definire il perimetro, otto-dodici mesi di progetto vero su un'applicazione media, qualche mese di consolidamento e spegnimento del vecchio sistema.

Chi parte nel 2028 sta già gestendo un'emergenza.

Nel manifatturiero italiano questo vincolo ha una variante sua.

Le applicazioni WebForms che vedo nei reparti sono quasi sempre quelle che raccolgono i dati di produzione, gestiscono le bolle o espongono il portale ai fornitori, e hanno una caratteristica comune: nessuno può fermarle per due settimane, perché se si fermano si ferma la linea.

È il motivo per cui su questi sistemi il collaudo di accettazione va pensato prima del preventivo e non dopo: la parità funzionale va dimostrata su un impianto che continua a girare, e quella è una voce di costo del progetto, non un dettaglio organizzativo.

Con WPF, invece, la storia cambia completamente: lì la fretta non c'è, e proprio per questo si sbaglia strada più spesso.

WPF: Blazor Hybrid come alternativa alla riscrittura totale

WPF non è malato.

Microsoft lo supporta, riceve aggiornamenti su .NET moderno, un'applicazione WPF su .NET 8 gira con prestazioni eccellenti e usa le librerie attuali senza problemi.

Chi ti dice di riscriverlo perché è vecchio non ha guardato i fatti.

Il problema di WPF non è tecnologico, è geografico: gira solo su Windows.

E questo diventa caro nel momento esatto in cui il business chiede di vedere le stesse cose da un browser, da un tablet o da un Mac.

Le richieste arrivano sempre da tre direzioni diverse e sempre nello stesso trimestre.

L'interfaccia HMI di una macchina industriale che gli operatori vogliono anche sul tablet in reparto.

Il gestionale che i commerciali vogliono usare da casa, e a casa hanno un Mac.

Il cruscotto direzionale che il CFO vuole sull'iPad in aeroporto.

Nessuna di queste tre richieste è irragionevole, e a nessuna delle tre WPF può rispondere.

Il problema specifico di WPF: quanto della tua applicazione è davvero portabile

La domanda che decide il preventivo non è quanto è grande l'applicazione, ma è quanto è separata.

WPF ha avuto MVVM fin dall'inizio, e questa è la buona notizia.

La cattiva è che averlo adottato e averlo applicato sono due cose diverse.

Apri il file xaml.cs della finestra più usata e conta le righe che non riguardano la presentazione: se ci trovi query al database, regole di calcolo e gestione degli errori di dominio, sei esattamente nella posizione di chi ha WebForms, solo con un'interfaccia più bella davanti.

Il code-behind dello XAML è il codebehind di vent'anni fa che ha cambiato estensione.

Da lì in poi il conto si fa in due colonne.

Si portano quasi intatti i ViewModel e i servizi, a una condizione: che non conoscano la vista.

Un ViewModel che chiama il Dispatcher, che apre una MessageBox o che decide una Visibility ha la vista dentro, e va ripulito prima.

Non si portano invece lo XAML, gli stili, i template, le animazioni e i controlli di terze parti: griglie, editor e componenti per WPF non hanno un equivalente automatico in Blazor, vanno rifatti con la libreria corrispondente e la licenza si ricompra.

La vista è la parte più piccola in righe di codice e la più grande in aspettative degli utenti, ed è il motivo per cui i preventivi fatti contando i file sbagliano quasi sempre per difetto.

La verifica costa mezza giornata e la può fare il tuo team senza consulenti: si prendono le tre finestre più usate, si contano le righe di code-behind che non sono presentazione e si guarda l'elenco dei pacchetti di terze parti nel file di progetto.

Se le righe sono poche e i pacchetti sono standard, la migrazione è un lavoro di traduzione con un rischio noto.

Se il code-behind è denso, prima serve la stessa rifattorizzazione preliminare del caso WebForms, e conviene farla comunque: rende l'applicazione testabile mesi prima che qualcuno scriva la prima riga di Blazor.

Blazor Hybrid: il percorso di modernizzazione meno invasivo per WPF

Qui esiste una strada che quasi nessuno considera perché sembra troppo comoda per essere vera.

Blazor Hybrid, tramite .NET MAUI, permette di ospitare componenti Blazor dentro un'applicazione desktop WPF o WinForms già esistente.

Non è un framework alternativo: è un ponte, e la finestra WPF resta dov'è.

Il modo giusto di usarlo è incrementale.

Si individua un modulo abbastanza isolato, la reportistica, la configurazione, la ricerca avanzata, lo si riscrive come componente Blazor e lo si ospita dentro la finestra WPF attraverso WebView2.

Il resto dell'applicazione continua a funzionare come ha sempre fatto, e nessuno in azienda si accorge che è iniziata una migrazione.

I vantaggi si accumulano in fretta: nessuna riscrittura totale con il rischio che si porta dietro, il team impara Blazor su moduli a basso rischio prima di toccare il cuore del sistema, il business non subisce interruzioni, e alla fine lo stesso codice Blazor può essere distribuito sia come applicazione desktop sia come applicazione web.

Due dettagli operativi decidono se il ponte regge davvero.

Il primo è il runtime di WebView2, che serve sulla macchina dell'utente: su Windows 11 c'è già, su Windows 10 va verificato, e su una postazione bloccata dal reparto IT o su un PC di produzione in fabbrica è la prima cosa da controllare, prima ancora di scrivere il componente.

Il secondo è la proprietà dello stato.

Il componente Blazor e la finestra WPF che lo ospita condividono i servizi registrati nel contenitore delle dipendenze, quindi possono leggere gli stessi dati: la tentazione è dare a ciascuno la propria copia, e il risultato sono due verità che divergono al primo salvataggio.

Lo stato ha un proprietario solo, e il componente ospitato lo chiede al servizio invece di tenerselo.

L'accesso al disco, all'hardware e alle librerie native resta sul lato .NET dell'applicazione: se il componente Blazor comincia ad avere bisogno di fare cose da desktop, la scelta giusta non era l'ibrido.

Quando considerare Blazor Desktop rispetto a Blazor Hybrid

La scelta tra le due dipende da dove vuoi essere tra tre anni, non da dove sei adesso.

Se l'obiettivo finale è eliminare WPF e avere un'applicazione web, prima di tutto, Blazor Desktop con MAUI è la destinazione e l'ibrido è solo il traghetto.

Se invece l'obiettivo è modernizzare l'interfaccia mantenendo un'applicazione desktop con accesso alle risorse locali, allora Blazor Hybrid dentro WPF o WinForms non è il percorso: è il punto di arrivo.

Per le applicazioni industriali e SCADA, dove l'accesso diretto all'hardware non è negoziabile, l'ibrido è quasi sempre la risposta giusta.

C'è però un caso in cui l'ibrido non va usato, ed è quello delle interfacce che ridisegnano molte volte al secondo: sinottici di impianto, andamenti in tempo reale, quadri di controllo con centinaia di elementi animati.

Lì il passaggio attraverso la WebView costa più di quanto rende, e la risposta corretta è tenere WPF dov'è e mettere Blazor accanto, come applicazione web separata per chi guarda da fuori, invece che dentro la stessa finestra.

Su quando conviene l'uno e quando l'altro, con i criteri messi in fila, trovi tutto nell'articolo su WPF e Blazor per le interfacce HMI SCADA industriali.

C'è però un terzo caso, ed è quello in cui la risposta corretta più spesso è "non fare niente".

Vale la pena guardarlo, perché è anche il più frequente.

C'è un modo economico di imparare queste cose e uno caro.

Quello caro è accorgersi al settimo mese che il componente ospitato non regge il refresh del sinottico e che lo stato ha due proprietari.

Quello economico è il corso Blazor, dove i trade-off tra Server, WebAssembly e Hybrid li discuti con chi li ha già pagati sulla propria pelle.Impari dove l'ibrido è la risposta giusta e dove è una trappola, sul tuo codice, non in astratto.

ASP.NET MVC: quando conviene migrare e quando no

Qui ti aspetti che ti dica di migrare, ma non lo farò.

ASP.NET Core MVC non è una tecnologia in via di estinzione: è pienamente supportata, riceve aggiornamenti, scala, si containerizza, si integra con i servizi cloud moderni.

Migrare da MVC a Blazor non serve a salvare il sistema, serve a ottimizzare i costi di sviluppo e l'esperienza utente.

Sono due conversazioni diverse e vanno tenute separate.

Quando la migrazione da MVC a Blazor ha senso

Il caso più solido lo riconosci da un file.

Se nel progetto c'è un JavaScript da cinquemila righe cresciuto negli anni per gestire interazioni complesse, validazioni dinamiche, aggiornamenti parziali della pagina e comunicazione in tempo reale, quel file è un secondo sistema con un secondo linguaggio, e nessuno lo ha mai progettato.

Blazor lo elimina e riporta tutto in C#.

Il secondo caso è organizzativo e si vede nella coda del lavoro.

Se ogni funzionalità richiede il coordinamento tra chi scrive C# e chi scrive JavaScript, e le persone che scrivono JavaScript sono meno di quelle che servono, quel collo di bottiglia non si risolve con la buona volontà.

Blazor lo risolve strutturalmente, perché toglie il confine.

Quando la migrazione da MVC a Blazor non conviene

Non conviene se l'applicazione MVC funziona bene e ha poco JavaScript scritto a mano: lo sforzo della migrazione non trova benefici proporzionati.

Non conviene se hai requisiti SEO critici che richiedono un rendering lato server impeccabile, perché su certi pattern Blazor Server ha ancora limiti rispetto a MVC, anche se .NET 8 e .NET 9 hanno migliorato molto la situazione.

E non conviene se il budget non copre una migrazione fatta bene: una migrazione veloce, senza rifattorizzazione architetturale, produce componenti Blazor con problemi di prestazioni peggiori del punto di partenza.

La regola pratica sta in una riga.

Se stai valutando di migrare per "stare al passo con i tempi", senza un beneficio concreto che sai nominare, non migrare.

Se hai un problema specifico che Blazor risolve e MVC no, migra quel problema e poi decidi sul resto.

Come si migra un'applicazione MVC a Blazor senza riscriverla

C'è una terza possibilità che le due sezioni precedenti lasciano fuori, ed è quella che nella pratica risolve la maggior parte dei casi MVC: non migrare l'applicazione, migrare le pagine di cui si lamentano gli utenti.

Da .NET 8 un componente Blazor può essere ospitato dentro una view MVC esistente, senza creare un progetto nuovo e senza toccare il resto del sistema.

L'applicazione resta ASP.NET Core MVC: stesso instradamento, stesso cookie di autenticazione, stesso contenitore delle dipendenze, stesso layout.

Cambia una cosa sola: su quella pagina il pezzo interattivo lo disegna un componente Blazor invece di un file JavaScript cresciuto per anni.

Il modo giusto di scegliere la prima pagina è cinico.

Si prende il file JavaScript più grande del progetto, si guarda quale view lo carica, e si comincia da lì.

È la pagina dove il beneficio è massimo e dove il confronto prima e dopo è visibile anche a chi non legge codice, che è esattamente quello che serve per ottenere il permesso di continuare.

Ci sono due cose da sapere prima di partire:

• La prima è che l'interattività costa una connessione: una pagina con un componente in modalità Server tiene aperto un canale verso il server; quindi, va messa dove serve e non ovunque solo per simmetria.
• La seconda è che finiscono per convivere due modi di validare gli stessi dati, quello di MVC e quello di Blazor, e se le regole stanno in due posti prima o poi divergono.

Le regole di validazione vanno spostate in un servizio comune prima di iniziare, non dopo.

Il risultato è che la domanda "migriamo a Blazor sì o no" smette di essere una decisione da centomila euro e diventa una serie di decisioni da una pagina alla volta, ognuna con un costo stimabile in ore e un beneficio mostrabile in una riunione.

Su un'applicazione MVC sana questa è quasi sempre la risposta giusta, e spesso è anche l'unica migrazione che verrà fatta davvero, perché dopo tre o quattro pagine ci si accorge che il resto stava benissimo com'era.

E adesso arriva la parte che decide se il progetto si farà: il numero da portare in riunione, quello che quasi tutti sbagliano per difetto.

Il costo reale di una migrazione a Blazor: con numeri

Il momento in cui la maggior parte dei progetti di migrazione viene condannata non è tecnico: è la riunione in cui qualcuno dice un numero a sensazione, quel numero entra nel verbale, e otto mesi dopo diventa la prova che il team ha fallito.

Il costo di una migrazione a Blazor si stima su quattro fattori misurabili: quante schermate, in che stato è il codice, quante integrazioni ci sono e quanto costa chi lavora.

Tutto il resto sono aggiustamenti.

I fattori che determinano il costo di migrazione

Il primo fattore, e il più pesante, è il numero di schermate da migrare: le view in ASP.NET MVC, le pagine .aspx in WebForms, le finestre in WPF.

Una schermata semplice, pochi campi e logica lineare, richiede dalle 8 alle 16 ore tra analisi, riscrittura e test.

Una schermata complessa, con JavaScript intricato, vincoli di business non documentati e molte dipendenze, arriva a 40-80 ore.

Su applicazioni enterprise tipiche la media ponderata si assesta tra le 20 e le 30 ore per schermata, ed è il numero da usare finché non hai fatto l'inventario vero.

Il secondo fattore è la qualità di quello che c'è.

Un'applicazione con separazione chiara tra logica di business e presentazione costa dal 30% al 40% in meno rispetto a una con tutto nel codebehind o nei controller.

E il codice senza test automatici chiede uno sforzo aggiuntivo prima ancora di cominciare, perché senza test non hai modo di dimostrare che dopo la migrazione il comportamento è lo stesso.

Il terzo fattore è quello che si scopre in corsa.

Se il sistema si integra con altri sistemi interni tramite servizi SOAP, interoperabilità COM o chiamate dirette a database legacy, ogni integrazione richiede analisi dedicata e quasi sempre uno strato di adattamento.

Le integrazioni pesano tipicamente dal 20% al 30% del costo totale.

Il quarto fattore è il prezzo del lavoro.

In Italia nel 2026 uno sviluppatore .NET senior con esperienza su Blazor costa tra 55 e 85 euro l'ora come consulente esterno, oppure tra 70.000 e 100.000 euro l'anno di costo aziendale lordo come dipendente.

La squadra tipica per un'applicazione di media complessità è di due o tre persone per sei-nove mesi.

Ordini di grandezza per tipologia di applicazione

Messi insieme i quattro fattori, i numeri che escono su progetti italiani sono questi.

Un'applicazione WebForms piccola, dalle 20 alle 40 schermate con architettura pulita, richiede 400-800 ore, quattro-sei mesi con due persone, per un costo indicativo tra 25.000 e 65.000 euro.

Un'applicazione WebForms media, 60-100 schermate con codebehind accoppiato, sale a 1.200-2.000 ore, otto-dodici mesi con due o tre persone, tra 75.000 e 160.000 euro, rifattorizzazione preliminare inclusa.

Un'applicazione WebForms grande, oltre le 150 schermate e critica per il business, chiede da 2.500 a oltre 4.000 ore, dodici-diciotto mesi con tre o quattro persone, tra 150.000 e 300.000 euro.

Gli stessi numeri, messi in colonna, si leggono meglio:

Qui la migrazione per moduli non è una preferenza: è l'unica strada che non metta a rischio l'azienda.

Un'applicazione WPF verso Blazor Hybrid si conta invece a moduli: uno di media complessità sta tra 200 e 400 ore, mentre la migrazione completa di un'applicazione enterprise tipica da 30-50 finestre richiede 1.500-3.000 ore su dodici-ventiquattro mesi.

Su tutti questi numeri va aggiunto un 15-20% per gestione del progetto, collaudo di accettazione e formazione.

E poi c'è la voce che non compare mai nei preventivi e che fa saltare i piani: il tempo delle tue persone.

Durante la fase attiva, gli sviluppatori interni dedicano tipicamente il 20-30% del loro tempo alla collaborazione con chi migra, e quel tempo lo stai già pagando per fare altro.

Rileggi la riga della tabella che ti riguarda.

Poi aggiungi il 20-30% del tempo dei tuoi sviluppatori interni, che stai già pagando per fare altro.

Il modo più caro di affrontare quel numero è affrontarlo senza sapere quale parte è rifattorizzazione, quale è riscrittura e quale è solo trasloco: nel corso Blazor la prima cosa che si fa è separare le tre voci sul tuo progetto.

Una stima costruita sull'inventario vero, non a sensazione, prima che entri in un verbale e diventi la prova che il team ha fallito.

Il preventivo sbagliato non costa quanto sbagli.

Costa il progetto.

Blazor Server vs Blazor WebAssembly: quale scegliere per la tua azienda

Questa è la scelta su cui ho visto litigare due team per tre settimane, con l'unico effetto di ritardare l'inizio del progetto.

Non è una questione di gusto tecnico, ed è più semplice di come viene raccontata.

Chi sono i tuoi utenti e dove stanno: se sono interni, su rete aziendale o VPN, Blazor Server; se sono esterni, tanti e su connessioni imprevedibili, Blazor WebAssembly.

Il resto sono conseguenze di questa risposta, e qui le tengo strette di proposito: il confronto per esteso, con i modelli di rendering e i comportamenti veri in produzione, sta nell'articolo su come si sceglie tra Blazor Server, WebAssembly e Auto.

Blazor Server: quando è la scelta giusta

In Blazor Server l'applicazione gira tutta sul server.

Il browser mostra l'HTML, ma ogni click e ogni tasto premuto viaggiano fino al server, che elabora e rimanda indietro solo le differenze da aggiornare.

Il browser è un terminale intelligente, il cervello sta dall'altra parte.

È la scelta corretta per le applicazioni interne, dove la latenza su rete locale è impercettibile.

È anche la scelta più prudente quando il team ha poca esperienza nel proteggere API REST esposte al browser, perché in Blazor Server il codice C# che accede ai dati non arriva mai al client: resta dove è sempre stato.

Ed è ideale quando servono notifiche, cruscotti che si aggiornano da soli, comunicazione in due direzioni.

Il limite lo paghi in memoria.

Ogni utente attivo tiene aperta una connessione, quindi il consumo del server cresce in modo lineare con gli utenti collegati insieme.

Con 50-200 utenti simultanei di un'applicazione interna non te ne accorgi.

Con 10.000 utenti simultanei di un portale pubblico, la bolletta dell'infrastruttura diventa una voce di bilancio.

Il secondo limite è meno noto e si manifesta al primo guasto di rete.

Se il canale verso il server cade, l'utente vede un avviso di riconnessione, e se la riconnessione non riesce lo stato di quella schermata è perso: il modulo compilato a metà se ne va insieme al canale.

Su un magazzino con rete senza fili a copertura discontinua non è un dettaglio teorico.

Si gestisce salvando fuori dal canale lo stato che conta, e sul bilanciatore serve l'affinità di sessione, perché l'utente deve tornare sul server che lo conosceva.

Blazor WebAssembly: quando è la scelta giusta

In WebAssembly l'applicazione viene scaricata nel browser e gira lì, sul computer dell'utente, mentre il server resta solo una API REST che fornisce dati.

Dopo il download iniziale, tipicamente tra 5 e 15 MB, l'interfaccia risponde senza latenza di rete.

È preferibile quando gli utenti sono esterni e le connessioni sono eterogenee, quando vuoi ridurre il carico del server su grandi volumi, quando l'applicazione deve funzionare anche senza rete.

Ed è la direzione giusta se vuoi una separazione netta tra frontend e backend, con API che riutilizzerai anche per il mobile.

Il conto lo paghi altrove: il primo caricamento è pesante rispetto a una SPA JavaScript tradizionale, la sicurezza è più delicata perché il codice gira sul client e non puoi nasconderci dentro niente, e le elaborazioni intensive sul client vanno più lente che sul server.

Le modalità di rendering di Blazor: quando non devi più scegliere

Con .NET 8 e .NET 9 Microsoft ha smesso di chiedere una scelta secca: nella stessa applicazione alcune parti possono girare in Server, altre in WebAssembly, con rendering statico sulle pagine non interattive.

Questa modalità ibrida, chiamata Blazor United o render mode, è la direzione verso cui Microsoft sta spingendo ed è il modo più flessibile di costruire applicazioni nuove.

Per una migrazione, la strategia ragionevole è partire da Blazor Server, che è più veloce da sviluppare, e portare in WebAssembly solo i moduli che ne traggono un beneficio reale.

Il che significa che questa decisione, quella su cui i team litigano per settimane, si può rimandare senza costi.

Quella che invece non si può rimandare è come organizzi il progetto, perché lì si decide se finirà.

Come strutturare il progetto di migrazione a Blazor: i 4 passi

Le migrazioni non falliscono per incapacità tecnica.

Falliscono per struttura, e il sintomo si vede al mese sette, quando il team è bravissimo, lavora tantissimo e il business non ha ancora visto niente di funzionante.

Un progetto di migrazione a Blazor si struttura in quattro passi che producono risultati prevedibili:

• Valutazione e definizione del perimetro, 2-4 settimane.
• Rifattorizzazione preliminare, 20-30% del tempo totale.
• Migrazione per moduli, il cuore del progetto.
• Consolidamento e ottimizzazione, 10-15% del tempo totale.

Passo 1: valutazione e definizione del perimetro (2-4 settimane)

Prima di scrivere una riga di Blazor serve sapere esattamente cosa c'è da migrare.

La valutazione produce l'inventario di tutte le schermate con la complessità stimata di ognuna, la mappa delle dipendenze tra moduli, l'elenco delle integrazioni esterne, l'inventario dei punti in cui logica di business e presentazione sono attaccate tra loro, e la fotografia dei test automatici esistenti.

Quell'ultimo punto sull'accoppiamento è il dato che predice il costo meglio di qualsiasi altro, ed è anche quello che nessuno misura prima di firmare.

In uscita servono tre cose: una stima di costi e tempi sul perimetro definito, una raccomandazione sulla strategia, e l'elenco dei moduli in ordine di priorità per rischio e valore.

Passo 2: rifattorizzazione preliminare (20-30% del tempo totale)

È il lavoro che separa la logica di business dalla presentazione nel sistema vecchio, prima ancora di toccare Blazor.

Non è una riscrittura: è estrarre la logica in servizi C# che il progetto Blazor userà senza modifiche.

Ed è il passo che le aziende saltano per risparmiare tempo, che è anche il motivo per cui la maggior parte dei progetti di migrazione sfonda il budget.

Su un'applicazione WebForms con cento view che hanno logica nel codebehind, saltarlo significa riscrivere non solo la presentazione ma anche tutte le regole di business, con il rischio di introdurre regressioni su comportamenti che nessuno aveva mai messo per iscritto.

Tre settimane risparmiate qui costano tre mesi al passo tre.

Passo 3: migrazione incrementale per moduli, il cuore del progetto

La migrazione avviene modulo per modulo, nell'ordine deciso nella valutazione.

Il pattern si chiama strangler fig, il fico strangolatore, e il nome descrive bene la cosa: il sistema vecchio continua a girare, i moduli Blazor gli crescono attorno, e un reverse proxy manda il traffico all'uno o all'altro a seconda della rotta.

Quando l'ultimo modulo è passato, il vecchio sistema si spegne senza che nessuno se ne accorga.

Il vantaggio è che il business non ha mai una finestra di indisponibilità.

I collaudi di accettazione di ogni modulo girano in parallelo con la produzione, e il passaggio avviene solo quando la parità funzionale è dimostrata.

L'ordine consigliato è controintuitivo e vale oro: prima i moduli meno critici e meno complessi, perché il team impari su codice a basso rischio; poi quelli molto visibili ma semplici, per far vedere al business qualcosa che funziona presto; il cuore del sistema per ultimo, quando le persone sanno cosa stanno facendo.

Passo 4: consolidamento e ottimizzazione (10-15% del tempo totale)

L'ultima fase è quella che tutti sottovalutano perché sembra la più noiosa: spegnimento del sistema vecchio, ottimizzazione delle prestazioni Blazor su dimensione dei bundle, caricamento differito e cache, revisione della sicurezza sull'intera applicazione, documentazione aggiornata e formazione sui pattern che il team ha stabilito strada facendo.

Spegnere un sistema legacy non è un click.

Ha integrazioni sparse in decine di punti dell'ecosistema aziendale, e alcune le scoprirai solo quando smetteranno di funzionare.

Metti in conto questa fase, o la pagherai due volte.

Adesso hai i quattro passi.

Sai anche che il sintomo del fallimento arriva al mese sette, quando il team lavora tantissimo e il business non ha ancora visto niente.

La differenza tra i due esiti non sta nei passi, sta in chi li governa: nel corso Blazor l'ordine dei moduli, il perimetro e i criteri di passaggio li decidete insieme a chi quei progetti li ha già portati in fondo.

Al mese tre il business vede qualcosa che funziona.

È l'unico modo per ottenere il permesso di continuare.

ROI della migrazione a Blazor: le metriche da monitorare

C'è un momento, in ogni progetto di questo tipo, in cui il CFO fa la domanda giusta: perché adesso?

La risposta tecnica non funziona.

Servono quattro numeri.

Il ritorno di una migrazione a Blazor si misura su manutenzione, tempo di rilascio, infrastruttura e rischio.

Il framework completo del business case della modernizzazione, quello da portare in consiglio, sta nella guida su quanto ti costa davvero il software legacy: qui restano i numeri specifici di Blazor.

Riduzione del costo di manutenzione

Il costo di mantenere un sistema legacy non è stabile: cresce ogni anno.

Le stesse modifiche richiedono più ore, i bug diventano più difficili da isolare, e le richieste che il sistema non riesce a soddisfare si accumulano in una coda che nessuno guarda più.

Indagini pubbliche su questo numero non ne esistono.

Quello che vedo sui progetti di migrazione WebForms che ho seguito, su applicazioni italiane di media complessità, è una riduzione tra il 35 e il 50% nel primo anno successivo, che continua a scendere man mano che il team prende confidenza.

Il calcolo da fare è semplice: prendi il costo annuo attuale di manutenzione, cioè ore dedicate per costo orario, applica il 40% di riduzione, proietta su cinque anni.

Quello è il risparmio sul solo fronte manutenzione, prima di guardare qualsiasi altra voce.

Riduzione del tempo di rilascio per le nuove funzionalità

Un sistema Blazor su .NET 8 o .NET 9 permette di aggiungere funzionalità in meno tempo grazie alla separazione delle responsabilità, alla testabilità e ai componenti riutilizzabili.

Sugli stessi progetti il tempo di rilascio di una nuova funzionalità cala tra il 25% e il 40%, e la differenza tra chi sta in fondo a quella forbice e chi sta in cima non è Blazor: è quanto lavoro di separazione era stato fatto prima.

Per il business questo si traduce in una cosa sola, e conviene dirla con le sue parole: lo stesso team, a parità di costo, consegna di più e risponde più in fretta a quello che chiede il mercato.

Risparmio su infrastruttura e licenze

Un'applicazione Blazor su .NET moderno gira su Linux, e questo da solo toglie dal conto le licenze di Windows Server.

Può essere messa in container, scalata in automatico, ospitata sui piani più economici di Azure App Service invece che su macchine virtuali dimensionate sul picco di dicembre.

Il calcolo non richiede un consulente, richiede l'ultima fattura.

Si contano i server che oggi esistono solo per far girare l'applicazione legacy e i loro core, si guarda quanto costa il rinnovo delle licenze e del contratto di manutenzione su quei core, e si somma la parte di lavoro sistemistico che se ne va ogni mese in aggiornamenti, certificati e configurazioni fatte a mano su IIS.

Quella somma è il costo dell'infrastruttura del vecchio sistema, e in genere sorprende chi la vede scritta per la prima volta, perché è sparsa su tre voci di bilancio diverse e nessuno l'aveva mai messa in colonna.

Su questo fronte la forbice tipica è del 20-40% di costi operativi in meno nel lungo periodo, ma va detto cosa la determina, perché non è automatica.

Il risparmio è reale quando l'applicazione diventa senza stato e scala in orizzontale su container piccoli.

Si assottiglia se resti su Blazor Server con molti utenti collegati insieme, perché ogni utente occupa memoria sul server e la memoria si paga: lì il conto va rifatto sul consumo misurato in collaudo, non sulla scheda commerciale del fornitore cloud.

Due voci non spariscono e vanno lasciate nel preventivo per onestà.

SQL Server resta SQL Server, a meno che tu non stia migrando anche il database, e non è questo il progetto.

E le licenze dei componenti di interfaccia si ricomprano nella versione Blazor: è una spesa una tantum, ma arriva prima del risparmio; quindi, nell'anno uno peggiora il flusso di cassa invece di migliorarlo.

Dirlo in riunione prima che lo scopra il controllo di gestione vale più di qualsiasi grafico.

Riduzione del rischio di sicurezza

È la voce più difficile da mettere a bilancio e la più cara quando si materializza.

Un sistema con dipendenze non aggiornabili ha un profilo di rischio che cresce da solo, senza che nessuno faccia niente.

Il costo medio di una violazione dei dati per una PMI italiana, secondo il Rapporto Clusit 2025, sta tra 150.000 e 500.000 euro tra rimedio, sanzioni e danno reputazionale.

Non lo puoi contabilizzare in anticipo, ma è il numero che rende il resto della discussione meno accademica.

C'è però un modo per far uscire questo rischio dalla categoria delle ipotesi, e negli ultimi due anni è arrivato da solo.

Con il recepimento italiano della direttiva NIS2, il decreto legislativo 138 del 2024, la sicurezza della catena di fornitura è diventata un obbligo per le aziende che rientrano nel perimetro e, di conseguenza, un questionario che quelle aziende girano ai loro fornitori.

Chi ha un sistema con dipendenze che non si possono aggiornare, a quel questionario non può rispondere di sì.

Lo stesso vale per le polizze cyber, dove la domanda sulle versioni supportate dei componenti in uso è ormai standard, e per gli audit dei clienti grandi.

Il punto pratico è questo: il rischio di sicurezza di un sistema legacy ha smesso di essere un costo eventuale e futuro, ed è diventato un requisito commerciale presente.

Una gara persa perché non puoi firmare un allegato tecnico è una cifra che il CFO capisce senza bisogno di spiegazioni.

Il calcolo del ROI: formula pratica

La formula sta in una riga: ROI uguale risparmi annui su manutenzione, tempo di rilascio e infrastruttura, moltiplicati per gli anni, meno il costo della migrazione, il tutto diviso per il costo della migrazione e moltiplicato per cento.

Su un'applicazione WebForms media, con un costo di migrazione di 120.000 euro e risparmi attesi di 60.000 euro l'anno, il ritorno è già positivo al secondo anno dalla conclusione e arriva al 50% al terzo.

Proiettato su cinque anni supera il 100% contando i soli risparmi di manutenzione, quindi escludendo velocità di sviluppo e riduzione del rischio.

Per confrontare con altri articoli correlati al tema della modernizzazione, leggi anche la guida sulla modernizzazione del software legacy e sull'impatto economico del software legacy non modernizzato.

La migrazione a Blazor non è un progetto tecnico, è una decisione strategica

Nel 2026 Blazor è una tecnologia matura, con Microsoft dietro, un ecosistema consolidato e una comunità ampia.

Scommetterci non è più un rischio tecnologico.

Il rischio, per chi ha WebForms, WPF legacy o sistemi MVC pieni di JavaScript, è continuare ad aspettare.

Il costo di non fare niente non è zero, ed è l'unica voce che nessuno mette a budget: manutenzione che cresce, funzionalità non rilasciate, rischio di sicurezza su dipendenze che non si aggiornano, e il ricambio di persone su un sistema che nessuno vuole toccare.

Sono quattro costi che aumentano ogni anno, in silenzio, senza mai comparire in una riga di bilancio.

C'è però una cosa che la tecnologia non risolve, ed è la ragione per cui parecchie migrazioni tecnicamente corrette finiscono male.

Il progetto lo devono guidare persone capaci di decidere l'ordine dei moduli, di dire di no a una scorciatoia che costerà tre mesi al passo successivo, di riconoscere quando il vecchio sistema sta nascondendo una regola di business che nessuno ha mai scritto.

Quelle competenze non le installi con un pacchetto NuGet e non le impari da un video: si costruiscono su progetti veri, con qualcuno accanto che ha già visto come vanno a finire.

Le aziende che pianificano la migrazione oggi, con metodo e senza urgenza, ottengono la stessa tecnologia a un terzo del costo di chi la farà in emergenza tra 18 mesi.

C'è chi la migrazione la farà scegliendo il momento, con il perimetro definito e i numeri in mano, e chi la farà perché un browser ha smesso di supportare qualcosa o un audit ha trovato una vulnerabilità che non si può correggere.

La tecnologia di arrivo sarà identica.

Quello che cambia è chi comanda il calendario.

Pensa alla riunione di budget del prossimo anno.

Puoi presentarti con la stessa voce rimandata per la quinta volta, oppure con un modulo già in produzione, un costo reale al posto di una stima a sensazione e un team che sa cosa sta facendo.

La differenza tra i due scenari comincia da una conversazione di trenta minuti sul tuo caso, e prosegue nel corso Blazor, dove si lavora sul tuo codice e non su un esempio.

Le competenze che servono per guidare una migrazione non si installano con un pacchetto NuGet.

Si prendono da chi le ha già.