Big bang eller fasad migrering: så väljer du

Tidigt i nästan varje migrering ställer någon frågan som formar hela planen: flyttar vi allt på en gång – en big bang-driftsättning – eller migrerar vi i faser? Det debatteras hårt, ofta av personer som försvarar en preferens snarare än väger avvägningen. Och det ärliga svaret är att ingen är "bäst": de byter olika risker mot varandra, och rätt val faller ut ur dina förutsättningar, inte en tumregel.

Så här resonerar jag igenom det med en kund.

Vad varje ansats faktiskt betyder

Big bang. Du väljer ett driftsättningsfönster – oftast en helg eller en helgdag – fryser det gamla systemet, migrerar allt, validerar och tar upp alla på det nya systemet på en gång. Ett ögonblick, en omkoppling.

Fasad. Du bryter upp flytten i etapper och driftsätter en bit i taget: per affärsenhet, per geografi, per modul (ekonomi först, sedan logistik) eller per dataområde. Mellan etapperna samexisterar det gamla och det nya systemet, och du kör dem tillsammans en tid.

Den samexistensen är kärnan i hela beslutet, så håll fast vid den.

Big bang: för och emot

För:

• Ingen samexistens att bygga. Du behöver inte hålla två system synkroniserade, eftersom det bara finns ett system of record åt gången. Det är en större besparing än det låter – integrationerna som håller gammalt och nytt överens under en fasad flytt är ofta det svåraste i hela programmet.
• Snabbare till "klart". En knuff, en driftsättning, och legacy-systemet är avstängt. Ingen utdragen period av att köra två världar.
• Det är begreppsmässigt rent. Alla byter samma dag; det finns inget förvirrande mellanläge där en del data bor här och en del bor där.

Emot:

• Koncentrerad risk. Allt vilar på ett fönster. Om något går fel klockan tre på driftsättningsnatten fattar du ett go/no-go-beslut under maximalt tryck med hela verksamheten väntande.
• Återställning är brutal. Att backa en big bang betyder att återställa allt och förklara en missad driftsättning. Ju senare du upptäcker problemet, desto värre läge.
• Den kräver en beredskap du måste bevisa i förväg. Datan måste vara rätt före fönstret, för det finns ingen andra etapp som fångar det som slank igenom. Det är en hög ribba – och att nå den är precis vad provkörningar och avstämning är till för.

Fasad: för och emot

För:

• Begränsad sprängradie. Om etapp ett (säg ett land eller en division) har problem drabbar det den skivan, inte hela företaget. Du lär dig på en liten population och bär lärdomarna in i nästa etapp.
• Återställning är realistisk. Att backa en etapp är en långt mindre händelse än att backa allt. Beslutet är mindre skräckinjagande, så det fattas på sina meriter.
• Teamet bygger en rytm. Vid tredje driftsättningen är körboken vass och överraskningarna mestadels bakom er.

Emot:

• Samexistens är dyrt och svårt. Medan du är halvmigrerad håller både det gamla och det nya systemet levande data och måste hållas i takt – vilket betyder temporära integrationer, avstämning mellan de två, och regler för vilket system som äger vad. Det är riktig ingenjörskonst, och den är slit-och-släng: du bygger den bara för att riva den.
• Det tar längre tid, och dubbeldriften kostar hela tiden. Du bär två plattformar, två uppsättningar support, och den kognitiva bördan av en mellanvärld i månader.
• Att dela datan är ibland genuint svårt. Delad masterdata, transaktioner mellan bolag, koncernrapportering – vissa saker delar sig inte rent längs en affärsenhets- eller modulgräns, och att tvinga fram delningen skapar egna problem.

Faktorerna som egentligen borde avgöra

Skala bort preferenserna och beslutet kokar ner till en handfull verkliga förutsättningar:

• Tolerans för driftstopp. Kan verksamheten faktiskt vara mörklagd en helg? En dygnet-runt-verksamhet – tillverkning, logistik, vård – kanske inte har något fönster stort nog för en big bang, vilket knuffar dig mot fasning vare sig du vill eller inte.
• Aptit för återställning. Hur katastrofal är en misslyckad driftsättning? Ju mindre verksamheten kan absorbera en dålig driftsättning, desto mer förtjänar en fasad ansats sin omkostnad genom att krympa varje enskilt vad.
• Hur separerbar datan är. Om dina affärsenheter, regioner eller moduler verkligen är löst kopplade är fasning naturligt. Om allt delar masterdata och flöden mellan bolag kan en ren delning kosta mer än den sparar.
• Skala och komplexitet. En handfull system och en avgränsad datamängd kan flyttas i ett omsorgsfullt fönster. Ett vidsträckt, högvolyms-, mångkälligt landskap koncentrerar för mycket risk till en natt.
• Kostnaden och möjligheten för samexistens. Fasning är bara så bra som din förmåga att hålla de två världarna i takt. Om temporär integration är billig och pålitlig är fasning attraktivt; om den är en mardröm talar det för det enda rena snittet.
• Kalenderbegränsningar. Årsbokslut, regulatoriska deadlines, högsäsong i handeln – dessa kan utesluta eller kräva ett fönster oavsett allt annat.

Den ärliga medelvägen

I praktiken är valet sällan rent det ena eller det andra. Vanliga, kloka hybrider:

• Big bang per affärsenhet. Varje division gör sin egen enda driftsättning, men divisionerna går live på olika datum – begränsad risk utan den fulla kostnaden för samexistens på datanivå.
• Fasa historiken, big-banga driften. Ta upp alla på det nya systemet på en gång för levande, öppna transaktioner, och för över historisk data i en senare etapp med lägre insats (eller lämna den sökbar i legacy-systemet).
• En pilot, sedan en big bang. Migrera en liten, vänligt inställd enhet först som en äkta repetition på riktig data, lär av den, och flytta sedan resten tillsammans med körboken bevisad.

Hur du beslutar, konkret

Diskutera det inte i det abstrakta. Gör förutsättningarna explicita och låt dem välja:

1. Skriv ner det driftstopp verksamheten verkligen tål – inte den optimistiska siffran, den verkliga.
2. Bestäm hur illa en misslyckad driftsättning är, i klara verksamhetstermer, och därmed hur mycket återställningssäkerhet är värd att betala för.
3. Testa om datan separerar rent längs linjen du skulle fasa på – delade masters och flöden mellan bolag är där detta brister.
4. Prissätt samexistensen en fasad flytt skulle kräva, ärligt, inklusive det slit-och-släng-integrationsarbete den medför.
5. Välj sedan – och vilket du än väljer är det som faktiskt avriskar det detsamma: profilering, tvätt med tydligt ägarskap, flera provkörningar och riktig avstämning. Driftsättningsstrategin avgör hur risken formas; det disciplinerade dataarbetet avgör om du lyckas.

Det finns inget universellt rätt svar här, och den som ger dig ett utan att fråga om din tolerans för driftstopp och din data har inte förstått frågan. Välj medvetet, av skäl du kan försvara inför en styrgrupp.

Väger du big bang mot en fasad utrullning för din migrering? Hör av dig – jag pratar gärna igenom det.

---

Vidare läsning: Varför datamigreringar misslyckas.