Uppgradera Magento 1 till Magento 2

Jag har arbetat med Magento 1.x (M1) sedan hösten 2011 och Magento 2.x (M2) sedan hösten 2016. Jag har gjort mängder med M1-projekt men bara varit med på tre M2-projekt under 1,5 år. Alla tre M2-projekten har varit nya handelsplatser, ingen hade tidigare använt M1. I den här texten ska jag berätta om mina erfarenheter av Magento 2.1, vad du som e-handelsplatsägare kommer att drabbas av och vad du kan göra för att minska problem och kostnader.

End of life (EOL) M1 hösten 2018

Magento 1 kommer att få säkerhetsuppdateringar till hösten 2018. Därefter kommer upptäckta säkerhetshål att få vara som de är. Det är förstås en ohållbar situation för e-handelsplatser.

Man kan med andra ord inte vara kvar på Magento 1 utan att riskera kunddata. Det kan vara så att en revision kan slå ned på företaget om man inte vidtagit nödvändiga åtgärder för att skydda sina kunders data.

Det här gör att du som e-handelsplattformens ägare måste spendera pengar för att få samma sak som du redan har, en e-handelsplats.

Uppgradera till Magento 2

Det går inte att uppgradera Magento 1 till att bli Magento 2. M1 och M2 delar namnet Magento, de är båda e-handelsplatformar, men sedan slutar likheterna. Det går inte att använda moduler från M1 i M2. Det går inte att använda någon kod alls, allt måste skrivas om. Magento har gjort en modulkonverterare. Vi utvärderade den. Modulerna den skapade fungerade inte och koden var underlig.

Det är INGEN fördel alls att välja M2 bara för att du hade M1 innan. Du är därmed fri att välja vilket annat system som helst när du ska migrera din data från M1 till ett annat system.

Magento 2 – versioner

Magento 2.0.x var första versionen av M2. Den var inte färdig och det var eländes synd om de kunder som hoppade på den versionen. Det var mängder med buggar och produkten skulle inte ha släppts alls.

Ett år senare kom 2.1.x, den var lite mer mogen. För varje version 2.1.2 till 2.1.3 osv så fick vi korrigera våra modifieringar, ibland ganska rejält. Hur man gör moduler i M2 är inte konsekvent för M2 är inte färdigt. Ibland är man tvungen att göra på ett sätt, ibland på ett annat. Magento arbetar mot att bli konsekventa och fasa ut de metoder som inte ska användas. Det betyder ständigt underhåll av alla modifieringar.

Magento 2.2 väntade vi på i ett år, det var länge det stora hoppet. Med mängder av buggfixar så skulle det här vara versionen som löste alla problem. Dessvärre så visade den sig innehålla en mängd buggar den också. Nya buggar men också gamla buggar som rapporterats för över ett år sedan öppnades upp på nytt och utlovades en lösning för i nästa version som kommer i framtiden.

Just nu är Magento 2.3 det stora hoppet. 🙂

M2 buggar

Du kan se hur arbetet med M2 går här: https://github.com/magento/magento2

Här kan du också se att det finns många buggar. Just nu är det 1025 öppna buggar varav 894 har ”G3 passed”, dvs de har konstaterat att det är en bugg och ska fixa den. Om du sorterar listan kan du hitta G3 buggar som legat där sedan hösten 2015.

Du kommer oundvikligen att drabbas i någon form av alla dessa buggar. Jag har fixat en drös med core-buggar som drabbat mina kunder.

Alla dessa buggar gör att du förlorar försäljning på din e-handelsplats, och de direkta kostnaderna att laga buggarna hamnar hos dig.

M2 säkerhetsuppdateringar

Tidigare skickade Magento ut lagningsfiler för att täppa till pockande sårbarheter. En lagning kunde installeras ganska snabbt och effektivt. Detta har Magento slutat med. Istället släpps nya kompletta versioner av M2. Det släpps en ny version i varje serie: 2.0.x, 2.1.x, 2.2.x

Att uppgradera en Magento-version inom samma serie 2.1.x är inget man gör i en handvändning. Du måste se till att 3e-partsmoduler uppgraderas att klara den nya versionen. Dina egna modifieringar måste testas. Och trots alla tester kommer du att behöva laga saker som gått sönder vartefter efteråt.

De här kostnaderna hamnar hos dig. Det du spenderar här är pengar du inte får tillbaka. Men gör du inte det här kan det kosta ännu mer pengar om någon stjäl kunddata eller påverkar dina ordrar.

Magento 2.1 hastighet

M1 var inte långsam, men den var inte snabb heller. Nu har vi fått ganska bra fart på M2. Den är i stort sett lika snabb som M1. För att få fart på M2 ska du köra PHP 7, Redis cache, bra bandbredd, snabb server, lagom med minne, optimera MySQL och Apache. Absolut inte köra xdebug. Använda alla cacher, index och flat-tabeller. Använda OP cache. Då är kundens sidor ganska snabba och admin är drägligt.

Se till att välja en partner som har satt upp Magento 2 siter förut, där du kan se att det fungerar bra.

3e-partsmoduler

Det har varit magert med genomarbetade moduler till M2. Behovet var skriande och det kom ut mindre bra saker på marknaden. Fortfarande har jag inte installerat en 3e-partsmodule som bara fungerat direkt. Alla moduler har behövt lagas på något sätt och kostnaden för det hamnar tyvärr hos dig.

När vi har uppgraderat M2 till nyare version har vi även behövt uppgradera alla 3e-partsmoduler. Det har gått ganska smidigt med composer, och hittills har ingen modul orsakat mer besvär än de redan gör.

Det här är också kostnader som landar hos dig.

Momentum

Alla de här problemen som löpande dyker upp gör att du tappar viktigt momentum. Hela tiden går det åt pengar och tid för att hålla din e-handelsplats på samma nivå som förut. Det här hindrar till viss mån dig från att utveckla ditt erbjudande till kunden.

Budget

Ditt företag behöver ha en ganska stor omsättning för att kunna bära ett Magento 2-projekt i längden. I e-handelsbudgeten måste löpande kostnader och tid avsättas för att hålla M2 på samma nivå. Samtidigt behöver du budgetera för affärsutveckling.

Men det räcker inte att hälla in pengar. M2 kan vara ett bottenlöst hål. Det finns en mängd saker du kan göra för att minska utgifterna med M2, men först – Vad ska jag välja? Är M2 verkligen ett bra alternativ?

Magento 2 som e-handelsplattform

M2 har många saker som talar till dess fördel. Det finns många företag som kan Magento 1 och 2. Magento finns och fungerar. Det är en helhetslösning med allt från produktkatalog till kassa, leverans, faktura, betalning. Allt finns där i M2 från start.

Vanliga saker som saknas i M2

Store locator – hitta till fysiska butiker.

Looks – klädaffärer brukar vilka kunna sälja en hel look.

Integrationer – M2 har inga integrationer alls. Ingen flexibel import eller export, och absolut inte något på automatik.

Butikslager – Har man fysiska butiker kanske man vill visa hur mycket som finns i lager i dem.

Överleva ett M2 projekt

Om du nu bestämmer dig för M2 så kan du spara en mängd pengar på följande knep:

Välj en etablerad aktör

Välj en leverantör för M2 som redan har några projekt bakom sig. Där utvecklarna har erfarenhet av just M2. (M1 erfarenhet hjälper inte).

Arbeta i iterationer

Betyder att du fokuserar på att göra klart något i varje iteration. Till exempel kan första iterationen vara att få igång senaste versionen av M2. Nästa iteration kan vara att konfigurera marknader, skatteregler. Tredje iterationen ett leveransalternativ och en betalmetod. Från och med nu skulle du kunna lansera och börja ta emot kunder om du vill.

Nästa iteration kanske är automatisk produktimport, därefter automatisk orderexport, automatisk import av order shipment + invoice + capture. Nu har du en hel kedja och borde verkligen tänka på lansering. Allt behöver inte vara perfekt från start.

Pressa ut allt från M2 först

Innan du börjar med utveckling och 3e-partsmoduler, se till att du pressar ut allt du kan från det som M2 har att erbjuda. Se till att du lär dig M2s möjligheter och begränsningar och utnyttjar dem. Du kan skapa katalogregler och varukorgsregler, sätta specialpriser och stafflade priser. Du kan ge förmåner till kundgrupper och locka kunder att registrera sig för att få nyhetsbrev. Du kan sända ut nyhetsbrev med information och locka tillbaka kunder. Du kan satsa på innehåll i dina produkter och ha innehållssidor med mer information. Som du ser finns det mycket du kan göra innan M2 sätter begränsningar.

Undvik utveckling

Försök i möjligaste mån att använda de inbyggda funktionerna i M2.
Ju mindre med specialutveckling ju bättre. Men det är sällan möjligt. Du behöver integrationer med ditt PIM system, ditt ekonomisystem etc.

Ska något utvecklas, tänk på att anlita erfarna M2 utvecklare. Håll saker så simpla som möjligt. Anta ingenting. Specificera vad du vill kunna göra. Testa grundligt varje uppgift. Kräv att få en dokumentation och vettiga testbeskrivningar på varje uppgift så du kan testa ordentligt. Får du inte allt detta ska du inte godkänna den uppgiften.

Utveckla inte mer än vad som ska levereras i denna iteration. Få ut koden på din e-handelsplats och börja använda den.

Undvik 3e-partsmoduler

Tanken med 3e partsmoduler är att spara tid jämfört med att utveckla själv.

Välj moduler som trovärdiga källor har bra erfarenheter av. Anpassa dina krav efter vad modulen klarar av. Det är sällan värt att vidareutveckla 3e partsmoduler. De måste passa dina krav från början. Testa modulen grundligt och fullt ut. Se vad den klarar av och inte klarar av.

Om en modul ska installeras, se då till att det görs på en iteration så den modulen blir levererad och gör sin nytta.

Undvik

Jag har via erfarenhet kommit fram till att följande områden ska undvikas helt.

GeoIP – Låt kunden själv bestämma vilken webbsite de vill besöka. GeoIP ger bara märkligt resultat och uppretade kunder.

Personnummer – Fråga aldrig efter personnummer. Lagra aldrig personnummer.

Vara först – Låt någon annan ta de värsta smällarna. Det är smartare att vänta med nya grejer tills de mognar.

Komplicerade funktioner – De kommer bara att bita tillbaka.

Ta inte bort default store även om den inte ser ut att göra någon nytta. Tro mig, den behövs.

Var en aktiv beställare

För att få ned kostnaderna så behöver du vara aktiv, men på rätt sätt. Det är viktigt att du inkluderas i teamets arbete och är aktiv. Om du inte är aktiv så kommer teamet att prestera sämre när de får vänta länge på din respons. Du kanske till och med blir nedprioriterad eftersom dina ärenden inte kommer framåt på grund av dig.

Se till att du lär dig använda M2 admin.

Tänk hela tiden på om varje funktion kan betala sig i ökade intäkter eller minskade kostnader. Går det inte att försvara investeringen så ska den inte göras.

Lär dig att skriva ”user stories” – dvs en kort två raders text hur du vill att något ska fungera.

Se till att du är med och väljer ut uppgifter för nästa iteration (kallas för en sprint).
Här är det viktigt att välja uppgifter som är klara att arbeta på. Annars hamnar uppgiften på undantaget och du förlorar momentum (pengar).

Håll koll på de uppgifter som inte kom med i iterationen. (Dessa samlas i en lista som kallas för backlog).

Se till att gamla eller oviktiga uppgifter raderas.

En uppgift är klar när den fungerar enligt din specifikation, har en bra testbeskrivning och en dokumentation, och du ska även kunna testa uppgiften på en testserver. Du ska inte behöva uppleva att något av detta saknas.

Testa kontinuerligt de uppgifter som är klara för test och skriv din återkoppling i ärendet.

Se till att all information hamnar på rätt ställen, dvs i ärendena.

Läs dokumentationen för alla ärenden och påpeka brister.

Inkludera teamet

Det är alltid bra att ha samma personer i ett team, men verkligheten brukar komma emellan med barnledighet, sjukdomar, uppsägningar. Sådana saker kan skapa underbemanning hos din leverantör. Då är det extra viktigt att det finns dokumentation så nya förmågor kommer igång snabbt.

Ett team som verkligen förstår din verksamhet kommer att arbeta mycket bättre. Ett studiebesök i din verklighet gör att teamet förstår vad det handlar om. Låt utvecklingsteamet teamet träffa dina medarbetare och lär känna varandra lite. Låt teamet vara med och se lite hur dina medarbetare arbetar för att få en bättre förståelse.

Estimat

Om du sedan tidigare har erfarenhet av Magento 1 och estimering av uppgifter där så kan du sällan använda dem på Magento 2. För att få samma funktionalitet i M1 och M2 så behöver du skriva tre gånger mer kod i M2 jämfört med M1. M2 är dessutom sämre än M1 att arbeta i när du vill modellera, dvs testa dig fram till en lösning.

Det här betyder att man kan spara pengar på att göra ett bra förarbete innan man börjar programmera. Programmeraren måste helt och hållet förstå syftet med uppgiften och tillsammans med dig visualisera hur det ska kunna fungera.

Om du ska få någorlunda bra estimat på ett M2 projekt så ska du kräva att följande finns i varje uppgift:

Ärendet ska ha en bra titel och en bra beskrivning. Estimatet inkluderar att koden skrivs, och testas av programmeraren, levereras till en testserver, du ska ha en testbeskrivning och en dokumentation tillgänglig, ärendet ska QA testats OK av någon annan än programmeraren innan projektledaren säger att du kan testa.

Allt detta ska ta max 8 timmar, dvs en arbetsdag annars är uppgiften för stor och borde delas i fler uppgifter med separata estimat.

Slutligen

Det jag beskriver ovan kommer att bli din vardag. Din Magento 2-leverantör kommer att driva saker så långt det går på egen hand, men det är du och ingen annan som ytterst förstår din verksamhet och måste ta besluten.

Det går att få framgång med M2 om du är medveten om riskerna och är aktiv i att undvika dem.