Come abbiamo costruito ISPCore, il gestionale per chi è rimasto bloccato nel software vecchio di 15 anni

L’archeologia del database

La prima volta che ho aperto il database di Marco l’ho fatto da remoto, alle nove di sera di un giovedì, perché lui aveva detto “non posso mai durante il giorno, abbiamo clienti che chiamano”.

Marco gestisce un Internet Service Provider in una regione del nord Italia. Mille e ottocento clienti tra residenziali e aziende, copertura wireless su tre province, un POP in colocation e due uplink ridondati. Nel suo settore non è grande, ma non è piccolo: è la fascia che in Italia conta qualche centinaio di realtà identiche.

Il suo gestionale era stato scritto nel 2012 da una software house veneta che oggi non esiste più. .NET Framework 4.0, MySQL 5.5, una macchina virtuale Windows Server 2012 R2 che girava su un hypervisor ESXi vecchio quanto il software. Funzionava. Aveva sempre funzionato. Il problema era che adesso aveva smesso di generare FatturaPA conformi alle ultime specifiche dell’Agenzia delle Entrate.

«Costava quattromila euro all’anno il consulente che lo manteneva», mi ha detto Marco. «Adesso vuole quindicimila perché dice che deve riscrivere mezza libreria. E nessuno garantisce che funzionerà.»

Ho passato due settimane a leggere quel database prima di scrivere una sola riga di codice nuovo. Era una decisione contro-intuitiva. Il committente paga il software, non l’archeologia. Ma quel database era la chiave di tutto.

Il problema vero del mercato ISP italiano

In Italia ci sono circa 800 ISP attivi tra wireless, FTTH locali e operatori regionali. La maggioranza ha tra i 500 e i 5.000 clienti. Sono aziende che fatturano tra mezzo milione e dieci milioni di euro l’anno, gestite da imprenditori tecnici, con due o tre dipendenti operativi e un commercialista esterno.

Il mercato dei gestionali per loro è polarizzato in modo strano.

Sopra ci sono i prodotti enterprise — sviluppati per Vodafone, Fastweb, WindTre — che costano centinaia di migliaia di euro l’anno e richiedono team dedicati. Per un ISP da 2.000 clienti sono fuori scala.

Sotto ci sono i gestionali generalisti — i vari “tutto per la tua azienda” — che vanno bene per parrucchieri e officine ma non sanno cosa sia un RADIUS server, non gestiscono provisioning di link wireless, non hanno integrazioni con FatturaPA pensate per il settore telco.

In mezzo c’è il deserto. E lì si trovano gestionali costruiti dieci o quindici anni fa da software house piccole, ognuno verticale su una nicchia, ognuno mantenuto — o non mantenuto — da uno o due sviluppatori. Sono prodotti che hanno funzionato bene per anni, perché il mercato cambia lentamente, ma adesso stanno arrivando al capolinea per tre motivi:

1. FatturaPA evolve. Le specifiche tecniche dell’Agenzia delle Entrate cambiano ogni 18-24 mesi. Ogni cambio richiede aggiornamenti, e ogni aggiornamento richiede chi sa scrivere C# vecchio.
2. GDPR, NIS2, AGCOM. Le richieste di compliance aumentano. I gestionali del 2012 non avevano nemmeno il concetto di “consenso granulare” o “audit trail”.
3. Gli sviluppatori originali sono scomparsi. Software house chiuse, fondatori in pensione, repository perse. Restano consulenti esterni che fatturano a ore per mantenere in vita codice che nessuno ha più voglia di toccare.

Il risultato è che centinaia di ISP italiani oggi stanno pagando dai 10.000 ai 30.000 euro l’anno per tenere in vita software che andrebbero archiviati.

La trappola del “ricostruisco tutto da zero”

La risposta ingenua a questo problema è: ricostruisco il gestionale, moderno, cloud, microservizi, tutta la fuffa.

Non funziona. L’ho visto provare almeno tre volte negli ultimi due anni, sempre con lo stesso esito.

Il punto è che l’ISP non ha bisogno di un gestionale nuovo in astratto. Ha bisogno di passare dal suo gestionale attuale a uno nuovo senza perdere quindici anni di storico. Senza riscrivere a mano migliaia di anagrafiche. Senza dover spiegare alle agenzie fiscali perché manca la fattura del 2017.

E qui la maggior parte dei progetti muore. Si costruisce il gestionale nuovo — bello, moderno, performante. Poi arriva il momento della migrazione e ci si accorge che:

• La numerazione delle fatture non corrisponde
• I codici tributo sono in un campo di testo libero, non strutturato
• I contratti hanno date di inizio in formati misti (dd/MM/yyyy, timestamp Unix, stringhe in italiano tipo “primo gennaio duemilasedici”)
• Le anagrafiche hanno duplicati con varianti ortografiche
• I provisioning RADIUS sono salvati in una tabella che si chiama appoggio_temp_NON_TOCCARE_2018

A quel punto il progetto entra in stallo. Il cliente non vuole pagare due volte. Il fornitore non vuole farsi sei mesi di lavoro non preventivati. Si fa una “migrazione parziale” che diventa permanente, e dopo un anno il cliente ha due sistemi in piedi invece di uno.

La scelta architetturale di ISPCore

Quando ho disegnato ISPCore ho fatto una scelta che a chi viene dal mondo SaaS moderno sembra sbagliata: ho costruito un monolite modulare, non microservizi. E ho costruito Docker per-client — un’istanza per ogni ISP, non un sistema multi-tenant condiviso.

Le ragioni sono tre.

Prima ragione: l’isolamento dei dati è un requisito non negoziabile. Gli ISP gestiscono dati personali e di traffico che ricadono sotto AGCOM e privacy. Avere il database di un cliente nello stesso schema di un altro è un rischio operativo che nessun ISP serio accetta.

Seconda ragione: la migrazione è più semplice quando lo schema è dedicato. Importare 15 anni di storico in uno schema dedicato richiede ore. Importarlo in un sistema multi-tenant condiviso richiede settimane di refactoring per evitare conflitti.

Terza ragione: il monolite si aggiorna più velocemente. Un fix per il calcolo IVA su sub-fornitura wholesale è una pull request di 20 righe. In un sistema a microservizi sarebbe una catena di chiamate API tra tre servizi diversi, ognuno con il suo deploy.

ISPCore gira così:

Cliente ISP A → istanza Docker dedicata → PostgreSQL schema-per-tenant interno
Cliente ISP B → istanza Docker dedicata → PostgreSQL schema-per-tenant interno
Cliente ISP C → istanza Docker dedicata → PostgreSQL schema-per-tenant interno

Ogni istanza contiene tutti i moduli — anagrafica, billing, RADIUS, ticket, NOC, FatturaPA — ma serve solo quel cliente. Il codice è uno, gli ambienti sono separati.

Lo stack è volutamente minimale: Bun come runtime (avvio in millisecondi, performance native sui workload sincroni del billing), Hono come framework HTTP (5× più veloce di Express, type-safe), PostgreSQL 15 per la persistenza, Docker Compose per deploy on-premise o su Hetzner.

Niente Kubernetes, niente service mesh, niente API gateway. Un ISP da 2.000 clienti non genera mai abbastanza traffico per giustificare quella complessità.

La parte che cambia tutto: la pipeline di import

Il pezzo di codice di cui sono più orgoglioso non è il modulo FatturaPA. È la cartella imports/ di ISPCore.

Contiene parser dedicati per i gestionali legacy più diffusi nel mercato ISP italiano. Per ogni famiglia di software vecchio c’è uno script che:

1. Si connette al database originale (MySQL, SQL Server, anche Access in alcuni casi)
2. Mappa le tabelle storiche su uno schema intermedio normalizzato
3. Riconosce e risolve i pattern di sporcizia tipici (date in formati misti, codici fiscali con spazi, partite IVA salvate come float, duplicati con varianti ortografiche)
4. Genera un report di quality assurance prima dell’import (cosa è stato mappato, cosa è ambiguo, cosa va deciso manualmente)
5. Importa tutto in ISPCore mantenendo la numerazione progressiva delle fatture per continuità fiscale

Per Marco la migrazione è durata 11 giorni: tre di analisi, due di scrittura del parser specifico, due di import e test paralleli — il vecchio sistema rimane in piedi finché il nuovo non ha generato un ciclo di fatturazione completo — quattro di formazione e tuning.

Costo totale: meno di un terzo del preventivo annuale del consulente del vecchio sistema.

La lezione che vale per tutto il mercato italiano

Quando ho cominciato a costruire ISPCore mi aspettavo che la parte difficile fosse il codice. È stata la parte facile.

La parte difficile è stato capire che il mercato italiano delle PMI tecniche non chiede innovazione astratta. Chiede continuità. Chiede di passare dal vecchio al nuovo senza traumi e senza buchi nel pregresso.

Questo vale per gli ISP. Vale per i CRM degli studi commercialisti. Vale per i gestionali delle officine, per i sistemi di magazzino dei piccoli distributori, per le piattaforme di prenotazione dei centri estetici.

In Italia ci sono migliaia di piccole imprese tecniche che pagano costi crescenti per mantenere software costruiti 10-15 anni fa. Il problema non è che il software sia diventato cattivo. È che il mercato di chi lo sa mantenere si è prosciugato.

La domanda commerciale interessante in Italia oggi, almeno nel B2B sotto i 10 milioni di fatturato, non è “come costruisco la cosa nuova migliore”. È “come porto fuori dalla cosa vecchia chi non riesce più a uscirne”.

Chi sa fare quel passaggio bene avrà clienti per i prossimi vent’anni.