Byt plattform utan big bang: replatforming steg för steg

Det riskablaste du kan göra med din e-handel är att byta allt på en gång. Här är metoden för att slippa.

Föreställ dig att du leder e-handeln på ett bolag som vuxit ur sin plattform. Checkouten hänger sig vid kampanjtoppar, integrationen mot ERP är ihoptejpad, och varje ny funktion tar tre gånger längre tid än den borde. Beslutet är fattat: ni ska byta e-handelsplattform.

Och nu kommer frestelsen. Att bygga allt nytt, parallellt, i ett separat spår — och sedan slå om strömbrytaren en söndagsnatt. Big bang. Ett snitt, en lansering, klart.

Det är så här replatforming-projekt går överstyr. Vi har sett det tillräckligt många gånger för att säga det rakt ut: big bang är inte en plan, det är en förhoppning.

Varför big bang är så riskfyllt

En total omläggning kräver att du återskapar hela beteendet hos ett system du knappt längre förstår i sin helhet. Varje udda affärsregel, varje undantag i prislogiken, varje integration som någon byggde 2017 och slutade — allt måste med, samtidigt, innan du vågar gå live.

Problemet är inte tekniskt. Det är att riskerna staplas på varandra:

• Scope creep. "Medan vi ändå bygger om" blir projektets farligaste mening. Omfånget växer tills lanseringsdatumet flyttas en gång till.

• Ingen återväg. När allt byts samtidigt finns ingen delvis rollback. Något går fel klockan 02:14 och du står med hela handeln nere.

• Värde låst i bunkern. Under tolv–arton månader levererar teamet noll synligt värde. Affären står still medan konkurrenterna inte gör det.

• Allt-eller-inget-testning. Du kan inte validera systemet på riktig trafik förrän hela det är klart. Då är det för sent att upptäcka det som inte syntes i staging.

Big bang-projekt har ett genomgående svagt facit, just för att försöket att replikera ett befintligt systems fulla beteende är en grogrund för skenande omfång och försenade lanseringar [källa: https://coderapper.com/article/headless-commerce/composable-commerce-migration/].

Strangler fig: bygg det nya runt det gamla

Det finns ett etablerat alternativ, och det kommer inte från e-handelsvärlden. Martin Fowler beskrev 2004 Strangler Fig-mönstret som ett säkrare sätt att modernisera än att skriva om allt på en gång [källa: https://www.thoughtworks.com/en-us/insights/articles/embracing-strangler-fig-pattern-legacy-modernization-part-one].

Namnet kommer från strypfikonet, som gror uppe i kronan på ett värdträd och växer nedåt tills det till slut ersatt trädet helt. Översatt till din plattform: du bygger det nya systemet runt det gamla, en funktion i taget, och flyttar trafik bit för bit tills det gamla kan stängas av.

Mekaniken är enkel i princip. Du lägger en fasad — en proxy — framför den gamla plattformen. Klienten pratar med fasaden, inte med systemen direkt. I början routar fasaden nästan allt till det gamla. När en ny modul är byggd och validerad pekar du om just den trafiken till det nya. Resten ligger kvar [källa: https://learn.microsoft.com/en-us/azure/architecture/patterns/strangler-fig].

Resultatet är att du aldrig har ett enda farligt ögonblick. Du har många små, omvändbara steg.

Vad du bör migrera först — och sist

Ordningen avgör om projektet känns som framsteg eller som att treva i mörker. Principen: börja med det som ger mest värde och lägst risk, spara det affärskritiska och hårt sammanflätade till sist.

Flytta tidigt:

1. Frontend och presentationslager. Ofta den enklaste delen att lyfta ut, och den som kunden faktiskt ser. Snabb effekt på kundupplevelse och Core Web Vitals.

2. Sök och produktlistning. En vanlig flaskhals, och en avgränsad modul som går att byta utan att röra checkout.

3. Content och kampanjsidor. Headless CMS låter marknad jobba parallellt med att backend migreras.

Spara till sist:

• Checkout och betalning. Mest affärskritiskt, känsligast för fel. Byt när du byggt förtroende för det nya på mindre riskfyllda flöden.

• Order-, lager- och ERP-integrationer. De djupaste rötterna i monoliten. De som har flest dolda affärsregler.

Branschens egen erfarenhet pekar åt samma håll: börja med komponenten som är den största flaskhalsen — ofta sök eller frontend — och validera varje del för sig innan nästa följer [källa: https://www.contentful.com/blog/composable-commerce-migration/].

Varför pre-composed gör stegvis byte möjligt

Strangler fig förutsätter att du kan byta en modul utan att riva resten. I en monolitisk plattform är det svårt — allt hänger ihop, och "byt bara sök" finns inte som alternativ. Det är här arkitekturen avgör.

En composable arkitektur gör det möjligt att byta enskilda moduler utan total ombyggnad [källa: https://www.xictron.com/en/blog/composable-commerce-modular-architecture-2026/]. Sök, CMS, kunddata och betalning är separata tjänster som pratar via API — inte sammanvävda i en kodbas.

Callisto är vår pre-composed lösning byggd på just den principen. Norce Commerce hanterar handelslogiken, Voyado kunddata och lojalitet, Storyblok content. De är förintegrerade men inte ihopgjutna. Det betyder att du kan koppla in en modul i taget bakom fasaden, köra den parallellt med det gamla, och flytta över trafik när du är trygg.

Skillnaden mot ren composable: du slipper själva integrationsarbetet mellan modulerna. Det är redan gjort. Du behåller stegvisheten men tar bort en stor del av risken och tidsåtgången.

Tidslinje och vanliga fallgropar

Ett strangler-baserat byte mäts i kvartal, inte i en lanseringshelg. En realistisk rytm: ett par månaders förarbete med fasad och datamodell, sedan en ny modul live var sjätte till åttonde vecka. Bolag som går stegvis når i praktiken snabbare funktionsleveranser och lägre projektrisk [källa: https://coderapper.com/article/headless-commerce/composable-commerce-migration/].

Fallgroparna är förutsägbara — och därför möjliga att undvika:

1. Dubbel sanning i datan. När gammalt och nytt kör parallellt måste det vara glasklart vilket system som äger vilken data. Annars får du två versioner av samma kund.

2. Fasaden blir permanent. Proxyn är ett verktyg under resan, inte slutmålet. Sätt ett datum för när det gamla ska vara borta, annars lever monoliten kvar i åratal.

3. Ingen avvecklingsplan. Strangler fig är inte klart förrän värdträdet är fällt. Migrering utan decommission är bara mer komplexitet.

4. Att börja med checkout. Den känns viktigast, så frestelsen är stor. Men att inleda med det mest affärskritiska flödet är att ta största risken först.

5. Att se det som ett projekt med slutdatum. Composable är snarare en ny driftmodell — modulär, iterativ, löpande förbättringsbar.

Så här gör du i praktiken

1. Kartlägg innan du bygger. Vilka moduler finns, vem äger vilken data, vad är mest sammanflätat? Det styr ordningen.

2. Sätt fasaden först. Utan en proxy framför systemen finns ingen stegvishet att tala om.

3. Börja där värdet är högt och risken låg. Frontend, sök, content. Inte checkout.

4. Validera på riktig trafik, modul för modul. Varje steg ska vara litet nog att rulla tillbaka.

5. Bestäm avvecklingsdatumet i förväg. Annars stryper du aldrig det gamla på riktigt.

Det egentliga valet handlar inte om vilken plattform du landar på. Det handlar om hur du tar dig dit — med ett enda andlöst hopp, eller med en serie steg där varje enskilt är tryggt nog att ångra. Frågan är vilken risk du faktiskt är beredd att bära den där söndagsnatten.

Vi har gjort den här resan med nordiska handlare förut. Vill du se hur en stegvis väg till Callisto ser ut för just er affär? [BEKRÄFTA: ev. namngivet replatforming-case]