Per un e-commerce la migrazione da un PHP fuori supporto tocca molto più del codice. Dietro i file PHP ci sono anni di ordini, migliaia di clienti con il loro account e la loro password, pagine prodotto che arrivano in prima pagina sui motori di ricerca. Se qualcosa si perde nel passaggio, l’effetto si vede subito: clienti che non riescono ad accedere, numeri d’ordine duplicati, traffico organico che cala nelle settimane successive al lancio.
In questo articolo descriviamo un metodo che vale per le piattaforme più diffuse, da Magento a PrestaShop, da WooCommerce a OpenCart, e per i negozi sviluppati su misura. Vediamo cosa inventariare, come trattare ordini, password e consensi, come proteggere il posizionamento con i redirect e come organizzare il passaggio in modo che il negozio resti chiuso il meno possibile.
Perché l’e-commerce è il caso più delicato
Un sito vetrina si può ricostruire e ripubblicare: i contenuti sono pochi e cambiano di rado. Un negozio online invece cambia ogni minuto. Arrivano ordini, i clienti si registrano, le giacenze scendono, i pagamenti vengono confermati in modo asincrono dai gateway. Ogni ora che passa tra l’ultima copia dei dati e il lancio del nuovo negozio è un’ora di dati da recuperare.
A questo si aggiunge il fatto che i negozi su PHP legacy sono quasi sempre su piattaforme di generazioni precedenti, come Magento 1, PrestaShop 1.6 o OpenCart 1.5, e la migrazione coincide con un cambio di piattaforma o di versione principale. Le guide specifiche sono negli articoli su Magento 1 e su PrestaShop 1.6; qui ci concentriamo su ciò che è comune a tutti i casi.
Tre patrimoni da inventariare
Prima di scrivere una riga di codice serve un inventario di ciò che il negozio possiede e che il nuovo negozio deve ereditare. Lo organizziamo in tre gruppi, ciascuno con un controllo misurabile.
| Dato | Cosa verificare dopo la migrazione di prova |
|---|---|
| Prodotti e categorie | numero di prodotti attivi, varianti, prezzi, immagini e giacenze a campione |
| Clienti | numero di account, indirizzi, gruppi di prezzo, accesso con una password reale di prova |
| Ordini | numero di ordini e somma dei totali per anno, stati, ultimo numero d’ordine |
| Regole commerciali | coupon attivi, regole di prezzo, costi di spedizione, aliquote IVA |
| Consensi | iscritti alla newsletter con data e fonte del consenso |
| URL e metadati | elenco degli URL indicizzati, titoli e descrizioni delle pagine principali |
Ordini: storico, numerazione e ordini aperti
Lo storico degli ordini serve ai clienti, che lo consultano dal proprio account, e all’azienda, per assistenza, resi, statistiche e contabilità. Va portato completo, con righe, indirizzi, metodi di pagamento e spedizione e cronologia degli stati. Gli strumenti ufficiali, come il Data Migration Tool di Magento, lo fanno per i dati standard; i campi aggiunti da estensioni o sviluppi su misura vanno mappati a mano.
Tre dettagli meritano attenzione particolare:
- la numerazione: il nuovo negozio deve partire da un numero d’ordine successivo all’ultimo del vecchio, altrimenti si creano duplicati in gestionali, corrieri e comunicazioni ai clienti. Lo stesso vale per la numerazione di fatture e note di credito, se è il negozio a generarle;
- gli ordini aperti: ordini pagati e non spediti, resi in corso, pagamenti in attesa di conferma da parte del gateway. Conviene ridurli al minimo prima del passaggio e avere una procedura scritta per gestire quelli rimasti;
- le integrazioni: gestionale, magazzino, corrieri e marketplace leggono gli ordini dal negozio. Vanno collegati al nuovo negozio nello stesso momento del lancio, e provati prima su un ambiente di test.
Clienti: account, password e consensi
Gli account dei clienti si migrano senza difficoltà. Le password sono un altro discorso, perché il negozio conserva solo un hash, e ogni piattaforma usa il proprio formato: le generazioni più vecchie usano spesso MD5 con un sale, quelle moderne bcrypt o Argon2 tramite le funzioni native di PHP. Le opzioni sono due. La prima è chiedere a tutti i clienti di reimpostare la password al primo accesso, che è semplice ma fa perdere una parte dei clienti abituali. La seconda è far accettare al nuovo negozio anche il vecchio formato e convertirlo al primo accesso riuscito. Alcuni percorsi di migrazione ufficiali lo prevedono già; per un negozio su misura la logica è questa:
<?php
// Accesso cliente: accetta il vecchio hash e lo converte al primo login riuscito
function verifica_password(PDO $db, array $cliente, string $password): bool
{
$hash = $cliente['password'];
if (str_starts_with($hash, '$2y$') || str_starts_with($hash, '$argon2')) {
// Hash moderno creato con password_hash()
$ok = password_verify($password, $hash);
} else {
// Hash della vecchia piattaforma: qui MD5 con sale, da adattare al caso reale
$ok = hash_equals($hash, md5($cliente['salt'] . $password));
}
if ($ok && password_needs_rehash($hash, PASSWORD_DEFAULT)) {
// Sostituisce il vecchio hash con uno moderno e cancella il sale
$stmt = $db->prepare('UPDATE clienti SET password = ?, salt = NULL WHERE id = ?');
$stmt->execute([password_hash($password, PASSWORD_DEFAULT), $cliente['id']]);
}
return $ok;
}Dopo alcuni mesi, gli account che non hanno mai effettuato l’accesso conservano il vecchio hash: a quel punto si può forzare il reset solo per loro. Insieme agli account vanno migrati i consensi, cioè iscrizione alla newsletter, data e modalità con cui è stata raccolta, perché il GDPR chiede di poter dimostrare il consenso. Le carte salvate presso i gateway di pagamento, invece, dipendono dal modulo e dal contratto con il gateway: va verificato con il fornitore se i token restano utilizzabili dal nuovo negozio.
Posizionamento: URL e redirect
Le pagine di prodotto e di categoria accumulano negli anni posizioni nei risultati di ricerca e link da altri siti. Se dopo la migrazione cambiano indirizzo senza un reindirizzamento, quel valore si disperde e i visitatori trovano una pagina di errore. La guida di Google sugli spostamenti di siti dà indicazioni precise:
- mappare ogni vecchio URL al nuovo URL corrispondente, uno a uno, evitando di mandare tutto alla home page;
- usare redirect permanenti lato server, come 301 o 308;
- mantenere i redirect per almeno un anno, meglio più a lungo, e aggiornare i link interni perché puntino direttamente ai nuovi indirizzi;
- inviare la nuova sitemap in Search Console; lo strumento di cambio di indirizzo serve solo se cambia il dominio;
- mettere in conto oscillazioni temporanee del posizionamento durante lo spostamento.
Il modo più sicuro è mantenere gli stessi URL quando la nuova piattaforma lo consente. Quando non è possibile, la mappa dei redirect si costruisce dagli URL presenti nella sitemap del vecchio negozio, da quelli che ricevono traffico organico e da quelli linkati da altri siti. Prima del lancio la mappa va verificata in modo automatico sull’ambiente di prova:
# vecchi-url.txt contiene un percorso per riga, per esempio /scarpe/trekking-uomo.html
# Per ogni vecchio URL stampa codice di risposta e destinazione del redirect
while read -r percorso; do
curl -s -o /dev/null -w "%{http_code} %{redirect_url} $percorso\n" \
"https://prova.negozio.example$percorso"
done < vecchi-url.txt > esito-redirect.txt
# Righe con un codice diverso da 301: da correggere prima del lancio
grep -v '^301 ' esito-redirect.txtOgni riga deve mostrare un 301 verso una pagina che esiste. Un 404, un 200 sul vecchio percorso o una catena di redirect sono errori da correggere prima del lancio, e le destinazioni dei 301 vanno controllate a loro volta con lo stesso ciclo. Insieme agli URL vanno portati titoli e descrizioni delle pagine principali e i dati strutturati dei prodotti.
Il passaggio: prove, congelamento e delta
Il principio che rende la migrazione sicura è la ripetibilità. La migrazione dei dati deve essere uno script o una procedura automatica, eseguibile da capo su una copia fresca del vecchio database. Così si può provare più volte, misurare ogni volta i conteggi della tabella precedente e arrivare al giorno del lancio con una procedura già collaudata.
Il giorno del passaggio il vecchio negozio entra in manutenzione o sospende il checkout, si trasferiscono gli ordini e i clienti arrivati dall’ultima migrazione di prova, con uno strumento di delta come quello di Magento o con lo script completo se i volumi lo consentono, si fanno le verifiche finali e si sposta il traffico sul nuovo negozio. Con una procedura collaudata la finestra può ridursi a poche ore. Conviene sceglierla in base ai dati di traffico, lontano da promozioni e picchi stagionali, e comunicarla ai clienti.
Dopo il lancio
Le prime settimane dopo il lancio sono quelle in cui emergono i problemi che i test non hanno visto. Per questo il monitoraggio va pianificato insieme alla migrazione:
- controllare ogni giorno i log degli errori 404 e aggiungere i redirect mancanti;
- confrontare il numero di ordini e il tasso di conversione con lo stesso periodo precedente;
- verificare in Search Console la copertura dell’indice e gli errori di scansione;
- seguire i pagamenti, comprese le notifiche asincrone dei gateway, e le email transazionali;
- tenere il vecchio negozio spento ma disponibile, con il suo database, per tutto il periodo in cui potrebbe servire un confronto.
Se la migrazione richiede mesi, il vecchio negozio resta in produzione su un PHP fuori supporto per tutto quel tempo. Il backport delle patch di sicurezza sul pacchetto PHP in uso protegge la produzione senza toccare il codice, e lascia al progetto di migrazione i tempi di cui ha bisogno. Se vuoi impostare insieme il piano per il tuo negozio, contattaci indicando piattaforma, versione di PHP e volume di ordini.
Possiamo dunque riassumere
Migrare un e-commerce da un PHP legacy senza perdite significa proteggere tre patrimoni: lo storico degli ordini con la sua numerazione, gli account dei clienti con password e consensi, e il posizionamento costruito negli anni. Si parte da un inventario con controlli misurabili, si rende la migrazione dei dati ripetibile e la si prova finché conteggi e totali coincidono. Le password nel vecchio formato si possono convertire al primo accesso, gli URL che cambiano vanno reindirizzati uno a uno con redirect permanenti mantenuti per almeno un anno, come indica Google. Il negozio resta chiuso solo per il congelamento finale, il tempo di trasferire le ultime differenze, e dopo il lancio errori 404, ordini, pagamenti e indicizzazione vanno seguiti ogni giorno per alcune settimane.
