Prima domanda: che cosa deve cambiare per l'utente?
La domanda iniziale è: che cosa deve poter fare l'utente che oggi non riesce a fare? «Vogliamo un gestionale moderno» è troppo vago per scegliere una soluzione. «Il cliente deve approvare gli ordini dal browser senza collegarsi alla rete aziendale» permette già di discutere flusso, autorizzazioni, dati, carico e tempi.
Un'applicazione desktop può essere resa disponibile da remoto, anche tramite un browser compatibile, senza riscriverne subito l'interfaccia. La documentazione Microsoft sul client web di Remote Desktop Services mostra questa possibilità. È una strada da valutare quando si vuole far usare online il prodotto pressoché com'è, verificando licenze, periferiche, prestazioni, gestione delle sessioni e sicurezza. L'esperienza rimane quella dell'applicazione esistente: accesso via browser e applicazione web nativa non sono la stessa cosa.
Se occorre offrire a clienti o partner un percorso nuovo, si può costruire un'interfaccia web che usa funzioni e dati del core attuale attraverso accessi controllati. In altri casi serve sostituire un modulo che non regge più le richieste. Esistono anche prodotti per i quali cambiare architettura o ricostruire il sistema è la scelta ragionevole. Microsoft distingue infatti rehosting, refactoring, nuova architettura e ricostruzione, tra le altre opzioni di modernizzazione.
Fonti: Microsoft Learn — Remote Desktop web client · Microsoft Learn — Strategie di modernizzazione
Quattro strade da confrontare
Le strade possibili non sono ordinate dalla migliore alla peggiore. Ciascuna sposta costi e rischi in punti diversi. Pubblicare l'applicazione esistente può anticipare l'accesso remoto, ma lascia intatte le sue limitazioni funzionali. Rifare tutto può semplificare alcune scelte architetturali, ma richiede di ricostruire comportamenti che spesso non sono documentati.
- Accesso remoto al prodotto attuale: utile se gli utenti devono lavorare online con funzioni già esistenti. Verificare licenze, sessioni simultanee, periferiche, connessione e protezione dell'accesso.
- Web Bridge sul core esistente: utile per una nuova esperienza nel browser o un'integrazione con terzi. Verificare il punto d'accesso alla logica, le regole applicative, l'identità e le autorizzazioni.
- Sostituzione progressiva: utile se un modulo frena l'evoluzione ma il resto del prodotto funziona. Verificare i confini del modulo, i dati condivisi, i test e la convivenza temporanea.
- Riscrittura completa: da valutare se il prodotto attuale non offre una base sostenibile per gli obiettivi futuri. Verificare le funzioni realmente usate, le regole implicite, la migrazione dei dati e la transizione dei clienti.
Prima della tecnologia, serve un inventario del prodotto reale
Un gestionale con anni di utilizzo non coincide con il solo repository. Comprende dati, importazioni, stampe, procedure di supporto, personalizzazioni per cliente e passaggi che gli utenti danno per scontati. Prima di stimare una riscrittura o scegliere un framework, vale la pena ricostruire almeno quattro mappe.
Una funzionalità poco visibile può essere essenziale. Un export notturno, per esempio, potrebbe alimentare contabilità e assistenza anche se nessuno lo cita nella prima riunione. Per questo intervistare chi sviluppa non basta: servono anche supporto, persone che seguono i clienti e utenti del prodotto.
- Uso: chi usa il prodotto, quali funzioni usa davvero e quali richieste arrivano più spesso.
- Architettura: componenti, dipendenze, database, servizi esterni e strumenti di distribuzione.
- Regole: calcoli, autorizzazioni, eccezioni, procedure manuali e differenze tra clienti.
- Rischio: flussi che fermerebbero il lavoro se smettessero di funzionare, parti senza test e possibilità di ripristino.
Dieci domande da portare in riunione
Copiate queste domande prima di discutere preventivi o tecnologie. Le risposte incomplete non bloccano la decisione: indicano che cosa va verificato per primo.
Le ultime due domande trasformano un'intenzione in un piano. Il rollback non è solo «rimettere il vecchio codice»: se due versioni hanno scritto sugli stessi dati, occorre sapere come mantenere la coerenza.
- Quale risultato deve arrivare ai clienti entro il prossimo rilascio utile?
- Il bisogno è usare online tutto il prodotto esistente o offrire un percorso diverso a una parte degli utenti?
- Quali funzioni producono già valore e quali sono davvero diventate un limite?
- Quali clienti, dispositivi, periferiche e condizioni di connessione dobbiamo supportare?
- Dove si trovano dati e regole di business: codice, database, servizi, procedure manuali?
- Quali integrazioni e personalizzazioni non possiamo interrompere?
- Quali comportamenti sappiamo verificare oggi e quali dipendono dalla memoria delle persone?
- Chi gestirà identità, autorizzazioni, aggiornamenti, backup e assistenza nel nuovo assetto?
- Possiamo fare un esperimento su un cliente o su un flusso circoscritto prima di estendere la soluzione?
- Se il primo rilascio crea problemi, come torniamo alla versione precedente e che cosa accade ai dati creati nel frattempo?
Un esempio illustrativo: accesso web prima, migrazione dopo
Immaginiamo una software house con un gestionale verticale desktop, clienti attivi e un team piccolo. I clienti chiedono di usarlo fuori ufficio; alcuni vogliono anche consultare lo stato delle pratiche da telefono. L'applicazione attuale gestisce bene le regole di calcolo, ma ha poche interfacce esterne.
La prima verifica potrebbe riguardare l'accesso remoto al prodotto così com'è per gli operatori che hanno bisogno di tutte le funzioni. In parallelo si studia una schermata web dedicata alla consultazione delle pratiche. Solo dopo si decide se il modulo pratiche merita una sostituzione progressiva. Non è una sequenza valida per ogni prodotto: se stampa locale, connessione instabile, vincoli di licenza o isolamento dei clienti rendono impraticabile il primo passo, cambia anche il percorso.
Martin Fowler descrive la modernizzazione graduale come un lavoro che parte dai risultati desiderati e individua confini nei quali intervenire. Il punto utile non è adottare un pattern per principio: è ottenere evidenza sufficiente per scegliere il primo passaggio e misurarne gli effetti.
La decisione utile produce un primo esperimento
Alla fine dell'analisi dovrebbe essere possibile scrivere una frase verificabile: «Entro il primo rilascio, un gruppo di utenti potrà eseguire questo flusso online; confronteremo risultato, tempi di risposta e problemi con la versione attuale». Si possono poi stimare lavoro, costi ricorrenti e rischi delle strade rimaste aperte. Se la soluzione scelta non supera la prova, si aggiorna la roadmap prima di impegnare l'intero prodotto.
Il Legacy Assessment di MadeInCode serve a fare proprio questo: ricostruire architettura e vincoli, confrontare opzioni praticabili e definire un primo intervento verificabile. Il nostro metodo porta dall'analisi a un cambiamento controllato.