# Una flotta di siti WordPress fuori dal server a fine vita.

> Decine di siti di clienti diversi su server Ubuntu 20, ormai senza aggiornamenti di sicurezza. Li spostiamo su server nuovi a ondate, con un utente isolato per sito e PHP aggiornato.

- Settore: Più settori
- Ambito: Cloud e infrastruttura
- Anno: 2026
- URL: https://cloudfactory.it/lavori/migrazione-siti-wordpress-server/

## In breve

Abbiamo pianificato la migrazione di circa 45 siti, rimasti dopo aver eliminato quelli non più usati, da server Ubuntu 20 a server nuovi gestiti con Laravel Forge. Si procede a ondate, dal rischio più basso al più alto, con i siti isolati per utente e il vecchio server acceso finché tutto non è verificato. Insieme abbiamo separato le credenziali di invio email: un utente IAM per sito, limitato al proprio dominio.

- **~45** siti da migrare dopo la pulizia
- **14** siti di un solo cliente spostati da ISPConfig
- **23** siti con un utente di invio email dedicato

## Contesto

Nel tempo i siti dei clienti si erano accumulati su pochi server con Ubuntu 20.04, ormai fuori dal supporto standard: WordPress moderni, WordPress datati, applicazioni Laravel e PHP su misura, alcuni ancora su PHP 7.4. Un cliente aveva da solo 14 siti su un server con pannello ISPConfig.

## Il problema

Tenere tutto dov'era significava server senza aggiornamenti di sicurezza e, sui server più vecchi, siti che condividevano lo stesso utente di sistema. In parallelo, un audit sull'account AWS ha trovato 39 chiavi di accesso su 41 da ruotare, dopo una compromissione delle credenziali SMTP.

## Cosa abbiamo fatto

1. **Prima si toglie.** Inventario e cancellazione dei siti non più usati, così non si migra spazzatura. Abbassamento del TTL DNS a 300 secondi qualche giorno prima, per cambi e rollback quasi istantanei.
2. **Ondate per rischio.** Prima i WordPress aggiornati, poi quelli da verificare su PHP recente, poi le applicazioni con repository, infine il codice su misura più datato, già provato sul vecchio server alzando la versione di PHP.
3. **Lo stesso rito per ogni sito.** Sito creato sul server nuovo con il suo utente, copia dei file con rsync, dump del database, certificato, test con il file hosts, cambio DNS. Il vecchio server resta acceso 48-72 ore.
4. **Codice verificato su PHP 8.4.** Revisione dei temi e dei plugin su misura: dipendenze passate come null, confronti stretti fragili, redirect senza exit, accessi a $_POST senza controlli. Corretti prima del passaggio.
5. **Email con il minimo dei permessi.** Un utente IAM per sito su Amazon SES, con una policy che consente l'invio solo dal dominio del sito e solo dagli IP dei server. Una chiave rubata non manda posta per gli altri.

## Com'è andata

Ogni sito spostato gira con il proprio utente di sistema e una versione di PHP supportata, e le credenziali di invio sono separate sito per sito. Se un sito viene compromesso, resta confinato nel suo utente e la sua chiave email non serve a nient'altro.

## Strumenti

Laravel Forge, AWS EC2, Ubuntu 24.04, PHP 8.3, PHP 8.4, WP-CLI, rsync, Route 53, Let's Encrypt, AWS SES, IAM

## Domande frequenti

### Si può migrare senza fermare i siti?

Sì. Con TTL bassi, test tramite file hosts prima del cambio e vecchio server acceso in parallelo, il visitatore non se ne accorge e il ritorno indietro è immediato.

### Perché un utente di sistema per sito?

Perché se un sito viene compromesso l'attaccante resta confinato nella sua cartella e non legge file e database degli altri.

---

Cloudfactory S.r.l., Roma. Contatti: hello@cloudfactory.it