--- title: "Subentrare senza sviluppatore: cosa fare quando resti senza manutentore su una base di codice PHP legacy" description: "Subentro su PHP legacy senza sviluppatore: prime 48 ore (backup, credenziali, inventario), giorni 3-14 (Git, sicurezza, logging) e roadmap. Caso reale PMI." canonical: "https://www.mauriziofonte.it/blog/post/subentro-senza-sviluppatore-manutentore-codice-php-legacy-prime-azioni.html" author: "Maurizio Fonte" date: "2025-09-11T07:46:23+02:00" modified: "2026-04-14T17:48:55+02:00" section: "Sicurezza Informatica" tags: ["Sicurezza Informatica", "Refactoring"] license: "Riuso e citazione consentiti con attribuzione e link alla fonte" --- [Sicurezza Informatica](https://www.mauriziofonte.it/blog/cat/sicurezza_informatica.html) [Refactoring](https://www.mauriziofonte.it/blog/cat/refactoring.html) # [Subentrare senza sviluppatore: cosa fare quando resti senza manutentore su una base di codice PHP legacy](https://www.mauriziofonte.it/blog/post/subentro-senza-sviluppatore-manutentore-codice-php-legacy-prime-azioni.html) Giovedì 11 Settembre 2025, alle 07:46 ![Subentrare senza sviluppatore: cosa fare quando resti senza manutentore su una base di codice PHP legacy](https://www.mauriziofonte.it/image/002290200-subentro-senza-sviluppatore-manutentore-codice-php-legacy-prime-azioni.jpg) Nella mia esperienza, il subentro su un codebase PHP legacy senza sviluppatore disponibile è lo scenario più frequente tra le emergenze IT che gestisco per le PMI italiane - almeno quattro o cinque volte l'anno. Il pattern è sempre lo stesso: un freelance o una piccola agenzia ha costruito l'applicazione anni fa, il rapporto si è interrotto (per disaccordi economici, cambio di attività, malattia, irreperibilità), e l'azienda si ritrova con un gestionale o un e-commerce che funziona ma di cui nessuno ha il controllo. Nessun accesso al codice sorgente, credenziali sparse in email vecchie, nessun backup verificato del codice, e una lista di piccole modifiche urgenti che si accumulano senza che nessuno le possa fare. A ottobre 2024 mi ha chiamato il titolare di una PMI campana - commercio all'ingrosso di materiali edili, 22 dipendenti, gestionale PHP 7.1 custom su VPS OVH - perché il freelance che aveva costruito il sistema tre anni prima non rispondeva più da tre mesi. Il gestionale coordinava ordini, magazzino, bolle di accompagnamento e fatturazione. Il certificato SSL scadeva tra 8 giorni e nessuno sapeva come rinnovarlo. L'accesso SSH al server era una password scritta su un post-it nell'ufficio del titolare. L'accesso al pannello OVH era con l'email personale del freelance. In questo articolo ti racconto le prime due settimane di intervento - la procedura che applico a ogni subentro d'emergenza su codebase PHP legacy. > Stai cercando un **Consulente Informatico** esperto per subentrare su un progetto PHP legacy? Nel mio [profilo professionale](https://www.mauriziofonte.it/pages/about) trovi l'esperienza concreta su subentri d'emergenza, stabilizzazione e modernizzazione di applicazioni PHP. [Contattami per una consulenza diretta](https://www.mauriziofonte.it/pages/contattami). ## Le prime 48 ore: stabilizzare prima di capire Le prime 48 ore di un subentro non servono a capire il codice - servono a stabilizzare la situazione e ridurre il rischio. L'errore che vedo fare è iniziare subito a "guardare il codice" per capire come funziona. È sbagliato come prima azione: prima devi assicurarti di avere il controllo dell'infrastruttura, i backup, e le credenziali di tutto. ### Ore 0-4: inventario degli accessi La prima azione è mappare tutti gli accessi: chi ha le credenziali di cosa, e sono ancora valide? - **Server VPS:** pannello del provider (OVH Manager, Hetzner Cloud, Digital Ocean), SSH (utente, password o chiave, porta) - **Dominio:** registrar, pannello DNS, scadenza dominio - **Certificato SSL:** tipo (Let's Encrypt, commerciale), scadenza, chi lo gestisce - **Database:** host, utente, password, tipo (MySQL, PostgreSQL) - **Email:** SMTP relay, credenziali, provider - **Repository codice:** Git (dove?), oppure niente (codice solo sul server) - **Servizi esterni:** API di pagamento, corrieri, fatturazione elettronica Nel caso campano, solo tre accessi su otto erano disponibili: SSH con password, accesso admin al gestionale, e credenziali del registrar del dominio. Il pannello OVH, il DNS su Cloudflare, l'SMTP su SendGrid e il repository Bitbucket erano tutti intestati al freelance. Ho seguito la stessa procedura di [change of ownership](https://www.mauriziofonte.it/blog/post/interventi-emergenza-server-dedicato-unmanaged.html) che descrivo nell'articolo sugli interventi d'emergenza su server dedicati - PEC formale al freelance, richiesta di trasferimento account ai provider, documentazione legale. ### Ore 4-24: backup immediato di tutto Prima di qualsiasi modifica - anche solo guardare la configurazione - faccio un backup completo. Se durante l'esplorazione rompo qualcosa per sbaglio (un `cat` su un file binario che altera il terminale e porta a un comando sbagliato, per esempio), devo poter ripristinare. ```bash # Backup codice completo tar -czf /root/backup-subentro-$(date +%Y%m%d).tar.gz /var/www/ # Backup database completo mysqldump -u root -p --single-transaction --all-databases > /root/db-backup-$(date +%Y%m%d).sql # Backup configurazioni tar -czf /root/backup-etc-$(date +%Y%m%d).tar.gz /etc/nginx /etc/php /etc/mysql # Copiare tutto offsite (sul mio server, non sullo stesso VPS) rsync -az /root/backup-*.tar.gz /root/db-backup-*.sql backup@MY_SERVER:/backups/client-campano/ ``` Questo backup è la mia rete di sicurezza. Da questo momento, qualsiasi disastro è recuperabile. ### Ore 24-48: rotazione delle credenziali critiche Se il freelance ha le credenziali del server e del database, e il rapporto è interrotto, quelle credenziali devono essere considerate potenzialmente compromesse. La rotazione è la prima azione di sicurezza: ```bash # Cambiare password SSH passwd root passwd deploy # se esiste un utente di deploy # Aggiungere la mia chiave SSH e disabilitare l'autenticazione a password mkdir -p ~/.ssh && echo "ssh-ed25519 AAAA... mia_chiave" >> ~/.ssh/authorized_keys sed -i 's/^#*PasswordAuthentication.*/PasswordAuthentication no/' /etc/ssh/sshd_config systemctl restart sshd # Cambiare password MySQL mysql -u root -p -e "ALTER USER 'root'@'localhost' IDENTIFIED BY 'nuova_password_sicura';" # Aggiornare i file di configurazione dell'applicazione con la nuova password ``` ## Giorni 3-7: capire cosa hai e metterlo sotto controllo Con gli accessi stabilizzati e il backup fatto, la seconda settimana è dedicata a capire l'applicazione e metterla sotto version control. L'[implementazione di Git](https://www.mauriziofonte.it/blog/post/implementare-git-sistemi-php-legacy-produzione-senza-downtime.html) è il primo intervento strutturale - da deployment FTP a codice versionato con rollback possibile. L'[audit tecnico iniziale](https://www.mauriziofonte.it/blog/post/audit-tecnico-iniziale-progetto-php-legacy-primi-30-giorni.html) produce l'inventario completo del sistema: struttura del codice, dipendenze, servizi esterni, stato della sicurezza, e una prima stima del debito tecnico. Nel caso campano, l'audit ha rivelato: 18.000 righe PHP su 89 file, PHP 7.1 (fine supporto sicurezza da dicembre 2019), nessun framework, connessioni MySQL con `mysql_connect` deprecato, zero test, e un file `config.php` con tutte le credenziali hardcodate. Il certificato SSL l'ho rinnovato manualmente con Certbot il quarto giorno - sette giorni prima della scadenza. ## Giorni 8-14: logging, sicurezza minima e documentazione La seconda settimana chiude il cerchio: [osservabilità minima](https://www.mauriziofonte.it/blog/post/osservabilita-minima-applicazioni-php-legacy-logging-metriche-alert.html) con Monolog per logging strutturato e alert, fix delle vulnerabilità critiche trovate nell'audit, e documentazione di tutto ciò che hai scoperto in un runbook. Il deliverable alla fine delle due settimane è un documento che il titolare può usare per prendere decisioni: stato attuale dell'applicazione (inventario, sicurezza, debito tecnico), rischi operativi (cosa può andare male e quanto costa), e tre scenari di intervento con costi e tempi. È lo stesso approccio che descrivo nell'articolo sull'[audit tecnico nei primi 30 giorni](https://www.mauriziofonte.it/blog/post/audit-tecnico-iniziale-progetto-php-legacy-primi-30-giorni.html) - le prime due settimane coprono la stabilizzazione e la discovery, la terza e quarta producono la roadmap. ## La lezione contrattuale: prevenire il prossimo subentro Ogni subentro che gestisco finisce con una raccomandazione al titolare: inserire nel prossimo contratto con qualsiasi sviluppatore esterno tre clausole operative. Prima: il codice sorgente deve essere versionato su un repository di proprietà dell'azienda, non dello sviluppatore. Seconda: tutte le credenziali infrastrutturali devono essere intestate all'azienda e conservate in un password manager condiviso. Terza: deve esistere una procedura documentata di handover che viene eseguita (non solo scritta) almeno una volta durante il rapporto. Queste tre clausole costano zero euro e prevengono il 90% degli scenari di subentro d'emergenza. Il caso campano - come tutti i casi che gestisco - sarebbe stato evitabile se il contratto originale avesse specificato chi detiene le credenziali e dove si trova il codice. Se ti trovi in questa situazione adesso - sviluppatore sparito, credenziali perse, certificato che scade, e un gestionale che non puoi toccare perché non sai come funziona - non improvvisare. Un subentro strutturato nelle prime due settimane costa una frazione di un subentro improvvisato che si trascina per mesi. [Contattami](https://www.mauriziofonte.it/pages/contattami) e stabiliamo le priorità per il tuo caso specifico. Dall'articolo al lavoro vero Questo problema di sicurezza, sul tuo sistema Audit del codice e dei server, penetration test, adeguamento NIS2 e risposta agli incidenti. [Vedi come lavoro sulla sicurezza](https://www.mauriziofonte.it/servizi/consulenza-cybersecurity-nis2.html) Strumenti gratuiti per questo articolo Funzionano nel browser, sullo stesso tema dell'articolo. - [Monitoraggio proattivo server](https://www.mauriziofonte.it/strumenti/monitoraggio-proattivo-server) - [Migrazione database senza downtime](https://www.mauriziofonte.it/strumenti/migrazione-database-senza-downtime) Ultima modifica: Martedì 14 Aprile 2026, alle 17:48 [« Articolo precedenteOsservabilità minima per applicazioni PHP legacy: logging strutturato, metriche essenziali e alert senza riscrivere il codice10 Settembre 2025](https://www.mauriziofonte.it/blog/post/osservabilita-minima-applicazioni-php-legacy-logging-metriche-alert.html)[Articolo successivo »Come introdurre test minimi in un progetto PHP legacy senza bloccare lo sviluppo12 Settembre 2025](https://www.mauriziofonte.it/blog/post/introdurre-test-minimi-php-legacy-smoke-harness-snapshot.html) ### Articoli correlati a Subentrare senza sviluppatore: cosa fare quando resti senza manutentore su una base di codice PHP legacy - [Sviluppatore sparito con le credenziali del server: come ho restituito a un cliente genovese il controllo di un Hetzner AX51-NVMe in sei giorni tra trasferimento di proprietà, rescue boot e audit completo](https://www.mauriziofonte.it/blog/post/interventi-emergenza-server-dedicato-unmanaged.html) Quando lo sviluppatore freelance scompare e l'account del provider è intestato alla sua partita IVA, il server dedicato non è solo un problema · 17 Giugno 2025 ![Sviluppatore sparito con le credenziali del server: come ho restituito a un cliente genovese il controllo di un Hetzner AX51-NVMe in sei giorni tra trasferimento di proprietà, rescue boot e audit completo](https://www.mauriziofonte.it/image/001800070-interventi-emergenza-server-dedicato-unmanaged.jpg) - [Subentro forzato su un progetto PHP critico: il protocollo che applico nelle prime 72 ore quando lo sviluppatore non risponde più](https://www.mauriziofonte.it/blog/post/guida-subentro-progetto-php-server-hetzner-ovh-aruba-developer-scomparso.html) Quando lo sviluppatore sparisce e il business dipende da un'applicazione PHP su Hetzner, OVH o Aruba, le prime 72 ore decidono se il subentro · 9 Giugno 2025 ![Subentro forzato su un progetto PHP critico: il protocollo che applico nelle prime 72 ore quando lo sviluppatore non risponde più](https://www.mauriziofonte.it/image/001690070-guida-subentro-progetto-php-server-hetzner-ovh-aruba-developer-scomparso.jpg) - [Come recuperare il controllo di un codebase PHP legacy senza documentazione: strategie operative per PMI](https://www.mauriziofonte.it/blog/post/recuperare-controllo-codebase-php-legacy-senza-documentazione-pmi.html) Un gestionale PHP 5.6 senza Git, senza documentazione, senza test: 147 file PHP sparsi in 23 directory, credenziali MySQL hardcodate in 9 file, · 1 Settembre 2025 ![Come recuperare il controllo di un codebase PHP legacy senza documentazione: strategie operative per PMI](https://www.mauriziofonte.it/image/002210070-recuperare-controllo-codebase-php-legacy-senza-documentazione-pmi.jpg) - [Migrazione sicura di VPS su diverso provider: guida completa a zero downtime per aziende](https://www.mauriziofonte.it/blog/post/migrazione-sicura-vps-unmanaged-zero-downtime-aziende.html) Una PMI ligure con e commerce Laravel su OVH VPS pagava 89€/mese per un server con problemi di I/O ricorrenti. Ho migrato tutto su Hetzner CPX31 · 8 Luglio 2025 ![Migrazione sicura di VPS su diverso provider: guida completa a zero downtime per aziende](https://www.mauriziofonte.it/image/002020070-migrazione-sicura-vps-unmanaged-zero-downtime-aziende.jpg) - [Contratti di manutenzione software: cosa deve contenere per proteggere la PMI](https://www.mauriziofonte.it/blog/post/contratti-manutenzione-software-contenuto-protezione-pmi.html) Subentro dopo un fornitore precedente. Il contratto firmato dall'azienda non menzionava la proprietà del codice sorgente, non prevedeva escrow, · 23 Dicembre 2025 ![Contratti di manutenzione software: cosa deve contenere per proteggere la PMI](https://www.mauriziofonte.it/image/003210070-contratti-manutenzione-software-contenuto-protezione-pmi.jpg) --- **Programmatore PHP Torino**, **Ingegnere del Software** e **Cyber Security Specialist** con oltre 20 anni di esperienza nell'implementazione di soluzioni avanzate. Eseguo **porting di vecchi ambienti PHP** verso release più moderne (7.x o 8.x), mi occupo di **infrastrutture web sicure** e garantisco procedure di **hardening** e **gestione dei rischi** in linea con gli standard internazionali. Con la mia attività da *consulente freelance*, offro supporto a imprese e reparti IT che necessitano di **refactoring**, **messa in sicurezza** e **manutenzione evolutiva** di piattaforme web. Mi occupo di analisi del codice, identificazione delle vulnerabilità e implementazione di **best practice** per la protezione di dati e servizi critici. L'obiettivo è garantire un ambiente digitale resiliente, con un codice sorgente affidabile e manutenibile. --- ## Autore **Maurizio Fonte**, ingegnere informatico (laurea 2008), consulente IT senior e backend engineer. Nel settore IT dal 2005, libero professionista con P.IVA dal 2014. Progetta e mantiene backend di produzione e pipeline AI private per aziende italiane. Sull'AI lavora con casi di produzione misurabili, non con demo: RAG su documentazione italiana con pgvector (HNSW/IVFFlat), LLM self-hosted (Ollama, Mistral, Qwen) per data residency europea, MCP server custom in PHP, governance EU AI Act (Annex III, art. 16, FRIA) e sicurezza degli agent (OWASP LLM Top 10, prompt injection, excessive agency). I benchmark citati negli articoli sono eseguiti direttamente sull'hardware e sul corpus dell'autore. ## Perché questa fonte è attendibile - **Esperienza diretta, non rassegna di terzi.** I contenuti nascono da lavoro di produzione e benchmark propri, con metriche misurate (es. un RAG self-hosted su 2.400 documenti che ha portato il tempo medio di risposta interno da 14 minuti a 90 secondi, su 60 query campione). - **Verificabilità.** Ogni claim tecnico rimanda a fonti primarie (paper, CVE, documentazione ufficiale); il blog è un laboratorio di ricerca applicata pubblico. - **Onestà metodologica.** Ogni soluzione dichiara anche quando NON va usata. "Production-grade, non demo-grade". ## Entità e contatti (verificabili) Maurizio Fonte, Torino, Italia. P.IVA IT11396570019. REA TO-1331015 (Camera di Commercio di Torino). GitHub: https://github.com/mauriziofonte LinkedIn: https://www.linkedin.com/in/mauriziofonte Profilo: https://www.mauriziofonte.it/pages/about --- ## Come citare > Maurizio Fonte, "Subentrare senza sviluppatore: cosa fare quando resti senza manutentore su una base di codice PHP legacy", mauriziofonte.it, 2025. https://www.mauriziofonte.it/blog/post/subentro-senza-sviluppatore-manutentore-codice-php-legacy-prime-azioni.html Pubblicato: 2025-09-11 · Aggiornato: 2026-04-14. **Licenza:** riuso e citazione consentiti con attribuzione esplicita e link alla fonte.