Replatforming är ett av de projekt där tidplaner har sämst rykte – ofta välförtjänt. Men det är sällan tekniken som spräcker planen. Det är oftast det som inte fanns med i den: integrationer som visade sig vara fler än någon visste, produktdata som behövde tvättas, beslut som drog ut på tiden. En tidplan som håller är framför allt en tidplan som är ärlig om var osäkerheten sitter.
Här är faserna i ett plattformsbyte, vad varje fas ska leverera och var buffertar och beslutspunkter gör mest nytta.
Faserna i en replatforming – och vad de ska leverera
1. Förstudie och kartläggning
Innan någon tidplan skrivs behöver tre saker kartläggas: integrationslandskapet (varje system som pratar med butiken i dag), datat (produkter, kunder, order, innehåll – mängd och skick) och funktionaliteten (vad av dagens beteende som faktiskt används och ska med). Det här är fasen som oftast snålas in på, och det är exakt därför tidplaner spricker senare. Byter ni till HDL Commerce görs detta som en fri migreringsanalys – en genomlysning av just er miljö innan ni förbinder er till något.
2. Lösningsdesign och kravfrysning
Här bestäms målbilden: informationsstruktur, design, vilka integrationer som ska gå via färdiga konnektorer och vilka som kräver anpassning, samt – viktigast av allt – vad som INTE ingår i etapp ett. Ett plattformsbyte är fel tillfälle att samtidigt göra om hela affärsmodellen. Frys kravbilden vid fasens slut och för allt nytt till en etapp två-lista.
3. Uppsättning och integrationer
Plattformen sätts upp, designen implementeras och integrationerna byggs. Integrationsspåret ska starta först, inte sist – det är nästan alltid den kritiska linjen. Färdiga konnektorer förkortar spåret rejält: HDL Commerce har 200+ färdiga integrationer mot bland annat Business Central, Fortnox, Visma Net, Klarna, Swish, nShift och PostNord, listade på integrationssidan. Varje system som saknar färdig konnektor ska ha en egen rad i tidplanen med egen risk och egen buffert.
4. Datamigrering
Migrera i repeterbara körningar, inte som en engångsflytt. Första körningen avslöjar databristerna, de följande verifierar att rättningarna håller, och den sista körs i samband med lansering. Planera datatvätten som eget arbete med egen ägare – smutsig produktdata försvinner inte av att den byter system.
5. Test och acceptans
Testa med riktiga scenarier: riktiga kundprislistor, riktiga fraktregler, riktiga betalflöden. Acceptanstestet ska köras av dem som ska jobba i plattformen, inte bara av projektet. Boka deras tid nu – väntetid på upptagna nyckelpersoner är en av de vanligaste dolda förseningarna.
6. Lansering och stabilisering
Lansera med en genomarbetad checklista: DNS och omdirigeringar från gamla URL:er, spårning, betalflöden i produktion och en tydlig rollback-plan. Planera därefter en stabiliseringsperiod med förhöjd bevakning – och räkna den som en del av projektet, inte som efterarbete. Det är under de första veckorna efter lansering som sällsynta ordertyper, ovanliga betalkombinationer och kantfall i integrationerna visar sig, och då ska teamet som byggde fortfarande finnas kvar med avsatt tid.
Kör spåren parallellt – med rätt beroenden
Faserna ovan är inte strikt sekventiella. Innehållsproduktion, datatvätt och integrationsbygge kan och bör löpa parallellt – men bara om beroendena är uttalade. Innehållsteamet behöver informationsstrukturen från lösningsdesignen, integrationsbygget behöver testmiljöer och åtkomst till källsystemen, och datamigreringen behöver att attributmodellen är spikad. En tidplan som bara listar aktiviteter utan beroenden ser kortare ut än den är; det är beroendena som avgör den verkliga kritiska linjen.
Var tidplaner brukar spricka
- Okända integrationer. Excel-flöden, gamla FTP-jobb och system ”som bara Lasse känner till” dyker upp mitt i projektet. Botemedlet är en grundlig förstudie.
- Datatvätt utan ägare. Alla antar att någon annan fixar produktdatan. Utse en ansvarig med mandat och avsatt tid.
- Beslut utan deadline. Designval, sortimentsfrågor och prislogik som väntar på ”nästa möte” äter veckor. Sätt beslutspunkter i planen med namngiven beslutsfattare.
- Scope som växer i tysthet. Små ”när vi ändå håller på”-tillägg är enskilt största tidstjuven. Allt nytt går till etapp två.
- Innehållsarbetet glöms. Texter, bilder och SEO-omdirigeringar tar längre tid än de flesta planerar för och kan starta tidigt, parallellt med bygget.
Buffertar och beslutspunkter – så läggs de rätt
En klok tidplan har inte en stor buffert på slutet utan flera små vid de osäkra momenten: efter första migreringskörningen, efter integrationstesterna och före lanseringsbeslutet. Buffert i slutet skjuter bara upp upptäckten av problem; buffert vid osäkerheten fångar dem när de är billiga att rätta.
Lägg dessutom in en formell go/no-go-punkt före lansering med tydliga kriterier: migreringen verifierad, kritiska flöden testade med riktig data, omdirigeringar på plats. Det gör lanseringsbeslutet till en kontroll, inte en förhoppning – och det gör det legitimt att flytta datumet om kriterierna inte är uppfyllda.
Vad påverkar längden mest?
Tre faktorer styr kalendertiden mer än något annat: antalet integrationer utan färdig konnektor, skicket på produktdatan och er egen beslutskapacitet. En plattform med B2B och B2C i samma kärna och inbyggd PIM tar dessutom bort hela arbetspaket som annars måste byggas ihop av tillägg – se lösningarna för hur olika typer av verksamheter satt upp sina projekt. Flyttar ni specifikt från Magento finns en egen genomgång av vad som skiljer på jämförelsesidan.
Räkna också på totalkostnaden över projektets och driftens livslängd, inte bara byggkostnaden – med öppen prissättning per månad, som på vår prissida, blir den kalkylen betydligt enklare att göra ärligt.
Börja med analysen, inte med datumet
Den bästa starten på en replatforming är inte att sätta ett lanseringsdatum utan att skaffa fakta. Boka en genomgång så gör vi en fri migreringsanalys av er nuvarande miljö – integrationer, data och funktionalitet – och ger er ett tidplansunderlag som bygger på er verklighet. Kom igång här, svar inom 4 timmar.
