Replatforming ecommerce: quando conviene cambiare piattaforma e quando no

La decisione di migrare un ecommerce non nasce quasi mai dall'entusiasmo per una piattaforma nuova. Nasce dal costo di restare dove si è. Le personalizzazioni del checkout che prima richiedevano qualche ora cominciano a richiedere settimane. Le integrazioni con le spedizioni, un tempo lineari, girano su soluzioni tampone impilate l'una sull'altra. L'aggiornamento del catalogo che gestiva una persona ora ne occupa tre. Quando la piattaforma smette di crescere insieme al business, la decisione in fondo è già stata presa.

Replatforming è la parola tecnica per questo passaggio: cambiare la tecnologia che fa funzionare il negozio online, non aggiornarla, ma sostituirla con un'altra. È uno dei progetti più complessi e ad alto rischio che un'azienda di commercio elettronico possa affrontare, e proprio per questo va deciso per ragioni solide e affrontato con metodo. Fatto bene, sblocca la fase di crescita successiva. Fatto male, sposta i problemi di prima in un ambiente nuovo, con in più il conto della migrazione.

Questa guida risponde alla domanda che viene prima di tutte le altre: conviene migrare, oppure no. Cosa significa replatforming, quali segnali dicono che è ora, in quali casi invece è la risposta sbagliata a un problema diverso, quali sono i rischi che fanno deragliare i progetti e come si sceglie la piattaforma di destinazione. Il perché in dettaglio e il come in dettaglio hanno una casa loro, e li trovate collegati al punto giusto del discorso.

Cosa significa replatforming, e cosa non è

Replatforming significa spostare un negozio esistente, con i suoi dati di prodotto, gli account dei clienti e le regole di business, su una piattaforma diversa, più adatta a sostenere dove l'azienda vuole andare. È più di un trasloco tecnico: è l'occasione per ripensare l'architettura commerciale e liberarsi del debito accumulato negli anni.

Conviene distinguerlo da due operazioni che gli somigliano ma sono altra cosa. La migrazione dei dati in senso stretto è il trasferimento di informazioni e contenuti da un sistema all'altro, e può avvenire anche senza cambiare piattaforma. Il rehosting è il semplice spostamento del sito su un'infrastruttura diversa, senza toccare codice né funzioni. Il replatforming le comprende entrambe ma va oltre, perché cambia il motore e, di solito, anche il modo in cui il negozio lavora.

Esistono tre modi di affrontarlo. Il passaggio diretto da una piattaforma all'altra, che sostituisce tutto in un colpo solo. La migrazione per moduli, che sposta un pezzo per volta riducendo il rischio. Il passaggio da un sistema monolitico a un'architettura separata e componibile, dove la vetrina si stacca dal motore commerciale. La scelta dipende dalla complessità del negozio e dalla tolleranza al rischio dell'azienda.

Perché si migra: il costo di restare

Le ragioni serie di un replatforming si raccolgono in pochi gruppi. Una piattaforma che rallenta o va in difficoltà nei picchi, e perde denaro nel momento esattamente sbagliato. Un costo di possesso che cresce senza comprare niente, perché una quota sempre più grande del budget se ne va in toppe invece che in sviluppo di valore. Una distanza che si allarga fra ciò che il sistema fa di serie e ciò che serve, finché le funzioni che i concorrenti lanciano in poche settimane richiedono mesi. Integrazioni con i sistemi centrali dell'azienda che non reggono e costringono a gestire i dati a mano.

Ognuna di queste spinte ha un peso e una storia diversa, e le abbiamo raccontate una per una nel pezzo sulle motivazioni che portano ad abbandonare la piattaforma attuale. Qui basta tenere il criterio: una sola di queste ragioni giustifica raramente un progetto intero, ed è la loro somma a spostare l'ago. Quasi mai, del resto, se ne presenta una sola.

I segnali concreti che è ora di migrare

Tradotti in sintomi quotidiani, i motivi diventano riconoscibili. Vale la pena fermarsi quando se ne riconoscono diversi insieme, perché è la somma a fare la diagnosi, non il singolo episodio.

I tempi di caricamento superano stabilmente la soglia oltre la quale il visitatore se ne va. Le richieste a roadmap restano bloccate perché la piattaforma non le sostiene. I costi di licenze, plugin e sviluppo crescono più in fretta del fatturato. I processi interni, dal caricamento prodotti alla gestione ordini, sono diventati una sequenza di forzature che il team evita e che non scalano. Le integrazioni con i gestionali si reggono su soluzioni tampone che nessuno sa più mantenere.

Quando tre o quattro di questi segnali coincidono, non si tratta più di ottimizzare: si tratta di pianificare un progetto strutturato, partendo però dagli obiettivi di business e non dall'impulso di cambiare. Una migrazione decisa sull'onda della fretta comprime la fase di verifica, ed è proprio in quella compressione che nascono la maggior parte dei problemi dopo il lancio. Vale anche per la scelta di dove andare: il miglior software ecommerce è quello che fa per te, e senza obiettivi scritti quella frase resta uno slogan.

Quando non conviene migrare

Non tutti i problemi di un ecommerce si risolvono cambiando piattaforma, e alcune migrazioni nascono da moventi sbagliati che portano solo a spendere senza guadagnare. Riconoscerli in anticipo fa risparmiare un progetto inutile.

Il checkout che converte male è quasi sempre un problema di esperienza d'acquisto, metodi di pagamento, trasparenza sui costi di spedizione o segnali di fiducia, non della piattaforma sottostante. Chi migra per sistemare il checkout spesso introduce nuove rotture in fase di migrazione, mentre il problema di abbandono originario resta intatto. La cura è l'ottimizzazione della conversione, non il trasloco.

Un aspetto datato è un problema di tema, non di piattaforma. Ogni soluzione seria offre temi moderni e orientati alla conversione, e un restyling sul sistema in uso costa una frazione di una migrazione. Cambiare piattaforma per ragioni estetiche equivale a cambiare casa perché si vuole ridipingere la cucina.

Una singola funzione mancante raramente giustifica un progetto intero. Prima di migrare conviene verificare se un'estensione la copre già, e chiedere un secondo parere: ciò che un fornitore presenta come sviluppo su misura a volte è una funzione già disponibile a listino su un'applicazione di mercato. L'imitazione dei concorrenti, infine, è il movente più costoso: un concorrente può aver cambiato perché ha toccato un limite che voi non avete ancora raggiunto, oppure aver commesso un errore. Vale anche per le classifiche: i software ecommerce più usati dicono quanti li hanno scelti, non se servono a voi. La sua situazione non è la vostra, e spesso non lo è nemmeno il suo settore: chi vende abbigliamento online ha vincoli di taglie, resi e stagionalità che riscrivono le priorità da capo.

I rischi veri di una migrazione

Le migrazioni quasi mai vanno storte dove i team se lo aspettano. Il design, il catalogo e il flusso di checkout ricevono tutte le attenzioni. Gli strati sotto, regole fiscali, logica delle spedizioni, configurazioni delle interfacce, dati degli account clienti, integrazioni che da anni tengono in piedi le operazioni quotidiane, vengono trattati come se passassero da soli. È lì che si nascondono i tre rischi più gravi.

La perdita di traffico organico

È il rischio più alto e il più sottovalutato. Cambiare piattaforma significa quasi sempre cambiare la struttura degli indirizzi delle pagine, e senza una mappa di reindirizzamenti completa il posizionamento costruito in anni evapora. La mappa dei reindirizzamenti, la conservazione dei metadati e il controllo della struttura del sito vanno trattati come parte centrale del progetto, non come una rifinitura finale, e c'è una voce che quasi nessun preventivo contiene, cioè il traffico generato dalle pagine filtrate, che i redirect non salvano e che va ricostruito: come si migra senza perdere posizionamento è il capitolo dedicato. Per chi vende all'estero il discorso si moltiplica per ogni mercato, un tema che si intreccia con l'internazionalizzazione e la gestione dei mercati.

L'integrità dei dati

Spostare prodotti, clienti, ordini e storici tra sistemi costruiti in modo diverso è più complesso di quanto sembri. Un cliente che accede al nuovo negozio e non ritrova lo storico dei propri ordini, un feed verso i marketplace che smette di pubblicare il primo giorno, un'anagrafica che si disallinea: sono guasti che minano la fiducia proprio mentre si chiede al cliente di abituarsi al nuovo. La migrazione dei dati va progettata, provata e validata prima del lancio, non improvvisata durante.

La trappola del trasloco a freddo

L'errore più insidioso è trattare il replatforming come un puro spostamento, portando di peso sul nuovo sistema anche i processi rotti e i workaround nati per aggirare i limiti del vecchio. Molti flussi di lavoro esistono solo per compensare difetti della piattaforma di partenza: migrarli invariati significa ricreare lo stesso attrito altrove. È questa la trappola che trasforma un progetto da sei mesi in uno da diciotto, e un budget contenuto in uno fuori controllo. La migrazione è l'occasione per ripulire, non per fotocopiare.

Come si migra: il metodo, in sintesi

Un progetto di migrazione riuscito segue una sequenza precisa, e ogni fase saltata si paga dopo il lancio. Si parte dal caso di business, scritto nero su bianco e approvato non solo da chi guida l'ecommerce ma anche da finanza e operazioni, perché saranno coinvolte entrambe. Si sceglie la piattaforma sui requisiti reali e non sul fascino delle funzioni: quale ecommerce scegliere si valuta sul modello e sul costo totale, non sulla lista delle spunte, e il campo pratico si restringe quasi sempre a quattro nomi: PrestaShop, Magento, WooCommerce e Shopify. Si prepara la destinazione prima di spostare un solo dato. Si migrano i dati e si costruisce la mappa dei reindirizzamenti. Si costruisce, si collauda e si forma l'assistenza. Si lancia, e si tengono gli occhi sui numeri veri.

Detta così sembra lineare, e non lo è. Dentro ognuna di queste fasi c'è un mestiere: la mappatura dei contenuti, il censimento delle funzioni che il negozio usa davvero e, soprattutto, il censimento dei servizi che gli girano intorno, che è il punto in cui le migrazioni si rompono per davvero. Il metodo, fase per fase, sta nel pezzo su come si organizza una migrazione. Qui interessa solo sapere che quella sequenza esiste, e che chi la salta la ritrova tutta intera dopo il go-live.

Il metodo è lo stesso per tutti, ma il punto di partenza cambia il lavoro più di quanto lo cambi il punto di arrivo. Chi lascia Adobe Commerce affronta una migrazione da Magento a Shopify Plus fatta soprattutto di dati e di logiche su misura da tradurre. Chi arriva da Salesforce si porta dietro un modello enterprise e un contratto, e nella migrazione da Salesforce Commerce Cloud a Shopify la partita si gioca sul perimetro. Chi viene da un negozio più leggero ma pieno di moduli trova nella migrazione da PrestaShop a Shopify un lavoro concentrato sul catalogo. E chi parte da WooCommerce lascia un ecosistema di plugin, tanto che nel passaggio da WooCommerce a Shopify il grosso dell'impegno è sostituire quelle funzioni una per una. Quattro origini, quattro percorsi diversi: conviene leggere quello che riguarda il proprio.

Scegliere la piattaforma di destinazione

La scelta della destinazione è la decisione più pesante dell'intero progetto, perché sbagliarla costringe a una nuova migrazione entro pochi anni. Le piattaforme open source della famiglia Magento e Adobe Commerce offrono profondità di funzioni e personalizzazione spinta, ma sono costose da mantenere e richiedono sviluppatori specializzati: i loro limiti per chi le utilizza, e il modo in cui un sistema in cloud li risolve, li abbiamo analizzati a parte parlando dei problemi di Magento e Adobe Commerce.

C'è poi una famiglia di partenza diversa, ed è quella delle suite enterprise a licenza, dove il caso più frequente è Salesforce Commerce Cloud. Qui il ragionamento cambia, perché non si sta lasciando un open source da mantenere: si sta lasciando un SaaS che si paga a percentuale sul fatturato, e il calcolo di convenienza è tutto un altro. Cambia anche l'esecuzione, perché il codice di quella piattaforma non si converte, si riscrive: cosa si porta e cosa cade migrando da Salesforce Commerce Cloud a Shopify è il pezzo dedicato.

Sul fronte opposto, le piattaforme in cloud come Shopify concentrano il valore nella rapidità di messa a terra, quello che di solito si vende come sito ecommerce già pronto, e nella manutenzione inclusa nel canone: infrastruttura, sicurezza e aggiornamenti non sono più lavoro dell'azienda, e questo cambia la struttura dei costi prima ancora che il sito. In cambio si accetta un perimetro: si personalizza molto, ma dentro le regole della piattaforma, non riscrivendone il motore. È esattamente il baratto che va valutato a mente fredda, perché per alcune aziende è una liberazione e per altre una gabbia. Shopify non è l'unica in quella categoria: BigCommerce ne condivide l'impianto SaaS lasciando qualche apertura in più, ed è l'altra destinazione che vale la pena guardare prima di decidere.

La domanda da porsi non è solo quale marca, ma a quale livello: per volumi alti, logiche B2B e vendita internazionale il salto alla versione enterprise cambia le carte, e abbiamo messo a confronto le due versioni nel raffronto fra Shopify e Shopify Plus. In ogni caso, il criterio resta la compatibilità con lo stack tecnologico esistente, cioè quanto pulitamente la nuova piattaforma dialoga con i gestionali già in casa. E se si parte da Magento, il confronto voce per voce con Shopify è il modo più rapido per vedere cosa si guadagna e cosa si lascia per strada.

Il ruolo del partner

Un replatforming pulito dipende meno dalla piattaforma scelta e più da chi lo conduce. Il valore di un partner esperto sta nel sapere dove le migrazioni si rompono davvero, negli strati invisibili che i team interni tendono a dare per scontati, e nel trattare la mappa dei reindirizzamenti, la migrazione dei dati e il collaudo come parti centrali del lavoro e non come rifiniture.

È il tipo di progetto che noi di ICT Sviluppo affrontiamo con una sequenza collaudata di analisi, disegno, costruzione e collaudo, perché su un replatforming l'improvvisazione si paga due volte: una nel progetto e una nei mesi successivi al lancio, quando emergono i problemi che nessuno aveva previsto. Un metodo non elimina il rischio, ma lo rende governabile.

Domande frequenti

Quanto dura una migrazione ecommerce?

Dipende dalla complessità del negozio e dal numero di integrazioni. Un progetto contenuto può completarsi in poche settimane, uno enterprise con molti sistemi collegati richiede diversi mesi. Il fattore che dilata di più i tempi è la trappola del trasloco a freddo: portarsi dietro processi rotti trasforma un progetto breve in uno lunghissimo.

Si perde posizionamento sui motori di ricerca migrando?

Si rischia di perderlo se la migrazione è mal gestita, soprattutto per via dei reindirizzamenti mancati. Con una mappa completa degli indirizzi vecchi verso i nuovi, la conservazione dei metadati e un monitoraggio attento dopo il lancio, il calo è contenuto e temporaneo. È il capitolo su cui non si deve mai risparmiare.

Conviene migrare tutto insieme o un pezzo alla volta?

Il passaggio diretto è più rapido ma concentra il rischio in un solo momento. La migrazione per moduli, un pezzo alla volta, riduce il rischio ma allunga i tempi e richiede una convivenza tra vecchio e nuovo. La scelta dipende dalla tolleranza al rischio dell'azienda e dalla complessità del negozio.

Migrare risolve i problemi di conversione?

Quasi mai da solo. Se il problema è il tasso di abbandono al checkout, la causa è di norma nell'esperienza d'acquisto e va affrontata con l'ottimizzazione della conversione. Migrare senza prima capire l'origine del problema rischia di spostarlo, intatto, su una piattaforma nuova.

Migrare bene, o non migrare affatto

Il replatforming è una leva potente, ma solo quando risponde a un problema reale e viene condotto con disciplina. Migrare per moda, per estetica o per inseguire un concorrente porta quasi sempre più dolore che valore. Migrare perché la piattaforma è diventata il soffitto della crescita, con un caso di business chiaro e una pianificazione che mette traffico e dati al centro, è invece una delle decisioni che aprono la fase successiva dell'azienda.

La differenza tra una migrazione riuscita e un disastro costoso non sta nella piattaforma di arrivo, sta nel metodo con cui si gestisce il passaggio. Chi pianifica bene tratta gli strati invisibili con lo stesso rispetto della vetrina, e arriva al lancio con poche sorprese invece che con molte.