Quando un e-commerce cresce “davvero”, la tecnologia smette di essere solo una piattaforma e diventa un sistema nervoso: integrazioni, dati, procedure, negozi fisici, logistica, marketing e customer care iniziano a tirare tutti dalla stessa parte… oppure a creare caos.
Lo speech di Nicola Infantino (SEO di Motoabbigliamento) e Karina Vaschenko (product manager di un provider di estensioni) al Meet Magento Italy racconta proprio questo: una migrazione non ancora completata da Magento 1 a Magento 2, la gestione di un’espansione retail arrivata a 27 negozi, e l’avvio di un progetto internazionale parallelo per ridurre il rischio e testare l’evoluzione.
Di seguito, il caso studio ricostruito senza aggiungere elementi esterni rispetto a quanto condiviso sul palco.
Le origini: dal 2005, prima di Magento
Motoabbigliamento nasce nel 2005 e, inizialmente, non parte su Magento: prima osCommerce/soluzioni simili, poi Zen Cart, fino ad arrivare a Magento 1, che per Nicola rappresenta “una spinta pazzesca”. In quella fase, la crescita passa anche da un uso intenso di estensioni e personalizzazioni: Nicola racconta di essere stato un “acquisitore impulsivo di plugin”, anche perché Magento 1 (e l’ecosistema di allora) permetteva di sperimentare velocemente.
Un punto chiave del racconto è la mentalità: costruire un asset proprietario e difendere l’indipendenza. L’esempio pratico è l’esperienza con un grande marketplace: vincoli di usabilità e regole sulle varianti (taglie) impattano conversione e controllo dell’esperienza. Da lì, la scelta netta: “padroni in casa non ne voglio”. E il sito proprietario diventa il centro della strategia.
Dal solo online al retail: perché aprire negozi (e cosa cambia davvero)
Nel 2010 arriva un’altra decisione strategica: aprire un negozio fisico. La motivazione, nel racconto, ha due anime:
- Evoluzione dei costi marketing (CPC): percezione di una crescita che rende più complesso reggere la competizione solo a colpi di advertising.
- Specializzazione su categorie “meno scalabili”: abbigliamento e caschi richiedono consulenza e competenza, e possono differenziare rispetto ad accessori più “codificati” e facilmente comparabili.
Negli anni, l’espansione retail accelera: prima alcuni negozi in Toscana, poi l’apertura in Lombardia (Abbiategrasso, inaugurazione nel 2016) fa emergere un dato sorprendente: una notorietà sul territorio che non si vede guardando solo i KPI dell’online (es. conversion rate). All’evento, raccolto con “pubblicità organica”, entrano persone che conoscono persino il customer care “per nome”.
Da lì, la crescita diventa importante: dal 2016 ad oggi (nel racconto) si arriva a 27 negozi. E quando i negozi diventano tanti, il problema non è più “aprire”, ma gestire la complessità.
Il “caos” tecnologico: personalizzazioni, integrazioni e scalabilità su Magento 1
Qui arriva la parte più interessante per chi lavora su Magento e sistemi e-commerce: Motoabbigliamento, crescendo, ha investito “tantissimo” in integrazioni ad hoc costruite quando la scalabilità non era ancora un requisito così pressante.
Nicola descrive un paradosso tipico delle aziende cresciute nel tempo:
- da un lato, queste customizzazioni diventano vantaggio competitivo (hanno “cose” che oggi chiameremmo PIM, ma che in casa avevano già da anni con un nome interno);
- dall’altro, la stessa struttura diventa un vincolo: chi parte più tardi può adottare stack e tool moderni più rapidamente, mentre chi ha tanto “su misura” deve fare i conti con rigidità e debito tecnico.
Con l’aumento dei negozi, l’omnicanalità spinge a integrare Magento 1 con ERP/gestionali e altri sistemi. Ma ogni nuovo punto vendita aggiunge carico, dati e processi. E quando sei “in corsa”, fermarsi per rifattorizzare è difficile.
A complicare ulteriormente il quadro, cresce anche il catalogo: con il retail entrano prodotti e ricambi che un puro player online magari non inserirebbe mai, ma che servono per assistenza, customer journey e gestione del parco clienti.
Operazioni pesanti: cache, database, reindex e ridondanze
Nicola cita esplicitamente investimenti importanti su:
- cache
- database
- reindex
- ottimizzazioni per gestire ridondanze e processi diventati “esponenziali”
È un passaggio chiave: Magento 1, con molte integrazioni e con carichi crescenti tipici del multicanale, finisce per richiedere manutenzione e interventi costanti per restare reattivo.
Un esempio operativo molto concreto: a un certo punto decidono di far spedire dai punti vendita, non solo dal magazzino centrale. Questo implica logiche di disponibilità distribuita, orchestrazione ordini e movimenti stock. Durante il Covid, con prodotti difficili da reperire e negozi in condizioni operative particolari, questa architettura “distribuita” diventa una leva: ordini che vengono composti attingendo stock sparsi tra negozi e magazzino, con una gestione resa possibile anche da plugin (citato un plugin di gestione “multiordini” poi modificato).
Il rovescio della medaglia è la complessità: dati “mixati”, duplicati, ridondati → più lavoro di ottimizzazione per mantenere stabilità.
L’End of Life e l’effetto collaterale positivo: meno plugin impulsivi, più focus sui dati
Nel racconto, il “comunicato di End of Life” della piattaforma (Magento 1) crea panico, ma produce anche un effetto inatteso: non potendo più contare con lo stesso ecosistema e con la stessa serenità di prima, Nicola racconta di essersi spostato su aspetti più “strutturali”, come:
- difficoltà e lavoro sulla misurazione (analytics, business intelligence delle vendite)
- attenzione crescente ai dati più che alle feature “veloci”
È una dinamica realistica: quando la piattaforma entra in una fase di obsolescenza, il costo opportunità delle “pezze” aumenta e il focus si sposta su ciò che rende l’azienda governabile (dati, processi, reporting).
Perché Magento 2: performance, scalabilità e multistore (senza “padroni in casa”)
La migrazione verso Magento 2 è motivata da tre driver ricorrenti nello speech:
- Scalabilità e performance
L’esperienza del progetto internazionale su Magento 2 viene descritta come più stabile “per le performance” rispetto a Magento 1. - Multistore
In Magento 1 “c’erano soluzioni”, ma considerate più rischiose e non adatte. Su Magento 2, il multistore diventa un tassello più praticabile e coerente con l’evoluzione dell’azienda. - Indipendenza
Nicola ribadisce la preferenza per un asset che non dipenda da piattaforme dove “domani qualcuno può chiudermi la piattaforma”. È una presa di posizione netta: rinunciare a certe opportunità pur di mantenere controllo e libertà di manovra.
La scelta strategica: internazionalizzazione come progetto parallelo (per ridurre il rischio)
Un punto molto “da project management” è la decisione di non migrare tutto subito, ma aprire un progetto parallelo su Magento 2 per l’internazionale.
Per scelta, l’azienda aveva ritardato l’internazionalizzazione: Nicola dice chiaramente che preferiva investire il budget marketing in Italia e “aprire un negozio in ogni provincia”, piuttosto che spedire ovunque “per gratificazione”.
Poi però l’internazionale diventa necessario:
- per immagine
- come completamento dell’asset
- e, soprattutto, come modo per testare Magento 2 e le nuove logiche senza rischiare sorprese “in corsa” sulla piattaforma principale italiana.
In questo percorso arriva anche il Covid, che rallenta progetti e priorità (recruiting, gestione operativa, ecc.). Ma oggi (nel racconto) sono “a fine progetto”: con Magento 2 già attivo sul ramo internazionale, e la serenità che “basta fare uno switch” per portare anche la piattaforma italiana su Magento 2 dal punto di vista della gestione dati.
B2B e nuove linee: Motonice e la necessità di una base moderna
Nicola cita il progetto Motonice (ramo internazionale) e l’avvio del B2B, indicato come imminente (“andrà in linea la prossima settimana” nel momento dello speech). Questo passaggio è importante perché spiega una cosa: non è solo una migrazione “perché Magento 1 è vecchio”, ma perché l’azienda sta aprendo nuovi canali e modelli (B2B) che richiedono stabilità, compatibilità e un ecosistema aggiornato.
Omnichannel vs multichannel: stessa esperienza ovunque? Non sempre conviene
Un’altra osservazione controintuitiva: Nicola dice di essersi accorto che l’idea di omnicanalità intesa come “stessa identica esperienza sul sito e in negozio” li ha frenati.
Per loro, in pratica:
- un cliente del sito che entra in negozio si comporta in un modo,
- un cliente del negozio che entra sul sito si comporta in un altro.
Quindi è possibile (con buon marketing e storytelling) gestire anche offerte diverse tra canali, perché i contesti e le leve sono differenti. Questo non è un dettaglio tecnico, ma impatta direttamente:
- struttura pricing/promozioni
- segmentazione
- logiche CRM e customer journey
- priorità di sviluppo (feature in store vs feature online)
Da custom a plugin: il punto di vista di Karina (e perché conta in una migrazione)
La seconda parte dello speech porta il punto di vista “product” di un provider di estensioni.
Karina descrive un pattern comune:
- si parte con una customizzazione (es. layered navigation migliorata) perché quella nativa è “basic”;
- poi arrivano i problemi: update Magento, necessità di adattamento, test, compatibilità con framework moderni (es. Hyvä), linee guida di accessibilità, performance, sicurezza;
- i costi salgono e l’azienda diventa dipendente da sviluppatori specifici per mantenere il sito.
La tesi è che una soluzione “plugin” ben mantenuta può ridurre drasticamente tempi e costi perché:
- è pronta “out of the box”
- richiede meno adattamenti in update
- ha supporto dedicato
Nel caso citato, vengono menzionate estensioni come:
- improved layered navigation
- Omnibus price tracker
- Google Analytics
- e altre
E viene evidenziato che molte di queste soluzioni coprono aspetti di compatibilità con:
- Hyvä
- CSP
- accessibilità
- e requisiti di test/assurance
Karina cita anche un processo di quality interno: manual + automated testing, documentazione tecnica sulle performance tra release, test per marketplace, MFTF e partecipazione ad un programma di assurance.
Infine, riporta due risultati concreti attribuiti al modello “plugin” nel caso presentato:
- rilascio feature “in giorni invece che settimane”
- risparmio “fino al 30%” del budget sviluppo, spostando tempo da manutenzione a innovazione
Lezioni pratiche che emergono dal caso Motoabbigliamento
Senza uscire da quanto raccontato, ecco i takeaway più solidi:
- Le integrazioni ad hoc sono un acceleratore… finché non diventano un freno. Soprattutto quando passano da “supporto” a “fondamenta” della scalabilità.
- Il multicanale fa esplodere i volumi di dati e le ridondanze. Se la base è datata, la manutenzione su cache/database/reindex diventa una voce strutturale.
- Ridurre rischio con un progetto parallelo è una scelta sensata. Nel caso: internazionalizzazione su Magento 2 come “campo prova” prima dello switch della piattaforma italiana.
- Plugin vs custom non è ideologia: è governance. Update, test, accessibilità, CSP, performance: o li “industrializzi” (con partner e/o soluzioni mantenute) o li paghi ogni volta come progetto a parte.
- “Stessa esperienza ovunque” non è sempre l’obiettivo migliore. Differenziare per canale può essere più efficace se guidato da dati e marketing.