Quando non conviene portare un'app Windows sul Web: tabella decisionale e la soluzione realistica della "divisione"

“Vorremmo portare sul Web l’applicazione Windows che usiamo internamente” — questo tipo di richiesta arriva sempre più spesso. Spesso è una motivazione più che ragionevole, ma approfondendo il discorso capita non di rado di trovarsi davanti a team pronti a migrare per intero al Web un’applicazione che, in realtà, ne uscirebbe più scomoda da usare e più costosa.

Lo diciamo subito: questo articolo non è un invito a “non migrare mai al Web”. Esistono moltissime situazioni — uso da più sedi, riduzione della gestione dei dispositivi — in cui la migrazione Web è chiaramente la scelta giusta. Il problema è trattare come “modernizzazione = migrazione Web” anche applicazioni la cui natura non si presta al Web. In questo articolo raccogliamo i criteri che usiamo davvero, nel lavoro quotidiano di sviluppo Windows su commessa, per individuare i casi in cui è meglio non migrare al Web, e presentiamo la divisione come soluzione realistica all’alternativa secca tra “tutto Web” e “tutto Windows”.

1. La conclusione, prima di tutto (tabella decisionale)

Il punto chiave è valutare non l’applicazione nel suo complesso, ma ogni singola funzione o caratteristica che l’app possiede.

E ora la conclusione, anticipata subito.

• Nella richiesta “vogliamo andare sul Web” si mescolano di solito tre problemi diversi. Il fastidio della distribuzione, i vincoli sul luogo di utilizzo e l’obsolescenza tecnologica. Ognuno ha una soluzione diversa, e la migrazione Web è l’unica soluzione possibile solo per una parte di essi (capitolo 2).
• Le app con integrazione di dispositivi, elaborazione di file locali o funzionamento offline è più sicuro non portarle sul Web, almeno per queste parti. I browser limitano deliberatamente l’accesso alle risorse locali per motivi di sicurezza: non è un difetto del Web, ma la sua stessa filosofia progettuale¹. Esistono soluzioni alternative, ma portano con sé altri costi: limitazioni sui browser supportati, maggiore complessità operativa (capitoli 3-5).
• La migrazione Web è una “riscrittura”, non un “porting”. Gli asset delle schermate esistenti non si possono riportare così come sono, e una volta completata l’app nasce un nuovo costo continuativo: la gestione del server. Se la stima non parte da questa premessa, il piano rischia di sfaldarsi in corso d’opera (capitolo 7).
• La soluzione realistica è la divisione. Portare sul Web consultazione, aggregazione e report, mantenere su Windows l’integrazione con i dispositivi e l’inserimento dati sul campo, collegando le due parti con API e database comuni. Si può partire in piccolo rispetto a una migrazione completa e procedere a partire dalle parti che rendono di più (capitolo 8).

2. Scomporre cosa significa davvero “vogliamo andare sul Web”

Quando riceviamo una richiesta di migrazione Web, la prima cosa che facciamo è scomporre la richiesta. Dietro le parole “vogliamo andare sul Web” si nasconde di solito uno (o più) di questi tre problemi.

(1) Vogliamo eliminare il fastidio della distribuzione e degli aggiornamenti. Il problema è del tipo “ad ogni nuova versione dobbiamo andare a installarla su tutte le macchine”. La migrazione Web risolve certamente questo problema, ma si può risolvere anche senza migrare al Web. Passando a un metodo di distribuzione con aggiornamento automatico integrato, come ClickOnce o MSIX, si può azzerare quasi del tutto il lavoro di distribuzione restando un’applicazione Windows. Ne parliamo nel dettaglio in “Come scegliere il metodo di distribuzione di un’app Windows”. Se il fastidio della distribuzione è l’unica motivazione, la migrazione Web è un investimento eccessivo.

(2) Vogliamo poterla usare da qualsiasi luogo e da qualsiasi dispositivo. L’uso da più sedi, l’accesso da un cliente o da casa, la consultazione da tablet — qui la migrazione Web dà davvero il meglio di sé. Ma anche in questo caso vale la pena distinguere se si vuole “usare tutte le funzioni da ovunque” oppure semplicemente “consultare i dati da ovunque”. Nella pratica è spesso la seconda opzione, nel qual caso basta un’architettura divisa (capitolo 8) che porta sul Web solo la parte di consultazione e aggregazione.

(3) Vogliamo allontanarci da una tecnologia obsoleta. La motivazione è del tipo “chi l’ha sviluppata se n’è andato” oppure “siamo preoccupati di restare su .NET Framework”. È una preoccupazione legittima, ma la soluzione non è necessariamente la migrazione Web. Se comunque bisogna ricostruire l’applicazione e la natura del lavoro si presta all’uso desktop, esiste anche l’opzione di ricostruirla come app Windows sull’ultima versione di .NET (“Tabella decisionale per scegliere tra WinForms, WPF e WinUI”). Va anche tenuto presente che passare al Web non mette al riparo dall’obsolescenza. Il caso, ancora ben presente, di un sistema Web aziendale costruito esclusivamente per IE e rimasto senza via d’uscita con il pensionamento di IE ne è un esempio (“La sopravvivenza in modalità IE dei sistemi Web aziendali e la relativa strategia d’uscita”). Anche le applicazioni Web richiedono manutenzione per stare al passo con l’evoluzione dei framework e dei browser: “andare sul Web” non significa “liberarsi dalla manutenzione”.

Scomponendo la richiesta in questo modo emerge cosa risolve solo la migrazione Web, cosa può essere risolto anche in altro modo e cosa la migrazione Web non risolve affatto. A questo punto si può verificare se l’app presenta funzioni che rientrano nei “casi in cui è meglio non migrare al Web” descritti di seguito.

3. Caso 1: collegamento diretto a dispositivi o periferiche

Comunicazione con macchinari di produzione, acquisizione dati da strumenti di misura o di ispezione, bilance o lettori di codici a barre collegati via seriale (RS-232C), controllo fine di stampanti speciali — le applicazioni con funzionalità che dialogano direttamente con l’hardware sono strutturalmente poco adatte alla migrazione Web, almeno per quella parte.

Il motivo è semplice: il codice che gira nel browser viene eseguito in un ambiente isolato chiamato sandbox. I browser bloccano deliberatamente l’accesso alle risorse locali, perché sarebbe un problema se la semplice apertura di una pagina Web permettesse di toccare liberamente file o dispositivi della macchina. Non è un difetto del Web: è la sicurezza stessa a essere progettata così. Ad esempio, anche in Blazor WebAssembly, che permette di scrivere un client Web in C#, il codice viene eseguito all’interno del sandbox di sicurezza del browser, e l’accesso al file system o l’apertura di connessioni di rete arbitrarie generano un’eccezione PlatformNotSupportedException¹. Ciò che si può fare è limitato a quanto supportato dal browser stesso².

Si potrebbe obiettare che “con la Web Serial API o la WebUSB il browser può comunicare via seriale”. È vero, ma il supporto dei browser è limitato. La Web Serial API è supportata dai browser basati su Chromium (Chrome, Edge, ecc.) e, a partire da Firefox 151 rilasciato nel maggio 2026, anche da Firefox desktop, ma Safari resta non supportato (e su mobile, Chrome per Android offre solo un supporto parziale alla seriale via Bluetooth), mentre WebUSB rimane limitato a Chromium³. Oltre a limitare il principale vantaggio della migrazione Web — “utilizzabile da qualsiasi browser” — l’utente deve anche selezionare e autorizzare il dispositivo tramite una finestra di dialogo del browser (almeno la prima volta, o ogni volta che si aggiunge un dispositivo), il che nella pratica rende spesso questa soluzione poco conveniente come meccanismo di integrazione con i dispositivi per un sistema aziendale.

Esiste anche la possibilità di aggirare il problema con un’architettura “app Web più agente d’integrazione residente su ogni dispositivo”, ma si tratta di una configurazione in cui rimane comunque un programma Windows che richiede distribuzione e aggiornamenti. Non è di per sé un male — anzi, è una delle forme dell’architettura divisa trattata nel capitolo 8 — ma è importante condividere già in fase di pianificazione che questa non è la stessa cosa dell’aspettativa iniziale secondo cui “migrando al Web non sarà più necessario installare nulla sui dispositivi”.

Per la progettazione della parte di integrazione con i dispositivi, vedere anche “Buone pratiche per la verifica e la visualizzazione dello stato dei dispositivi esterni”.

4. Caso 2: integrazione profonda con file locali o altre applicazioni

Il secondo caso più frequente è quello in cui il lavoro con file sulla macchina, o con altre applicazioni, è il cuore del processo aziendale.

• Monitorare una cartella condivisa o locale ed elaborare automaticamente i file che vi vengono depositati
• Convertire, rinominare o smistare in blocco centinaia o migliaia di file
• Avviare Excel e comporre report tramite COM, o interagire con macro Excel esistenti
• Scambiare dati con altre applicazioni aziendali tramite file o comunicazione tra processi

La regola generale per l’accesso ai file dal browser è che si limita ai “file selezionati dall’utente, di volta in volta, tramite una finestra di dialogo”. Non è possibile un accesso massivo senza intervento dell’utente, né un monitoraggio residente che continui a funzionare anche a browser chiuso. Le recenti aggiunte come la File System Access API consentono l’accesso limitato a una cartella scelta dall’utente, ed esiste persino un’API sperimentale (FileSystemObserver) per monitorare le modifiche in una cartella selezionata finché la pagina resta aperta, ma si tratta di funzionalità limitate a Chromium⁴, con lo stesso problema di “vincolare ai browser supportati” già visto per l’integrazione con i dispositivi. Avviare e controllare dal browser un altro processo locale, come Excel, semplicemente non è possibile.

Migrare al Web questo tipo di funzionalità richiede di cambiare il flusso di lavoro verso qualcosa come “far caricare i file all’utente sul server ed elaborarli lato server”. Se l’attività può funzionare in questo modo, è un’opzione valida; ma se si hanno esigenze come gestire abitualmente file di dimensioni dell’ordine dei gigabyte, elaborare localmente dati che non possono uscire dall’azienda, o un forte accoppiamento con asset Excel, è più ragionevole — sia per chi sviluppa sia per chi usa — mantenere quella parte come applicazione Windows (o, per elaborazioni non presidiate come il monitoraggio di cartelle o l’elaborazione batch, come servizio Windows). Un punto a cui prestare particolare attenzione riguarda l’integrazione COM con Excel: Microsoft sconsiglia e non supporta l’automazione di Office da ambienti non presidiati e non interattivi come i servizi⁵, quindi il codice che pilota Excel automaticamente dovrebbe risiedere lato applicazione desktop, dove un utente ha effettuato l’accesso, oppure va riscritto per leggere e scrivere tramite librerie basate su Open XML che non avviano affatto Office. Trattiamo la costruzione dell’integrazione con Excel in “Come costruire l’output di report Excel” e il monitoraggio di cartelle in “Le basi sicure di FileSystemWatcher”.

5. Caso 3: usata sul campo con rete instabile, per attività che non possono fermarsi

Per sua natura, un’applicazione Web presuppone che la connessione di rete sia attiva. Vale per le app Web con rendering lato server, ma anche per Blazor Server, molto diffuso nel mondo C#: poiché ogni operazione dell’interfaccia viene elaborata tramite una connessione persistente con il server, l’app smette di funzionare non appena la connessione si interrompe. La documentazione ufficiale dichiara esplicitamente che non c’è supporto offline².

Questo diventa un problema in ambienti come i seguenti.

• Fabbriche, magazzini, siti esterni: il segnale Wi-Fi viene ostacolato da scaffalature metalliche o macchinari, con micro-interruzioni quotidiane
• Linee che non possono fermarsi: una schermata di registrazione o di istruzioni bloccata anche solo per pochi minuti incide sulla produzione o sulle spedizioni
• Sedi con connessione debole o instabile: uffici temporanei che dipendono da rete mobile, navi, aree montane e simili

Un’applicazione Windows nativa può essere costruita in modo naturale per mantenere i dati localmente, continuare a funzionare offline e sincronizzarsi al ripristino della connessione. Il funzionamento offline è citato dalla stessa Microsoft tra i motivi per scegliere un’app nativa⁶. È tecnicamente possibile rendere offline anche un’app Web, tramite una PWA (service worker) o un’architettura che mantiene i dati lato client, ma costruire tutto questo — sincronizzazione e risoluzione dei conflitti incluse — richiede un investimento aggiuntivo non trascurabile, che va nella direzione opposta rispetto all’aspettativa iniziale di “risparmiare passando al Web”.

Il criterio decisivo è: “se la rete si interrompe per 30 minuti, quell’attività può aspettare?”. Se non può aspettare, almeno la schermata che gestisce quell’attività dovrebbe funzionare localmente.

6. Caso 4: l’inserimento dati veloce e massivo, prevalentemente da tastiera, è al centro dell’attività

Registrazione di bolle, controllo qualità e registrazione delle spedizioni, schermate di gestione delle chiamate in un call center — attività in cui una persona resta davanti a quello schermo tutto il giorno, digitando grandi quantità di dati principalmente da tastiera. È un ambito in cui l’interfaccia desktop raggiunge un livello di rifinitura molto alto, ed è proprio l’ambito in cui la migrazione Web tende a peggiorare visibilmente la qualità percepita.

• Latenza di risposta: nei modelli con connessione al server come Blazor Server, ogni operazione dell’utente comporta un andata e ritorno in rete, aumentando la latenza dell’interfaccia². Anche solo poche decine di millisecondi per operazione, su migliaia di operazioni al giorno, si traducono in una sensazione percepibile di “lentezza”.
• Riproduzione del comportamento da tastiera: elementi dati per scontati nel lavoro di inserimento dati — lo spostamento tra i campi con Invio, l’assegnazione dei tasti funzione, la validazione istantanea durante la digitazione — finiscono per essere costruiti in contrasto con il comportamento predefinito del browser (Invio che invia il modulo, F1 che apre la guida, e così via). Non è impossibile, ma significa pagare un costo aggiuntivo per raggiungere una qualità che un framework e un componente griglia desktop offrono già di serie.
• Griglie con grandi quantità di dati: realizzare per il Web una griglia di livello desktop — capace di scorrere fluidamente in modo virtuale decine di migliaia di righe e di supportare modifica delle celle, blocco delle colonne e copia-incolla — richiede l’adozione di un componente commerciale avanzato e un notevole lavoro di ottimizzazione.

Per la consultazione, le approvazioni o l’inserimento occasionale, un modulo Web è più che sufficiente. Ma per una schermata in cui la velocità di inserimento incide direttamente sulla produttività aziendale, va verificato con lucidità se si beneficerà davvero del vantaggio della migrazione Web (utilizzabile da qualsiasi luogo) — o se quella schermata, in realtà, verrà sempre e solo usata da una postazione fissa in ufficio. Se il luogo di utilizzo è fisso, la migrazione Web non porta alcun vantaggio, solo perdite.

7. Caso 5: iniziare una “riscrittura” con il preventivo di un “porting”

Finora abbiamo parlato di funzionalità e modalità d’uso; l’ultimo aspetto riguarda la struttura dei costi. Lo schema classico con cui un piano di migrazione Web si sfalda a metà percorso è preventivare l’operazione come un porting — “spostare sul Web quello che già c’è” — per poi scoprire in corso d’opera che si trattava in realtà di una riscrittura completa.

• Gli asset delle schermate non si possono riportare. Non esiste un modo realistico per convertire automaticamente in Web le definizioni e la logica delle schermate di WinForms o WPF: l’interfaccia va riprogettata e ricostruita schermata per schermata. Il numero di schermate moltiplicato per la loro complessità diventa direttamente lo sforzo stimato.
• La logica di business va prima censita. In un’applicazione utilizzata per molti anni, non è raro che regole di business assenti dalla documentazione esistano soltanto nel codice. La migrazione Web include il lavoro di riportarle tutte alla luce e reimplementarle. Vale esattamente il principio “non riscrivere tutto di getto” esposto in “La sopravvivenza e la migrazione delle applicazioni aziendali VB6 / Access”.
• I costi operativi post-completamento aumentano strutturalmente. La gestione di un’app desktop consisteva nel prendersi cura dei dispositivi, ma con un’app Web nascono compiti continuativi: costruzione, monitoraggio, backup e aggiornamenti dei certificati e della sicurezza di un server (o di un ambiente cloud). Se in azienda non c’è questa capacità, si pagherà mensilmente un fornitore esterno. Il confronto dei costi della migrazione Web deve includere anche questo costo ricorrente, non solo lo sviluppo iniziale.
• Cambiano le premesse di sicurezza. Nel momento in cui un’app che girava solo all’interno della LAN aziendale viene messa sul Web e resa accessibile dall’esterno, il livello richiesto di autenticazione, autorizzazione, cifratura delle comunicazioni e difesa dagli attacchi sale di un gradino. Anche questo fa parte del “costo della migrazione Web”.

Lo ripetiamo: nessuno di questi punti è un argomento contro la migrazione Web, ma materiale per preventivarla sulla premessa corretta. Se, anche considerando riscrittura e costi ricorrenti, i benefici della migrazione Web restano superiori, si può procedere. Se non lo sono, conviene prima verificare se modernizzare restando un’app Windows (migrazione all’ultima versione di .NET, miglioramento del metodo di distribuzione, rinnovamento dell’interfaccia) — un investimento più contenuto — possa soddisfare gran parte della motivazione.

8. La soluzione realistica: non ridurre tutto alla scelta secca tra tutto Web e tutto Windows

Portando tutto quanto detto finora nella pratica, nella maggior parte dei casi la risposta non è né “migrazione Web completa” né “mantenere lo status quo”, ma la divisione.

L’idea è semplice: applicare la tabella decisionale del capitolo 1 non all’app nel suo insieme, ma funzione per funzione.

• Cosa portare sul Web: consultazione, ricerca e aggregazione di dati che più sedi o più persone devono vedere, download dei report, operazioni leggere come le approvazioni. Anche la manutenzione delle anagrafiche rientra di solito qui.
• Cosa mantenere su Windows: integrazione con dispositivi e periferiche, monitoraggio ed elaborazione batch di file locali, attività sul campo che non possono fermarsi nemmeno offline, schermate di inserimento dati veloce.
• Cosa condividere: il database e la logica di business. Centralizzare i dati in modo che sia l’app Web sia l’app Windows facciano riferimento alla stessa API (o allo stesso database). Condividendo questa parte, si ottiene un’architettura che soddisfa gran parte della motivazione alla migrazione Web: “il personale sul campo inserisce i dati tramite l’app Windows, mentre la sede centrale può verificarli immediatamente dal browser”.

Questa architettura ha vantaggi pratici che una migrazione Web completa non offre: l’ambito da ricostruire in una sola volta è più piccolo, si può procedere per gradi partendo dalle parti a maggior impatto (la consultazione), e l’usabilità sul campo non peggiora. Di contro, serve una struttura in grado di mantenere due sistemi — un’app Windows e un’app Web — quindi se l’app in questione è piccola e prevalentemente orientata alla consultazione, può convenire senz’altro una migrazione Web completa. Anche qui non si tratta di una scelta binaria, ma di una questione di misura.

Va anche detto che, per il requisito “vogliamo costruire le schermate con tecnologie Web, ma dobbiamo comunque toccare risorse locali”, esiste anche l’opzione ibrida di Electron o Blazor Hybrid (WebView2). Permettono di usare un’interfaccia in tecnologie Web senza i vincoli del sandbox del browser, ma attenzione: si tratta comunque di un’applicazione desktop che richiede distribuzione, e non risponde alla richiesta di “volerla usare solo dal browser”.

9. Checklist prima di decidere sulla migrazione Web

Verificare i punti seguenti prima di richiedere un preventivo o di presentare la proposta internamente riduce il rischio di dover rifare il lavoro.

1. Scomposizione della motivazione: qual è il problema reale — il fastidio della distribuzione, il luogo di utilizzo o l’obsolescenza tecnologica? Se è solo la distribuzione, basterebbe cambiare il metodo di distribuzione?
2. Presenza di integrazione hardware: esistono funzionalità che comunicano direttamente con dispositivi seriali/USB, strumenti di misura o stampanti speciali? Se sì, decidere in anticipo come trattare quella parte (mantenerla su Windows / architettura con agente).
3. Dipendenza da risorse locali: c’è monitoraggio di cartelle, elaborazione batch di file, integrazione di processo con Excel e simili? Il flusso di lavoro può essere trasformato in un modello di elaborazione lato server?
4. Requisiti offline: se la rete si interrompe per 30 minuti, quell’attività può aspettare?
5. Peso del lavoro di inserimento dati: esistono schermate in cui si digita da tastiera per l’intera giornata? Quella schermata verrà davvero usata “da qualsiasi luogo”?
6. Realtà di utenti e luoghi: chi vuole vedere o inserire cosa, e da dove? È “tutti devono usare tutte le funzioni dall’esterno” oppure “la sede centrale vuole solo consultare i dati”?
7. Struttura operativa: chi si occuperà della costruzione, del monitoraggio e degli aggiornamenti di sicurezza del server? Quanto costerà al mese?
8. Collocazione della logica di business: la documentazione corrisponde al codice? Il tempo necessario per il censimento è stato incluso nel preventivo?

Se anche solo uno dei punti dal 2 al 5 si applica, consigliamo di considerare come approccio principale un’architettura divisa piuttosto che una migrazione Web completa. Per un quadro generale su cosa chiarire prima di affidare l’incarico, vedere anche “Cosa chiarire prima di affidare a terzi lo sviluppo su commessa di un’app Windows”.

Riepilogo

La migrazione Web è uno strumento, non un fine. Aiuta chiaramente nell’uso da più sedi e nella riduzione della gestione dei dispositivi, ma l’integrazione con i dispositivi e l’elaborazione di file locali si scontrano con vincoli che derivano dalla progettazione di sicurezza del browser, difficili da aggirare con la scelta del framework o con il lavoro di sviluppo; il funzionamento offline e l’inserimento dati veloce possono essere tecnicamente affrontati, ma il costo di costruzione e gestione tende a remare contro l’obiettivo iniziale di “semplificare le cose passando al Web”. E la migrazione Web è una riscrittura, non un porting: una volta completata, aggiunge un nuovo costo continuativo, la gestione del server.

Proprio per questo, la decisione pratica non è “migrare al Web oppure no”, ma una questione di progettazione: “quali funzioni portare sul Web, quali mantenere su Windows e cosa condividere”. Dal censimento dell’applicazione esistente fino alla decisione sulla migrazione Web e alla progettazione dell’architettura divisa, serve spesso un giudizio basato sulla realtà del codice e dell’operatività: se siete indecisi, contattateci pure.

Articoli correlati

• Cosa chiarire prima di affidare a terzi lo sviluppo su commessa di un’app Windows
• La sopravvivenza e la migrazione delle applicazioni aziendali VB6 / Access — tabella decisionale tra mantenere, incapsulare e sostituire
• Tabella decisionale per scegliere tra WinForms, WPF e WinUI
• Come scegliere il metodo di distribuzione di un’app Windows (MSI / MSIX / ClickOnce / xcopy / aggiornatore personalizzato)
• La sopravvivenza in modalità IE dei sistemi Web aziendali e la relativa strategia d’uscita
• Buone pratiche per la verifica e la visualizzazione dello stato dei dispositivi esterni
• Le basi sicure di FileSystemWatcher
• Come costruire l’output di report Excel

Aree di consulenza correlate

Komura Soft LLC si occupa di consulenza tecnica per valutare se migrare al Web un’applicazione Windows esistente, per progettare architetture divise Web+Windows e per lo sviluppo o la modifica di applicazioni aziendali con integrazione di dispositivi ed elaborazione locale.

• Sviluppo di app Windows
• Modifica e manutenzione di software Windows esistente
• Consulenza tecnica e revisione della progettazione
• Contatti

Riferimenti

Articoli correlati

Articoli recenti con gli stessi tag per approfondire argomenti vicini.

Argomenti correlati

Queste pagine collocano l’argomento in un contesto più ampio di servizi e decisioni.

Servizi collegati all’argomento

L’articolo è direttamente collegato ai servizi seguenti.

Domande frequenti

Domande che ricorrono nelle consulenze sull’argomento dell’articolo.

Se comunque aggiorniamo una vecchia app Windows, conviene approfittarne per portarla sul Web?

Non consigliamo di migrare al Web per il solo motivo che l'app è "vecchia". La migrazione Web richiede un impegno più vicino a una riscrittura completa che a un semplice porting, e anche le applicazioni Web sono soggette all'obsolescenza tecnologica (un sistema Web aziendale rimasto vincolato a IE ne è un esempio da manuale). Il criterio decisivo non dovrebbe essere l'anzianità della tecnologia, ma l'effettivo modo in cui l'app viene utilizzata. Se viene usata da più sedi e si vuole ridurre la gestione dei dispositivi, la migrazione Web ripaga. Ma se l'app è incentrata sull'integrazione con dispositivi o sull'elaborazione di file locali, spesso conviene di più modernizzarla restando un'app Windows: passare a una versione più recente di .NET, rinnovare l'interfaccia.

Migrando al Web, almeno il fastidio della distribuzione e dell'installazione non sparisce?

Elimina il lavoro di distribuzione lato client, ma se questa è l'unica motivazione esistono soluzioni più leggere di una migrazione Web completa. Passare a un metodo di distribuzione con aggiornamento automatico integrato, come ClickOnce o MSIX, può rendere quasi superflue le visite di installazione macchina per macchina, mantenendo l'app come applicazione Windows. E se si migra comunque al Web, si assume un nuovo costo operativo continuativo: costruzione, monitoraggio e aggiornamenti di sicurezza di un server (o di un ambiente cloud). Valutate sia i costi che eliminate sia quelli che aggiungete prima di decidere.

È possibile migrare al Web solo una parte dell'applicazione?

Sì, e nella pratica questa è spesso la risposta più realistica. Uno schema tipico consiste nel portare sul Web la visualizzazione dei dati, l'aggregazione, i report e la consultazione da più sedi, mantenendo invece come app Windows l'integrazione con i dispositivi, l'inserimento dati veloce sul campo e l'elaborazione di file locali, collegando le due parti tramite un'API e un database condivisi. Rispetto a una migrazione Web completa, l'ambito da ricostruire in una sola volta è più piccolo, e si può procedere per gradi partendo dalle parti in cui la migrazione Web rende di più.

Che dire di opzioni intermedie come Electron, PWA o Blazor Hybrid?

Si tratta di soluzioni di natura diversa che vanno considerate separatamente. Electron e Blazor Hybrid (WebView2) funzionano come applicazioni desktop, quindi possono accedere a file e dispositivi senza i vincoli del sandbox del browser, pur scrivendo l'interfaccia con tecnologie Web. Restano però applicazioni desktop che richiedono distribuzione e aggiornamenti, quindi non rispondono alla richiesta di "poterla usare solo dal browser". Una PWA, invece, può dare la sensazione di un'app installata (ad esempio ancorata alla barra delle applicazioni), ma nella sostanza resta un'applicazione Web eseguita nel browser, con le stesse restrizioni di accesso alle risorse locali di una normale app Web. È fondamentale, prima di tutto, scomporre con precisione quale problema si vuole risolvere considerando la migrazione Web.

Profilo dell’autore

Pagina di presentazione dell’autore dell’articolo.

Go Komura

Rappresentante di KomuraSoft LLC

Specializzato nello sviluppo di software Windows, nella consulenza tecnica e nell’analisi dei malfunzionamenti, soprattutto nei progetti con sistemi esistenti e guasti difficili da riprodurre.