Come si organizza una migrazione ecommerce: contenuti, funzioni e censimento dei servizi

La domanda che arriva sempre per prima, in una migrazione, è quanto costa. La domanda che dovrebbe arrivare per prima è un'altra: cosa c'è dentro il negozio che avete oggi. Non il catalogo, non il tema, non le pagine. I servizi. Il motore di ricerca, il sistema di recensioni, la piattaforma di email, il feed verso i comparatori, il configuratore, il programma fedeltà, il gestore delle taglie, il modulo che calcola le spedizioni con quel corriere lì. Sono decine, quasi sempre nessuno ne ha l'elenco, e sono la ragione per cui le migrazioni sforano.

Questo pezzo è il manuale d'esecuzione, e dà per deciso il resto: che la migrazione s'abbia da fare. Se siete ancora al bivio, la decisione si prende altrove, nel pezzo su quando conviene un replatforming e quando no, che è la porta d'ingresso di tutto questo discorso. Qui si parla di come si organizza il lavoro, e vale in generale: qualunque sia la piattaforma di partenza, le operazioni sono le stesse e cambiano solo i dettagli. I dettagli, però, non sono tutti uguali: le entità che non si traducono venendo da PrestaShop sono un problema diverso da quali plugin WordPress vanno sostituiti uno per uno quando si arriva da WooCommerce.

Diamo per discusse anche le ragioni: perché si lascia una piattaforma, con i costi di gestione, gli aggiornamenti e la dipendenza dagli sviluppatori, è il tema del pezzo sulle motivazioni che portano a migrare. Qui mettiamo in fila quattro lavori, e sono i quattro che decidono l'esito: la mappatura dei contenuti e dell'architettura dell'informazione, il censimento delle funzioni, il censimento dei servizi, e i nodi tecnici che stabiliscono se il traffico sopravvive al passaggio. In mezzo c'è la parte che nessuno racconta, ed è anche quella che dà il numero al preventivo.

L'architettura dell'informazione viene prima dei dati

Il primo lavoro non è tecnico: è disegnare come sarà organizzato il negozio nuovo. Quali categorie esistono, come si annidano, che rapporto hanno con i filtri, quali pagine di atterraggio devono esistere perché oggi portano traffico. Sembra un lavoro da fare dopo, quando i dati sono là. È esattamente il contrario: se l'architettura la si decide dopo l'importazione, la si decide sotto ricatto, adattandola a come i dati sono arrivati.

Qui si presenta la tentazione più forte di tutto il progetto, ed è quella di ricostruire l'esistente tale e quale, perché è più rapido e non richiede decisioni. È anche il modo più sicuro di spendere sei mesi per ritrovarsi con lo stesso negozio di prima, sopra una tecnologia diversa. La regola è semplice: si porta ciò che funziona, si ripensa ciò che non funziona, e si decide adesso quale dei due è ciascuna cosa.

Il censimento delle funzioni, e i punti deboli da sistemare

Secondo lavoro: scrivere l'elenco di tutto quello che il negozio fa oggi. Non quello che dice il capitolato di cinque anni fa, quello che fa adesso. La ricerca interna, i filtri, le regole di prezzo, i codici sconto, i listini per cliente, le regole di spedizione per zona e per peso, la gestione delle taglie esaurite, la lista d'attesa, il reso online, la fattura, i punti fedeltà. Elenco lungo, noioso, e imprescindibile: è la base su cui si stima il progetto, e chi non lo fa sta stimando a caso.

Accanto a ogni voce dell'elenco va messa una seconda colonna, e vale quanto la prima: questa cosa funziona? Perché in ogni negozio ci sono funzioni che nessuno usa, funzioni che tutti odiano, e processi che esistono solo per aggirare un limite della piattaforma vecchia. Quelli non si migrano: si buttano. La migrazione è l'unica occasione, spesso a distanza di anni, in cui è legittimo dire che una cosa non serve più. Sprecarla per fedeltà all'esistente è il vero costo nascosto del progetto.

Cosa si migra: i dati e i contenuti

Sul piano concreto, una migrazione tocca alcune famiglie di dati ben precise, e ognuna ha le sue insidie. Vale la pena conoscerle prima di iniziare, perché è qui che si perde o si salva il valore costruito negli anni.

• Catalogo prodotti: prodotti, varianti, immagini, attributi, categorie. È il momento giusto per bonificare, eliminando le referenze morte e sistemando una tassonomia cresciuta male nel tempo, non per trascinare il disordine accumulato.
• Clienti: anagrafiche, segmentazioni, consensi al marketing. Le password non si migrano, perché sono cifrate e illeggibili anche per chi le ospita, quindi si gestisce un reset al primo accesso, comunicandolo bene per non perdere persone per strada.
• Storico ordini: gli ordini passati servono al servizio clienti, alla contabilità e all'analisi del valore del cliente nel tempo. Vanno migrati con criterio, decidendo quanta storia portare e in che forma.
• Contenuti e blog: pagine, articoli, risorse. Sono spesso il patrimonio SEO più sottovalutato e il primo a essere sacrificato per fretta.
• URL e struttura: la mappa degli indirizzi del vecchio sito è un asset, non un dettaglio tecnico. Da come la si tratta dipende buona parte del traffico organico del giorno dopo il lancio.

Il censimento dei servizi, che è il lavoro che decide il preventivo

Qui arriviamo al punto che nella maggior parte dei progetti viene scoperto troppo tardi. Attorno a ogni ecommerce maturo orbitano decine di servizi di terzi: il motore di ricerca, le recensioni, l'email marketing, il feed verso i comparatori di prezzo, il live chat, il programma fedeltà, l'analisi dei dati, il gestore dei consensi, il calcolo delle spedizioni, la fatturazione. Nessuno di questi è la piattaforma, e tutti sono indispensabili al negozio. Vanno censiti uno per uno, e per ognuno va data una risposta secca, che può essere solo una di tre.

Primo esito: si porta identico

Sono i servizi che esistono su entrambi i mondi, perché sono prodotti autonomi che si integrano con più piattaforme. Algolia, per fare l'esempio più chiaro sulla ricerca, pubblica connettori per Adobe Commerce e Magento, per Salesforce B2C Commerce, per Shopify, per BigCommerce e per commercetools: se lo usate oggi, lo userete anche domani. Cambia il connettore, non il servizio. Il dato importante, per il progetto, è che qui il costo è di riconfigurazione, non di ricostruzione, e che il know-how del team non si perde. Su un'origine come Salesforce, dove il codice è fatto di cartridge che non hanno un corrispettivo dall'altra parte, è proprio questa distinzione a disegnare il perimetro: cosa si porta e cosa cade migrando da Salesforce Commerce Cloud è il conto che decide i tempi.

Vale la pena verificarlo servizio per servizio, invece di darlo per scontato: il fatto che un fornitore sia grande non garantisce che copra la piattaforma di destinazione, e il fatto che la copra non garantisce che il connettore abbia le stesse funzioni su tutte. Va guardata la documentazione ufficiale del fornitore, non la promessa commerciale.

Secondo esito: va sostituito, perché dall'altra parte non esiste

Sono i servizi che nel mondo di origine sono moduli installati dentro il sistema, e che nel mondo di destinazione semplicemente non hanno un corrispettivo, perché quel mondo risolve la stessa esigenza in un altro modo. Il caso da manuale sono i feed di prodotto: chi viene da Magento ha un modulo che genera il feed e lo pubblica. Su Shopify il feed verso Google non è un modulo: è un canale di vendita, che si installa e sincronizza il catalogo direttamente con il Merchant Center, e se un feed esisteva già viene sovrascritto per evitare conflitti.

La sostituzione non è un problema in sé, ed è anzi spesso un miglioramento. Il problema è quando non la si prevede, perché ogni sostituzione porta con sé tre cose che costano: una configurazione da rifare da zero, un pezzo di storico che non viene dietro, e un team che deve imparare uno strumento nuovo. Se il conto dei servizi da sostituire lo si fa a marzo, si pianifica. Se lo si fa a settembre, si va in ritardo.

Terzo esito: va sviluppato ex novo

È la categoria più piccola e la più pericolosa, perché è quella che fa il prezzo. Ci finiscono le cose davvero specifiche dell'azienda: la regola di prezzo che dipende dal contratto di quel cliente lì, l'integrazione con quel gestionale che non ha connettori perché l'ha scritto un fornitore locale nel 2009, il configuratore di prodotto costruito su misura. Non esistono altrove e non si comprano: si costruiscono.

Prima di metterle in questa colonna, però, va posta la domanda scomoda: questa cosa serve davvero così com'è, o è fatta così perché la vecchia piattaforma non permetteva altro? Una parte non trascurabile di ciò che sembra sviluppo su misura irrinunciabile è in realtà la cicatrice di un limite tecnico che non esiste più. Ricostruirla significa portarsi dietro la cicatrice e pagarla due volte.

Quando le tre colonne sono piene, il progetto ha finalmente una forma: si sa cosa si riconfigura, cosa si sostituisce e cosa si costruisce. Ed è solo a questo punto che una stima significa qualcosa. Ogni preventivo di migrazione fatto prima di questo censimento è un numero messo lì per far contento chi lo ha chiesto.

I nodi critici da presidiare

Se il trasloco dei dati è meccanico, ci sono alcuni punti dove una migrazione si gioca la riuscita. Sono i nodi che, quando saltano, trasformano un progetto promettente in un incidente da raccontare nei convegni.

La SEO e i redirect

È il rischio numero uno, e il più sottovalutato. Quando cambiate piattaforma cambiano gli indirizzi delle pagine, e se i vecchi non vengono reindirizzati ai nuovi con un redirect permanente, il 301, i motori di ricerca trovano errori 404 al posto delle pagine e il posizionamento costruito in anni evapora. Su Shopify i redirect si gestiscono dall'amministrazione del negozio e si importano in blocco da un file CSV, il che rende il lavoro fattibile anche su migliaia di indirizzi. Ci sono però dei dettagli che si pagano cari se si scoprono dopo: un redirect si attiva soltanto se l'indirizzo di partenza restituisce un errore 404, quindi non si può reindirizzare un percorso che sul nuovo sito è ancora attivo; e sul comportamento dei redirect nelle sottocartelle dei mercati internazionali la documentazione ufficiale si contraddice, quindi va provato sul negozio prima del lancio e non dato per scontato. La mappa va preparata prima, voce per voce, e verificata dopo. Insieme ai redirect vanno preservati i metadati, la struttura dei titoli e i dati strutturati, perché un sito tecnicamente nuovo ma cieco ai motori è un passo indietro travestito da passo avanti. Il capitolo per intero, compresa la coda lunga delle pagine filtrate che i redirect non salvano, sta nella guida alla migrazione SEO verso Shopify.

Le integrazioni con i sistemi aziendali

Un ecommerce enterprise non è un'isola: dialoga con il gestionale, con il sistema di gestione degli ordini, con il software di anagrafica prodotti, con la logistica, a volte con il CRM e con la piattaforma di marketing. Su Shopify queste integrazioni vivono fuori dalla piattaforma e comunicano via API, secondo il principio per cui il nucleo del software resta intatto e le funzioni aggiuntive risiedono all'esterno. È un modello più solido, perché evita i conflitti tipici dei moduli installati direttamente sul server, ed è il rovescio esatto del motivo per cui WooCommerce regge male un ecommerce aziendale, dove ogni plugin è codice di terzi che gira dentro il sito. Ma va progettato: capire quali flussi di dati servono, in che direzione, con quale frequenza, è parte integrante del replatforming, non un dopo.

Pagamenti, fiscalità e mercati

La configurazione di pagamenti, imposte, spedizioni e listini è il genere di lavoro che sembra noioso finché un cliente non viene tassato in modo sbagliato o un ordine non parte. Va impostato con metodo, soprattutto quando si vende in più paesi, dove valute, regole fiscali e metodi di pagamento locali cambiano da mercato a mercato. Qui Shopify offre un apparato dedicato all'internazionalizzazione che semplifica molto la gestione transfrontaliera, e ne abbiamo parlato in dettaglio nel pezzo su Shopify Markets e l'internazionalizzazione.

La convivenza tra B2B e B2C

Per molte aziende la migrazione è anche l'occasione per portare il commercio all'ingrosso dentro lo stesso sistema della vendita al consumatore. Su Shopify il B2B è gestito in modo nativo, con account azienda, listini dedicati e termini di pagamento, e il perimetro di ciò che è incluso nei vari piani si è mosso nel tempo, quindi va verificato sul listino in vigore quando si sceglie. Quello che conta per il progetto è pianificare fin dall'inizio come il canale business si innesta, invece di aggiungerlo a forza dopo il lancio: è uno dei temi che approfondiamo nel pezzo dedicato al B2B e alla vendita all'ingrosso su Shopify.

Le fasi di una migrazione fatta bene

Un replatforming serio non si improvvisa e non si fa tutto insieme. Ha una sequenza, e ogni fase ha un suo esito che abilita la successiva. È la struttura con cui lavoriamo, e che riduce il rischio distribuendolo invece di concentrarlo tutto sul giorno del lancio.

1. Discovery e analisi: si parte dai numeri e dai processi reali dell'azienda, si mappa l'esistente, si definiscono obiettivi e requisiti. È la fase dove si decide cosa cambiare e cosa no, ed è quella che determina la qualità di tutto il resto.
2. Design e analisi funzionale: si disegnano l'esperienza e l'architettura, si definiscono le pagine, i flussi e le funzioni custom. Qui il progetto prende forma su carta prima di prenderla nel codice.
3. Build: si costruiscono il tema, le configurazioni e le integrazioni o le applicazioni custom dove servono. È la parte di sviluppo vera e propria, sul front end e sul back end.
4. Migrazione dei dati: si trasferiscono catalogo, clienti, ordini e contenuti, si bonifica e si verifica la correttezza di prezzi, scorte e attributi.
5. Test: si prova tutto, dagli ordini reali annullati alle notifiche, dai pagamenti ai redirect, prima che lo veda un cliente. È la rete di sicurezza.
6. Go-live: si lancia, si attivano i redirect, si trasferisce il dominio, si tiene il sistema sotto osservazione nelle prime ore e nei primi giorni.
7. Post go-live: si monitora, si correggono gli assestamenti, si misura e si pianificano le evolutive. Un lancio non è una fine, è un inizio.

Quanto dura, e da cosa dipende il prezzo

Le due domande arrivano sempre insieme, e la risposta onesta è che dipende dalla complessità. Una migrazione lineare, con un catalogo ordinato e poche integrazioni, si chiude in poche settimane. Un progetto enterprise con tema custom, B2B, più mercati e integrazioni profonde con i sistemi aziendali è un percorso di mesi, scandito dalle fasi appena descritte.

Sul prezzo il discorso è lo stesso, e riporta esattamente al censimento dei servizi: non è il numero di prodotti a fare il preventivo, è la terza colonna, quella delle cose da costruire da zero. Due negozi con lo stesso catalogo possono costare uno il triplo dell'altro perché uno ha quindici servizi che si riconfigurano e l'altro ne ha tre da riscrivere. Il canone della piattaforma, che è la cifra che tutti chiedono per prima, è la parte piccola e prevedibile del conto: come si compone davvero l'investimento di un progetto lo abbiamo scomposto nel pezzo su quanto costa un progetto ecommerce su Shopify Plus.

Gli errori da evitare

Il primo errore è trattare la migrazione come un'operazione tecnica da delegare al fornitore più economico. Il secondo è ignorare la SEO, che è esattamente la parte che il fornitore più economico taglia per prima. Il terzo è il fai-da-te oltre la propria competenza: Shopify è semplice da usare, e questo inganna, perché far funzionare un negozio non è la stessa cosa che far funzionare un replatforming enterprise senza perdere dati, traffico e clienti per strada.

C'è poi un errore più sottile, quello di chi sceglie l'agenzia sbagliata convinto che ormai facciano tutti Shopify. È vero che le agenzie che propongono Shopify sono molte, ed è altrettanto vero che quelle in grado di sviluppare soluzioni davvero in linea con la filosofia della piattaforma, temi performanti, integrazioni pulite, applicazioni custom dove servono, sono poche. La differenza tra un sito che regge il Black Friday e uno che cade non è la piattaforma, è chi l'ha costruito.

In sintesi

Una migrazione si organizza in quattro lavori, e nessuno dei quattro è il trasloco dei dati. Si disegna l'architettura dell'informazione prima di importare qualsiasi cosa. Si censiscono le funzioni che il negozio usa davvero, separando quelle che servono da quelle che esistono solo per aggirare un limite. Si censiscono i servizi, dividendoli fra quelli che si portano identici, quelli che vanno sostituiti perché dall'altra parte non hanno corrispettivo e quelli che vanno costruiti da zero. E si presidiano i nodi tecnici che decidono se il traffico sopravvive al passaggio. Chi fa questi quattro lavori arriva al lancio con poche sorprese. Chi li salta li ritrova tutti, moltiplicati, il giorno dopo.

È un lavoro che in ICT Sviluppo affrontiamo con metodo, partendo dai processi reali dell'azienda e non dalla tecnologia in astratto. Se vuoi capire come ragioniamo su un progetto di migrazione, il punto di partenza è la nostra pagina dedicata al replatforming.

Domande frequenti

Quanto dura una migrazione a Shopify Plus?

Dipende dalla complessità. Un progetto lineare si chiude in poche settimane, mentre una migrazione enterprise con tema custom, B2B, più mercati e integrazioni profonde è un percorso di alcuni mesi, scandito dalle fasi di discovery, design, build, migrazione dati, test e go-live.

Si perde il posizionamento SEO migrando?

Non se la migrazione è fatta bene. Il rischio esiste e va presidiato con una mappatura completa dei redirect permanenti, il 301, dai vecchi indirizzi ai nuovi, insieme alla conservazione di metadati, struttura dei titoli e dati strutturati. È una delle attività più delicate dell'intero progetto e la prima che un fornitore poco serio trascura.

Si possono migrare gli ordini storici?

Sì. Lo storico ordini si può trasferire e serve al servizio clienti, alla contabilità e all'analisi del valore del cliente nel tempo. Si decide insieme quanta storia portare e in che forma, per non appesantire inutilmente il nuovo sistema.

I servizi che uso oggi funzionano anche dopo la migrazione?

Alcuni sì, altri no, e non si può sapere senza guardarli uno per uno. I servizi che sono prodotti autonomi, e che pubblicano connettori per più piattaforme, si portano dietro: cambia il connettore, non lo strumento. I servizi che nella piattaforma di origine sono moduli installati nel sistema di solito vanno sostituiti, perché la piattaforma di destinazione risolve la stessa esigenza in un altro modo. E una parte piccola va riscritta. Questo censimento è il primo lavoro da fare, prima ancora di chiedere un preventivo.

Conviene rifare l'architettura del sito o replicare quella attuale?

Le due cose vanno separate. La struttura degli indirizzi e delle pagine che oggi portano traffico va conservata il più possibile, perché cambiarla senza necessità significa rischiare posizionamento per niente. L'organizzazione interna, invece, va ripensata dove non funziona: le categorie cresciute male, i processi nati per aggirare i limiti del vecchio sistema, le funzioni che nessuno usa. Si conserva ciò che ha valore per chi arriva da fuori, si ripulisce ciò che pesa su chi lavora dentro.