Så blir en POC till ett beslutsunderlag du vågar lita på vid migrering från BizTalk till Azure

En lyckad migrering från BizTalk till Azure avgörs sällan av själva kodflytten. Den avgörs av hur väl man vet vad man ger sig in i innan den börjar. Därför är det andra steget i vår metodik en POC. Den ska inte imponera på kunden med tre snabbt migrerade flöden. Den ska förvandla antagandena från steg 1 till fakta. Den här texten handlar om vad en nyligen genomförd POC lärde oss om vår egen metodik, om verktygen vi använder, och om hur vi bygger ett beslutsunderlag som en beställare ska känna sig trygg med.

Jag leder projektleveranserna på Contica. Min del av leveransen i en POC inför en migrering från BizTalk till Azure är att kunden får ett beslutsunderlag som håller hela vägen till produktionssättning, och till sist när BizTalk stängs ner. Underlaget innehåller en fullständig projektplan baserad på verifierad data, så att kunden kan bemanna och budgetera för en fullständig migrering. Nyfiken på att djupdyka i vår metodik? Läs vidare, så hittar du länken längst ner i artikeln.

Vad en POC i en migrering faktiskt är till för

En POC i en BizTalk till Azure-migrering är inte ett sidospår för att visa tempo. Den är estimeringsmotorn. Efter analysen, som görs av våra egenutvecklade verktyg för att skanna kundens BizTalk, väljer vi ut tre representativa integrationer av olika svårighetsgrad, migrerar dem på riktigt, och mäter vad det faktiskt kräver i tidsåtgång. Ur det växer ett beslutsunderlag som är långt mer än en kalendertid.

Det är här vår metodik visar sin styrka i ett tidigt skede. Hela syftet med den är att leverera ett underlag kunden kan agera på, byggt i fyra steg: en analys av nuläget, en POC som bevisar och validerar takten, ett beslutsunderlag med projektplan och estimat, och därefter en vågbaserad migrering. I vår nyligen genomförda POC följde vi den ordningen. Analyserna av BizTalk och Azure var redan genomförda och överlämnade med gott resultat, och POC:en var nästa steg.

Underlaget som växer fram svarar på de frågor en beställare behöver kunna ta vidare i beslutsordningen: vad migreringen kostar, hur målarkitekturen i Azure ser ut, hur projektet ska levereras i kontrollerade etapper i form av vågor, och total tidsåtgång för migreringen. Utifrån kundens deadline får man dessutom full koll på vilken bemanning som krävs för att lyckas. Med de svaren på plats blir tidslinjen väldigt konkret. Man vet hur man hinner stänga ner BizTalk i god tid före sin deadline, exempelvis slutet på mainstream-supporten som är den 11 april 2028, och vad som krävs för att ta sig dit.

Det är den verkliga poängen. Ett företag som migrerar gör det sällan för migreringens egen skull. Man gör det för att man måste lämna en plattform som når sitt slut, och för att man vill stå med något bättre på andra sidan. En POC som är rätt genomförd ska säkra möjligheten att lyckas: en trygg väg ut, och en modern integrationsplattform i Azure som verksamheten kan bygga vidare på.

Från analys till tre flöden, tillsammans med kunden

Innan POC:en började satte vi oss ner med kundens team kring resultatet av analyserna, som precis genomförts. Den workshopen fyllde två syften. Det första var att validera rapporternas innehåll tillsammans. En del handlade om att gå igenom det som BizTalk-skanningen hittat. I det här fallet hade vi även genomfört vår Azure Foundation Screening på kundens Azure-miljö, för att hitta rätt åtgärder för en trygg grund inför migreringen. Tillsammans med kundens egna experter blev det en givande och konstruktiv workshop. Det andra syftet var att gemensamt välja ut de tre integrationer som skulle ingå i POC:en, en enkel, en medelkomplex och en komplex, för att täcka spannet i beståndet och få ett representativt bedömningsunderlag.

Just löpande validering är viktig i metodiken vi tagit fram. Kunden ska vara så involverad som krävs genom hela POC:en, dels för att vara med och fatta strukturellt viktiga beslut som namnstandard, infrastruktur och målarkitektur, dels för att underlätta rättigheter och rätt åtkomst.

Verktygen och stacken möter en verklig miljö

“Arbetet vilar på att vi förstår nuläget på djupet innan vi rör något. Till det använde vi våra egenutvecklade verktyg för analys av både BizTalk och Azure. De läser bindningsfiler och källkod direkt och bygger en strukturerad bild av miljön. I det här projektet innebar det att vår utvecklare i praktiken knappt behövde gå in i den gamla BizTalk-miljön manuellt. Fakta fanns redan strukturerade och redo att arbeta vidare på.

Men flödena är den del som syns. Det mesta av arbetet ligger under dem, i grunden som hela integrationsplattformen vilar på. Den grunden måste vara stabil innan en enda integration kan flyttas: landing zones, nätverk, security, identity, CI/CD och en namnstandard som vilar på best practice med målet att hålla över tid. Här utgick vi från vad analysen visat och förde löpande dialog med kunden, så att grunden blev en integrationsplattform anpassad efter kundens miljö snarare än en mall. Våra rekommendationer vilade på etablerade ramverk, framför allt Microsofts Well-Architected Framework och Cloud Adoption Framework, och vi använde vårt bibliotek av beprövade templates för att sätta upp de delar som krävdes. En viktig sak i varje uppsättning är fokus på förvaltningsbarhet. En grund som är byggd rätt från start blir billigare och tryggare att förvalta långt efter att migreringen är klar, och det är där en stor del av det verkliga värdet ligger.

Först ovanpå den grunden kom själva migreringen av våra tre utvalda integrationer. För det använde vi Microsofts Logic Apps Migration Agent, ett öppet verktyg byggt för att ta BizTalk-artefakter till Azure Logic Apps Standard. Verktyget gjorde ett starkt jobb på två av de tre integrationerna. På det tredje flödet gick det inte optimalt, så vi gjorde det vi alltid gör i ett sånt läge: vi stannade upp, utvärderade, och växlade väg för att säkra framdrift. Vi gick över till Claude CLI tillsammans med de skills vi byggt in i vårt eget arbetssätt, och fick bättre flyt på just det flödet.

Den lärdomen är viktigare än den låter. Poängen är inte att ett verktyg var rätt och ett annat fel. Poängen är att vi äger arbetssättet och väljer rätt verktyg i rätt läge, i stället för att låsa oss vid ett. Logic Apps Migration Agent löser konverteringen av flödena, men stacken runt omkring är bredare än så, och det är helheten som skapar framgång i en total migrering. Verktygen är medel. Underlaget är målet.

Kan man lita på AI i en migrering från BizTalk till Azure?

Ja, men inte tack vare AI i sig. AI gör arbetet snabbare bara när den har rätt kontext att arbeta på, och när en människa granskar det den producerar. I vår metodik är det därför analysen kommer först. Analysen skapar ett omfattande och verifierat underlag som en AI kan resonera utifrån. Att säkerställa att kontexten stämmer är avgörande, och först då har vi rätt förutsättningar för en process där AI tillför verkligt värde. Det är skillnaden mellan tempo och en dyr omväg.

Vad estimaten lärde oss om vår egen klassificering

I analysen klassar vi varje integration efter komplexitet. Det är ett utmärkt diskussionsunderlag, men POC:en påminde oss om att verkligheten inte alltid följer klassningen. Ett flöde som ser komplext ut på pappret kan visa sig vila på enkel logik. Ett som ser enkelt ut kan dölja besvärliga beroenden till andra system som drar ut på tiden.

Slutsatsen är inte att klassificeringen är fel, utan att den ska behandlas som en utgångspunkt som revideras allteftersom fler flöden migreras. Det är just därför vi mäter på representativa flöden i stället för att lita på en magkänsla. Enskilda flöden slår åt båda håll. Det är när man väger samman dem som estimatet blir trovärdigt, och det är den helheten en beställare behöver för att kunna planera den fullständiga migreringen. Det är också så här vi hanterar estimatet under själva migreringsprojektet, som något som utvärderas efter varje sprint och våg, där vi löpande letar optimeringsmöjligheter. Målet är transparens och trygghet i hur projektet går, vad det kommer att ta i tid och hur det stämmer mot budget.

Migrering är inte bara kodflytt

En sak till blev tydlig under arbetet. Moderniseringen kom som ett naturligt resultat av hur vi arbetar. På flera ställen kunde vi ta bort beroenden som inte längre behövdes och ersätta äldre konstruktioner med mer moderna. Den typen av modernisering skedde naturligt under migreringen och gav ett bättre utgångsläge i Azure, utan att projektet svällde. En migrering ska inte skapa en kopia av den gamla miljön, utan en renare och optimerad version av den.

Därför utvärderar vi oss själva

Det som binder ihop allt det här är att vi utvärderar metodiken, verktygen och oss själva efter varje POC. Inte för att något nödvändigtvis gick fel, utan för att det är så vi håller oss trovärdiga och pålitliga. Varje genomfört projekt skärper nästa estimat, varje verktygsväxling lär oss något om var gränserna går, och varje klassning vi får justera gör nästa analys ännu mer träffsäker.

För kunden betyder det konkret en sak. När POC:en är klar står kunden inte med en gissning, utan med ett beslutsunderlag att agera på: kostnad, målarkitektur, en vågbaserad projektplan och en bemanning som ser till att leveransen sker innan utsatt deadline. En plan som visar hur kunden hinner släcka ner BizTalk i tid, och i slutet av migreringen i stället står med en modern integrationsplattform i Azure som är redo för det verksamheten vill göra härnäst.

Vill du resonera om metodik, lärdomar och vad det faktiskt innebär att driva ett projekt så komplext som en migrering från BizTalk till Azure i mål, ta med ditt problem till oss så pratar vi. Du kan också läsa mer om vår metod för migrering från BizTalk till Azure.