WebroundWebroundBlog

Ho migrato un PrestaShop 1.7 a Webround. Ecco com'è andata.

Durante la ricerca di nuovi clienti per Webround, mi presentai a un contatto che mi era stato consigliato per passaparola da un cliente per cui avevo già realizzato un sito.

La situazione era interessante: un e-commerce con 4 anni di storico, più di 4000 varianti di prodotto e un ranking di SEO organico e advertising di tutto rispetto.

Sulla carta, il negozio non era messo male perché il sito girava bene e le vendite arrivavano. Il problema era tutto ciò che non si riusciva a fare.


In questi 4 anni di vendita online, il cliente era passato per tre agenzie marketing, ognuna con le sue idee e personalizzazioni. Il programmatore che aveva inizialmente tirato su il negozio, si era ritirato dal progetto da tempo e nessuno di interno all'azienda poteva mettere mano a qualcosa. Tra plugin non aggiornabili, un sito ormai datato e anche un po' bruttino, si era praticamente rimasti a un'interfaccia da 2010 con poche possibilità di estensione facile.

E l'hosting non aiutava: un server da 250 euro l'anno che faceva di tutto. Tra sito, database, email, asset statici senza CDN e 20 GB di spazio di archiviazione, si andava incontro a errori inattesi e spazio esaurito ogni 3 mesi.


Il cliente non sapeva cosa fare

La sua richiesta era incentrata sul sito, non sul sistema che lo forniva. Sapeva che PrestaShop non era la miglior soluzione, ma a lui sarebbe bastato un banale aggiornamento di interfaccia.

Il problema è che i problemi poi uscivano man mano che parlavamo. la sincronizzazione con i marketplace ormai era andata a causa di plugin non aggiornati, modificare logiche di business era sempre complicato, l'analisi dati era confusionaria e senza metriche ben visibili e organizzate. Insomma, era chiaro che il problema non era solo la personalizzazione.


Che poi, la personalizzazione su PrestaShop è una di quelle cose che richiede il triplo del tempo rispetto a una personalizzazione su un sistema "normale". Non solo le cose non erano granché nella versione 1.7, ma anche sulle nuove versioni non si è fatto grandi passi in avanti. Gli aggiornamenti sono tediosi, tra linguaggi di templating strampalati e plugin che si iniettano direttamente nel core della piattaforma, introducendo problemi, vulnerabilità ed altissimo debito tecnico.


PrestaShop 1.7 portava con sé anche una serie di patch di sicurezza mancate che si erano accumulate nel tempo e, con il traffico che faceva il sito, incluso un buon posizionamento organico e campagne Google Ads attive, era impossibile non vedere che l'infrastruttura non fosse all'altezza di quello che doveva reggere.

A quel punto, il ragionamento era semplice: o ti aggiorno tutto, compri un nuovo tema, ricompri i plugin che avevi prima e facciamo qualche aggiustamento grafico, oppure migri su Webround.

Tra l'altro, oggi, siamo alla versione 9 di PrestaShop. La versione 1.7 è una versione del 2021, che non è direttamente compatibile con un aggiornamento "one-click". In pratica, la migrazione andava fatta e, a questo punto, tanto valeva farla su un sistema migliore.


Il problema del server

Questo non è un dettaglio secondario, perché la macchina che faceva girare il sito era responsabile del database, delle email aziendali, di tutte le immagini del negozio e di tutte le installazioni dei plugin. Sembra assurdo, ma non lo è: la maggior parte delle installazioni PrestaShop sono monoliti intoccabili. Si rompe una cosa e rischi di tirare giù tutto. Un vero e proprio Single Point of Failure.


Webround è serverless per la maggior parte del suo funzionamento. La sua infrastruttura è totalmente custom e fa in modo che nessun merchant debba gestire una singola macchina. Oltre ad avere una CDN nativa, anche il sito è distribuito su rete Edge, quindi non c'è latenza nel caricamento della pagina per chiunque visiti il sito.


Con l'abbonamento attuale, il cliente paga 32,50 euro al mese (hosting + piano Webround Commerce Start), ma vuoi mettere la tranquillità di non dover aggiornare mai più la versione del tuo motore e-commerce con il rischio di perdere dati, accesso all'email aziendale e tutti i dati del tuo sito? Con tanto di gestione libera dell'aspetto e delle funzionalità del sito grazie al codice React, alle API e ai webhook?

Quando il cliente ha scoperto che una funzionalità complessa era a un pacchetto NPM e centinaia di righe di codice di distanza, ha giustamente spalancato gli occhi.


Allora abbiamo deciso di migrare verso Webround.


Il problema dell'export

Il primo ostacolo tecnico è arrivato ancora prima di capire la situazione reale: non avevo accesso SSH e non potevo abilitarlo dal cPanel che mi avevano fornito. Per fare un export massivo, avere accesso diretto al DB è un grande vantaggio ma non era una strada fattibile. Allora ho dovuto improvvisare.

La soluzione è stata uno script PHP da caricare via File Manager, eseguire una volta dal browser e cancellare immediatamente dopo. Lo script interroga direttamente il database PrestaShop, raccoglie tutte le tabelle rilevanti in un unico JSON, e lo scrive fuori da public_html, in modo che non sia mai accessibile pubblicamente. Il file viene poi scaricato via FTP o interfaccia e convertito in SQLite locale con uno script Node.


La migrazione effettiva

Mi era già capitato in passato di migrare dei siti WooCommerce e PrestaShop, quindi il pattern era già pronto. Un classico flusso ETL (Extract-Transform-Load). Ma ne ho approfittato per creare un sistema affidabile e ripetibile per tutte le migrazioni PrestaShop.
Purtroppo, ogni installazione PrestaShop è unica: il DB ha un nome diverso dagli altri, prefissi di tabelle particolari e tante altre sottigliezze che possono rendere lo strumento non integrabile direttamente: per questo è generalmente difficile standardizzare la migrazione. Però, per i dati fondamentali, c'è sempre modo di estrarre qualcosa in maniera standard.


Ho quindi creato una serie di script, il cui ordine non è casuale, che servono ad estrarre i dati da PrestaShop e importarli in Webround tramite le API, esattamente nell'ordine e nel modo che richiede Webround.


La sequenza completa è questa:

  1. Tag e opzioni: I gruppi di attributi PrestaShop diventano tag e opzioni su Webround. Le opzioni riutilizzano i tag per definire le diramazioni dei prodotti in varianti, che su PrestaShop si chiamano combinazioni.
  2. Collezioni: Le categorie, in maniera gerarchica, vengono migrate livello per livello in Webround, preservando la struttura e i filtri che permettono di identificare i prodotti al loro interno.
  3. Prodotti: Questo step crea i prodotti in batch con specifiche, dettagli SEO, dimensioni per le spedizioni e collegamento di tag di categoria e brand.
  4. Varianti: Ogni variante Webround è una combinazione PrestaShop, con slug e SKU univoco, prezzo e disponbilità di magazzino. Nota bene che in PrestaShop le combinazioni hanno un prezzo che si esprime come differenza (aggiuntiva o sottrattiva) dal prezzo del prodotto originale. In Webround, i prodotti non hanno un prezzo: ce l'hanno direttamente le varianti.
  5. Download immagini: Scaricate dal server originale e salvate nell'ambiente che sta eseguendo gli script
  6. Upload immagini: Le immagini condivise da tutte le varianti vanno sul prodotto, mentre quelle specifiche per la singola combinazione vanno sulla variante
  7. PDF: Gli allegati seguono lo stesso pattern delle varianti
  8. Upload PDF: Esattamente come le immagini
  9. Tax zones: Ogni prodotto viene collegato alla zona IVA corretta in base al gruppo fiscale PrestaShop
  10. Shipping: Zone di spedizione e metodi (corrieri disponibili) applicato a tutti i prodotti
  11. Clienti: Questi vengono deduplicati per email e caricati come normali Clienti Webround. Non sono attivate né trasportate credenziali di login
  12. Promozioni: Le "cart rule" di PrestaShop diventano promozioni Webround con tipologia di sconto, limiti di utilizzo e date di scadenza.
  13. Ordini: storico completo con articoli, mapping degli stati e utilizzi delle promozioni per evitare che un utente che ha già usato promozioni ad utilizzo limitato le possa riutilizzare in futuro.


Ogni script è idempotente: se un'esecuzione viene interrotta, la successiva riparte dallo stato salvato, senza duplicare niente. L'importante è non cancellare il contenuto dei file di stato!


I redirect 301

Il sito, tutt'oggi, è primo nel ranking delle ricerche Google su diverse keyword rilevanti, grazie a un catalogo curato, molto esteso e ben sincronizzato con Google Merchant Center, che fa anche da fonte dati per gli annunci Shopping di Google Ads.

Gli script generano automaticamente un file redirects.json che mappa ogni URL prestashop al corrispondente URL Webround: questo consente a Webround di fornire la risposta corretta su tutti gli URL precedentemente assegnati, senza perdere ranking SEO.

Attenzione: questo non è un passaggio opzionale quando c'è uno storico su Google di tutto rispetto, altrimenti il ranking cola a picco e Google è costretto a re-indicizzare tutto il sito. Per salvaguardare la SEO del tuo store prestashop, assicurati che dopo una migrazione, tutti i prodotti siano ugualmente raggiungibili con gli URL precedenti. Restituire un redirect 301 permanente a Google comporta una corretta gestione della migrazione, senza perdite di ranking SEO.


I clienti e le password

La migrazione delle password è spesso difficile: ogni sistema ha il suo meccanismo di hashing per le password e le sue strategie di autenticazione. Con Webround, è chiaramente possibile autenticarsi, ma questa operazione è riservata ai clienti, con un flusso di verifica email e di autenticazione JWT verso le API che non è comodo da "replicare" dentro il sistema di migrazione. Con il cliente, abbiamo stabilito che la cosa migliore fosse di azzerare le credenziali di tutti e inserire un avviso nella pagina di login. È anche una buona occasione per avvisare i clienti che non si autenticano da un po' del nuovo sito, per portare traffico affidabile dal primo giorno di migrazione.


Gli ordini

La migrazione degli ordini e degli articoli relativi è gestita direttamente dallo script di migrazione degli ordini. Grazie al meccanismo di autenticazione, se un cliente si registra dopo aver fatto degli ordini come ospite con la stessa email, tutti gli ordini ad esso associato vengono associati al nuovo cliente creato con l'autenticazione. Questo garantisce che un cliente che torna sul sito, dopo aver eseguito la registrazione, si ritrova comunque tutti gli ordini effettuati sul sito precedente quando accede alla sua area personale.


Il risultato ottenuto

Non solo il cliente oggi è interamente soddisfatto. Le sue parole dimostrano che lo sforzo fatto nella creazione di un sistema Headless, React based ed API-first, ripaga: "Sei molto più veloce di qualsiasi altra persona abbia mai toccato il sito". Sembra roba di poco, ma non lo è.

Allo stesso livello di capacità, su PrestaShop, avrei impiegato il triplo del tempo, se non di più, ad integrare ciò che serviva per rendere il sito totalmente funzionante. Il progetto ha poi richiesto un adattamento di diversi plugin e integrazioni, ma la velocità e la libertà di utilizzo di Webround si è trasformata velocemente in nuove richieste di integrazioni e flussi di business, integrando meccanismi di retention dei clienti, vantaggi promozionali e personalizzazioni front-end che avrebbero richiesto molto più tempo per un risultato che comunque si portava dietro le classiche fragilità di un sistema on-premise ormai superato.


Conclusioni e risorse

Se anche tu stai valutando una migrazione da PrestaShop verso Webround o vuoi semplicemente vedere cosa ho fatto, qui trovi tutto il codice utilizzato.

GitHub: https://github.com/WebroundAdmin/wr-prestashop-migration

← PrecedenteHo costruito un AI website builder per Webround. Poi l'ho eliminato.Successivo →Webround Agent: un business assistant AI che conosce il tuo store.
Luca Siviero
LinkedInTwitterIndieHackersdev.toGitHubemail