Ogni applicazione PHP legacy arriva allo stesso punto. Il codice ha dieci anni, nessuno vuole toccare il modulo ordini, il framework non riceve aggiornamenti dal 2019 e qualcuno propone una riscrittura. Diciotto mesi, dicono. Congelamento delle funzionalità nel frattempo.
Quel progetto ha un tasso di fallimento ben documentato, sempre per lo stesso motivo: l’azienda non può fermarsi per diciotto mesi, quindi si continuano a fare modifiche sul vecchio sistema, il nuovo resta indietro e la migrazione diventa un bersaglio mobile. Dopo due anni ci si ritrova con due sistemi, di cui uno incompleto.
Il pattern strangler fig evita questo scenario perché non prevede mai un taglio netto. Le nuove funzionalità si sviluppano in Laravel, quelle esistenti si migrano una rotta alla volta, e il traffico viene instradato verso il sistema che gestisce ciascun percorso. L’applicazione legacy si riduce fino a scomparire.
Contesto sulle versioni: Laravel 13 è uscito a marzo 2026 senza breaking change rispetto alla 12 e con un requisito minimo di PHP 8.3. Per un progetto di migrazione questo conta — il framework verso cui si sta migrando è insolitamente stabile in questo momento, e il requisito di versione di PHP è spesso il vero ostacolo.
Il confine del routing
Tutto dipende dalla possibilità di inviare una richiesta a entrambe le applicazioni senza che l’utente se ne accorga. Si posiziona un reverse proxy davanti a entrambe e si instrada in base al percorso.
- Imposti tutto di default sull’applicazione legacy il primo giorno, così il proxy non modifica nulla e può essere distribuito indipendentemente dalla migrazione.
- Sposta una rotta alla volta aggiungendola all’elenco Laravel del proxy. Questa diventa la sua modalità di migrazione, e si tratta di una modifica di configurazione.
- Mantenga il rollback banale. Riportare una rotta sul legacy deve essere solo una modifica di configurazione e un reload, non un deploy. Le servirà.
- Non instradi su criteri complessi. I prefissi di percorso bastano. Instradare per segmento utente o feature flag sembra utile ma raddoppia gli stati da gestire.
Questa singola infrastruttura trasforma una scommessa da diciotto mesi in una serie di decisioni settimanali.
Sessioni e autenticazione: risolvere prima questo aspetto
Il primo vero ostacolo, quello che blocca le migrazioni che lo trascurano. Un utente deve poter accedere da una pagina legacy e restare autenticato quando la richiesta successiva arriva su Laravel.
- Sposti la sessione dove entrambe le applicazioni possano leggerla — Redis o il database — prima di migrare qualsiasi rotta.
- Concordi un formato di serializzazione. Due applicazioni PHP con framework diversi non serializzano necessariamente la sessione allo stesso modo. Verifichi esplicitamente, non dia per scontato.
- Condivida dominio e percorso del cookie e allinei il nome del cookie.
- Affidi l’autenticazione a un solo sistema. Di solito Laravel, una volta migrata la rotta di login, con l’applicazione legacy che legge la sessione senza scriverla.
- Verifichi scadenza e rigenerazione della sessione tra i due sistemi. Se si esce da uno e si resta autenticati sull’altro, è un bug di sicurezza, non una semplice scomodità.
Se deve risparmiare tempo, non lo faccia qui. Un bridge di sessione che funziona al 99% genera logout intermittenti e non riproducibili che assorbiranno più tempo di ingegneria del resto della migrazione.
Il confine del database
La risposta pragmatica per la maggior parte delle migrazioni: entrambe le applicazioni condividono un unico database e non si tenta di ridisegnare lo schema durante la migrazione.
Questo può risultare sgradito, ed è comprensibile. Migrare codice e schema contemporaneamente significa che ogni problema può avere due cause possibili e impedisce di spostare una singola route in modo indipendente. Si passi prima a Laravel; si migliori lo schema in seguito, quando si dispone di una sola codebase e si può intervenire con sicurezza.
- Mappi lo schema legacy con i modelli Eloquent così com'è, inclusi i nomi delle tabelle che non sceglierebbe mai.
- Scriva sulle stesse tabelle, così entrambi i sistemi vedono gli stessi dati senza uno strato di sincronizzazione che può creare problemi.
- Ponga attenzione a trigger e stored procedure legacy: spesso rappresentano logiche di business non documentate che verranno eseguite anche sotto Laravel.
- Introdurre le migration solo per le nuove tabelle. Non lasci che il sistema di migration di Laravel prenda il controllo dello schema legacy a progetto in corso.
- Verifichi che il codice legacy non scriva timestamp o ID in modi inattesi per Eloquent. Questa è una fonte comune di bug difficili da individuare.
Cosa migrare per primo
La sequenza conta più della velocità.
- Qualcosa di poco rischioso e visibile: una pagina statica, un form di contatto, una sezione di aiuto. L'obiettivo è verificare routing, sessione e deployment end-to-end, non fornire valore.
- Le nuove funzionalità, da ora in poi. Tutto ciò che viene sviluppato dopo il primo giorno va su Laravel. È questo che rende la migrazione autosostenibile: la roadmap finanzia la crescita del nuovo sistema.
- Le aree soggette a frequenti modifiche, subito dopo. Ciò che il team modifica più spesso trae il massimo beneficio dall'essere nella nuova codebase, e lo sforzo viene ripagato subito.
- Pagine ad alto traffico lato cliente, dove si ottengono vantaggi in termini di performance e SEO insieme alla migrazione.
- Checkout, pagamento ed elaborazione ordini per ultimi. Sono le aree a rischio più elevato e con il maggior costo d'errore; a quel punto il team avrà già migrato numerose parti più semplici.
- Amministrazione e back-office solo alla fine, a meno che non rappresentino un ostacolo. Gli utenti interni tollerano una certa scomodità; i clienti no.
L'istinto porta a iniziare dal modulo peggiore. Resista. Iniziare dalla parte più difficile significa affrontare subito ogni possibile problema infrastrutturale.
Come mantenere il roadmap attivo
Questo è il punto centrale e va protetto con attenzione.
- Stabilisca una ripartizione fissa — ad esempio 70% roadmap, 30% migrazione — e la mantenga. Una migrazione che assorbe tutta la capacità diventa un problema aziendale in un trimestre, e i problemi aziendali vengono cancellati.
- Ogni route migrata deve portare un risultato. Risolva un bug noto, migliori la pagina, aggiunga una piccola funzione. Una migrazione che non produce valore visibile per sei mesi perde il suo sponsor.
- Renda conto dei progressi in route migrate e file legacy eliminati. Eliminare codice è l'unica prova inequivocabile che una migrazione strangler-fig sta funzionando.
- Non tocchi il codice legacy se non per correggere bug. Ogni miglioramento a un sistema che sta dismettendo è denaro sprecato.
Le modalità di fallimento
- Bloccarsi al 60%. Le route semplici sono migrate, restano solo le più complesse e il disagio si è ridotto abbastanza da far svanire l'urgenza. Così si finisce per mantenere due sistemi all'infinito, peggio di uno solo. Definisca in anticipo cosa determina la chiusura del progetto.
- Costruire uno strato di astrazione tra i due sistemi. Sembra una buona soluzione tecnica, ma diventa un terzo sistema da mantenere, che sopravviverà alla migrazione stessa.
- Migrare lo schema contemporaneamente. Raddoppia le variabili in ogni incidente.
- Mancanza di disciplina nell'eliminazione. Se il codice legacy non viene rimosso man mano che si migrano le route, non si sta migrando: si sta duplicando.
- Sottovalutare ciò che non è documentato. Cron job, endpoint webhook, report che la finanza estrae mensilmente, integrazioni dimenticate. Faccia un inventario prima di iniziare; se li trova in produzione, saranno loro a trovare Lei.
Quando non conviene adottare questa soluzione
Lo strangler fig non è sempre la scelta giusta. Se l'applicazione legacy è davvero piccola — sotto qualche migliaio di righe — una riscrittura diretta è più rapida e la gestione parallela è un onere inutile. Non lo usi se il sistema legacy viene dismesso completamente invece che sostituito. E non lo usi se è la logica di business stessa a dover cambiare: migrare una logica che intende eliminare significa lavorare due volte.
Questo è il modello che guida la maggior parte del nostro sviluppo Laravel su sistemi ereditati, e si affianca alla fase di valutazione descritta in ereditare una codebase PHP legacy. La nostra pratica su piattaforme Laravel e il lavoro di modernizzazione PHP personalizzato coprono entrambi gli aspetti del problema.
Domande frequenti
Quanto dura una migrazione strangler-fig?
Più a lungo, in termini di calendario, rispetto a quanto promette un rewrite, ma genera valore durante tutto il processo invece che solo alla fine. Per un’applicazione complessa, consideri 12–24 mesi di lavoro parziale in parallelo con le attività ordinarie — con la differenza fondamentale che può fermarsi in qualsiasi momento lasciando comunque un sistema funzionante.
Le due applicazioni possono davvero condividere lo stesso database?
Sì, e nella maggior parte delle migrazioni è la scelta consigliata. Modificare lo schema insieme al codice raddoppia le possibili cause di errore e impedisce di migrare una rotta alla volta. Prima passi a Laravel; migliori lo schema solo quando resta una sola codebase.
Come si mantiene l’utente autenticato su entrambi i sistemi?
Prima della migrazione, sposti la sessione su Redis o sul database, uniformi nome, dominio e percorso del cookie e verifichi che entrambe le versioni di PHP serializzino la sessione nello stesso modo. Un sistema gestisce l’autenticazione, l’altro la legge. Testi esplicitamente scadenza e rigenerazione oltre il confine.
Cosa conviene migrare per primo?
Un’area a basso rischio e ben visibile, solo per verificare che routing, sessione e deployment funzionino end-to-end. Poi tutte le nuove funzionalità, quindi le parti che il team modifica più spesso. Checkout e pagamenti per ultimi. Iniziare dal modulo più complesso significa affrontare subito tutti i problemi infrastrutturali.
Cosa succede se la migrazione si blocca a metà?
È il fallimento più frequente: la pressione diminuisce dopo aver migrato le rotte semplici. Definisca la condizione di completamento prima di iniziare, misuri l’avanzamento in base ai file legacy eliminati e mantenga una quota fissa di capacità, così che la migrazione non diventi mai opzionale.
Far revisionare la sequenza
Le scelte su routing, sessione e sequenza determinano il successo. Le analizzeremo prima che Lei investa risorse di sviluppo. Contatti il nostro team; rispondiamo entro un giorno lavorativo.