Subentrare senza sviluppatore: cosa fare quando resti senza manutentore su una base di codice PHP legacy

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 trovi l'esperienza concreta su subentri d'emergenza, stabilizzazione e modernizzazione di applicazioni PHP. Contattami per una consulenza diretta.

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 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.

# 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:

# 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 è il primo intervento strutturale - da deployment FTP a codice versionato con rollback possibile. L'audit tecnico iniziale 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 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 - 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 e stabiliamo le priorità per il tuo caso specifico.