Nel lessico della Pubblica Amministrazione, web archiving spesso significa “conservare una copia” (snapshot, export HTML, PDF, Wayback, ecc.).
Ma cosa succede quando il sito che vuoi archiviare non è staticizzabile, è basato su uno stack obsoleto (PHP/MySQL datati, framework legacy) e, soprattutto, è stato dismesso per ragioni di sicurezza?

In questo articolo racconto una sperimentazione pratica: abbiamo recuperato e rimesso in funzione un sito legacy attraverso un processo di reingegnerizzazione guidata da IA (in particolare Codex), con supervisione tecnica, aggiornando runtime e database e affrontando le principali criticità di sicurezza. Il risultato: un servizio nuovamente fruibile, con costi e tempi drasticamente ridotti rispetto a una reingegnerizzazione “tradizionale” da fornitore esterno.

Il problema: archiviare non basta, quando il sito è un’applicazione

Il caso era quello tipico (e sempre più frequente) dei siti nati come applicazioni web:

• codice storico (circa 2014) con stile PHP 4/5;
• dipendenze e framework legacy (es. PRADO 3.1.x, librerie JS datate);
• accesso al DB tramite API mysql_* e pattern non più compatibili con PHP moderno;
• autenticazione e sessioni con impostazioni non adeguate agli standard attuali;
• superficie di attacco incompatibile con un’esposizione pubblica ragionevole.

In questo contesto, “fare una copia statica” non è realistico: alcune parti dipendono dal database e dal comportamento applicativo (ricerche, indici, paginazione, rendering dinamico, provider OAI, ecc.). La conservazione “passiva” diventa insufficiente: serve un web archiving capace di preservare l’esperienza d’uso, non solo l’aspetto.

L’analisi del repository mostrava almeno tre macro-componenti (backend, frontend PRADO e provider OAI-PMH) e una configurazione web storica con rewrite e aree protette.

La leva: Codex come acceleratore di reingegnerizzazione (non come “pilota automatico”)

La sperimentazione è stata impostata con un principio chiaro: IA come motore di lavoro, tecnico come supervisore.

Codex (e più in generale un LLM orientato al coding) è stato usato per:

• leggere e interpretare la codebase legacy (struttura, entrypoint, routing, librerie, accesso al DB);
• produrre una mappa delle criticità (compatibilità PHP 8, query SQL, sessioni, upload, rischi);
• proporre patch incrementalmente verificabili;
• accompagnare la creazione di un ambiente riproducibile (Docker) per test e regressione.

Questo approccio è sintetizzato anche nei materiali di progetto come flusso “analisi → piano → migrazione incrementale → hardening → rilascio”, con una checklist operativa pensata apposta per lavorare con Codex in modo controllato.

Il processo: dalla “teca” al servizio riattivato

1) Congelare e capire: fotografia tecnica del legacy

Prima regola: niente magia. Il primo passo è stato fotografare il sistema:

• componenti applicative (backend, frontend, OAI);
• dipendenze e librerie legacy;
• modalità di accesso al DB e schema (dump MySQL storico, prevalenza MyISAM, charset utf8);
• punti critici per la migrazione (short tags, import_request_variables, mysql_*, hashing md5).

Questa fase serve a evitare l’errore classico: “aggiorniamo PHP e vediamo cosa succede”. Qui invece si costruisce una lista di hotspot e una strategia incrementale.

2) Ambiente moderno e riproducibile: Docker come base di lavoro

Per riattivare un servizio in modo controllato, l’ambiente riproducibile è fondamentale: consente test, rollback, comparazioni e, soprattutto, ripetibilità (chiave anche per un archivio digitale “vivo”).

La piattaforma è stata portata su runtime moderno PHP 8.3 e DB MySQL 8, in container dedicati.

3) Compatibilità: far ripartire senza tradire il comportamento

Il primo obiettivo non è “riscrivere bene”, ma tornare a servire pagine senza errori bloccanti:

• fix di compatibilità PHP 8 (fatal dovuti a sintassi e assunzioni legacy);
• stabilizzazione di pagine e flussi con problemi tipici (paginazione, callback PRADO, rendering componenti);
• ripristino funzionale di link, risorse statiche, immagini e allegati.

Questa fase è stata gestita in modalità incrementale, con verifiche (lint, smoke test, controlli su pagine campione).

4) Sicurezza: dal “non pubblicabile” a “pubblicabile con mitigazioni”

Qui la parola chiave è riduzione del rischio, non perfezione istantanea.

Sono state applicate misure infrastrutturali e applicative:

• hardening PHP/Apache (riduzione leakage, session cookies più robusti, header di sicurezza);
• protezione directory upload (mitigazione classica upload-to-RCE);
• rimozione esposizione DB verso l’esterno in profilo “prod”;
• avvio (e progressione) dell’hardening anti-SQL injection sui flussi più esposti, passando dove possibile a query parametrizzate.

Il risultato della valutazione: stato buono con mitigazioni operative, e possibilità di esposizione pubblica a condizioni precise (TLS frontale, segreti robusti, monitoring, patch management, prosecuzione remediation).

5) Verso “versione completa”: qualità minima misurabile

Quando si lavora su archiviazione/riattivazione, serve anche una definizione “operativa” di qualità.

Nel rilascio “versione completa” sono riportate evidenze oggettive come:

• lint globale PASS su centinaia di file;
• regressione statica PASS;
• isolamento moduli, autoload moderno e layer di compatibilità per il residuo legacy.

Questo è un punto importante: non è “una demo che gira”, ma una base che regge un ciclo di manutenzione.

Perché questo è web archiving (e non solo “migrazione”)

La sperimentazione suggerisce un cambio di paradigma:

• Archiviazione passiva: conservo un’istantanea (utile, ma spesso non navigabile davvero).
• Archiviazione attiva: preservo la fruizione del servizio, portandolo su un runtime sicuro e sostenibile.

Nel caso specifico, il sito non era staticizzabile: la reingegnerizzazione è diventata condizione necessaria per l’archivio. E l’IA ha reso questa strada praticabile in tempi e costi normalmente fuori scala per un team interno.

Impatto economico: 30k vs 6–8 ore (e cosa significa per la PA)

Qui sta il punto più “politico” (in senso buono) della sperimentazione.

Per una re-realizzazione ex novo era stata stimata una fornitura esterna intorno ai 30.000 €. Con l’approccio IA+supervisione tecnica, l’intervento è stato portato a termine con risorse interne e in un ordine di grandezza di 6–8 ore di lavoro, concentrando lo sforzo su:

• comprensione rapida del legacy;
• patch mirate guidate da analisi assistita;
• setup riproducibile e verifiche minime;
• hardening essenziale per ridurre rischio e sbloccare la pubblicazione.

Il valore per la PA non è solo “risparmio”: è autonomia operativa, capacità di intervento rapido e creazione di un metodo riutilizzabile su altri casi.

Cosa rende replicabile il metodo

Senza entrare in dettagli eccessivi, questi sono gli ingredienti che hanno fatto la differenza:

• Prompting disciplinato (niente supposizioni: ogni affermazione deve essere collegata a evidenze nel repo)
• Strategia incrementale: prima far ripartire, poi ridurre il rischio, poi migliorare architettura e qualità
• Ambiente riproducibile (Docker) come “laboratorio” e poi base per il deploy
• Verifiche minime ma concrete (lint, smoke test, regressioni statiche)
• Sicurezza trattata come backlog vivo: hardening subito sulle aree esposte, poi remediation progressiva

Limiti (da dichiarare, perché contano)

Un approccio del genere funziona proprio perché resta onesto sui limiti:

• un hardening mirato non equivale a un penetration test completo;
• in una codebase ampia e storica, una quota residua di legacy resta e va governata (non negata);
• l’IA accelera moltissimo, ma serve supervisione: scelte architetturali e valutazioni di rischio restano responsabilità tecnica.

Detto in modo semplice: Codex non sostituisce il tecnico, lo potenzia.

Due evoluzioni sperimentali con l’IA: staticizzazione “intelligente” e archiviazione dei dati su Zenodo

Oltre alla versione aggiornata e funzionante del portale in ambiente Docker, abbiamo sperimentato due ulteriori direzioni di lavoro guidate dall’IA.
La prima è stata la creazione di una versione staticizzata che mantenesse però una navigazione per indici, gestita tramite JavaScript
semplice: l’IA ha supportato la trasformazione e la ricostruzione delle pagine, e la sperimentazione ha prodotto una versione statica con navigazione
funzionante. Tuttavia, rispetto alla riattivazione su stack moderno, questa strada ha richiesto una revisione molto più puntuale da parte
dell’operatore: l’assenza del “motore” applicativo rende infatti più delicata la verifica di coerenza dei contenuti, delle relazioni e dei percorsi di
navigazione. Il risultato è stato raggiunto, ma con un investimento di tempo maggiore rispetto alla versione aggiornata e nuovamente operativa.

La seconda direzione, particolarmente interessante, è stata quella di astrarre il database del portale e conservarlo pubblicandolo su
Zenodo, archiviando così i dati della ricerca in modo indipendente dall’interfaccia web. L’obiettivo è duplice: preservare e rendere disponibili i
dati ai ricercatori e consentire loro di accedervi con la tecnologia che preferiscono (non necessariamente tramite la vecchia applicazione web).
Questo lavoro, supportato dall’IA, è stato molto più veloce ed è in corso di approfondimento. Un ulteriore passo (attualmente in sviluppo) è la
sperimentazione di un chatbot che, interrogando i dati archiviati su Zenodo, possa rispondere direttamente alle domande dei ricercatori.

Conclusione: verso un “web archiving sostenibile” con IA

Questa esperienza mostra una possibilità concreta: usare l’IA per trasformare il recupero di siti legacy da problema ingestibile a
procedura ripetibile, con tempi e risorse compatibili con un lavoro interno.

Per molti enti pubblici, il web archiving non è solo memoria: è continuità del servizio, tutela del patrimonio informativo e riduzione del rischio.
Se l’archivio deve restare consultabile e “vivo”, la reingegnerizzazione diventa parte integrante dell’archiviazione.

L’elemento abilitante è l’IA, ma il fattore decisivo è il metodo: supervisione tecnica, incrementalità, ambiente riproducibile e hardening
progressivo. In questo modo il recupero non diventa un progetto “monstre”, ma un intervento sostenibile e governabile.

Se vuoi maggiori dettagli sulle sperimentazioni (approccio, strumenti, livelli di hardening, criteri di validazione e possibili varianti per casi
simili nella PA), contattami: posso condividere informazioni operative e una traccia metodologica replicabile, compatibilmente con i vincoli di
sicurezza e riservatezza del progetto.

—
Iscriviti alla mailing list

Per rimanere aggiornato  iscriviti alla mailing list