En BizTalk-migrering till Azure ser inte ut som den gjorde för sex månader sedan. AI ensam fixar den inte, men använd rätt, inuti ett strukturerat arbetssätt och tillsammans med människor som kan plattformen, förändrar den vad som är möjligt. Det var kärnan i webinaret vi höll den 27 maj tillsammans med Microsoft, och här går vi igenom det viktigaste.

Webinaret hölls av Robin Wilde (Ansvarig för affärsutveckling, Contica), Ahmed Bayoumy (CTO, Contica, Azure MVP) och Harold Campos (Principal Product Manager för Azure Logic Apps, Microsoft). Inspelningen har kapitelmarkörer, så du kan hoppa direkt till det avsnitt som rör din situation.

FOMU: oron ingen pratar om

BizTalk fungerar. Det är att flytta från det som är svårt. Plattformen rullar, alla vet att den rullar, och i samma sekund något går sönder hör verksamheten av sig: vad hände med integrationen som faktiskt fungerade?

Det är därifrån frågorna kommer. Vilken målarkitektur är rätt i Azure? Behöver vi Logic Apps, Functions, Service Bus? Vad kommer plattformen att kosta, och hur lång tid tar det egentligen? Och under allt detta ligger en tyst oro. På webinaret kallade vi den FOMU, fear of messing up. Inte FOMO. Den som ingen pratar om. Hela poängen med webinaret var att göra den oron mindre.

Varför BizTalk-migreringar stannar innan de börjat

På papper är en BizTalk-migrering en rak linje. Du kartlägger din BizTalk-miljö, gör en arkitekturanpassning, bygger en landningszon, väljer moln eller hybrid, migrerar och går i produktion. Tydliga steg, logisk ordning.

I verkligheten loopar de stegen. Scoping drar ut på månader för att något är odokumenterat och ingen riktigt vet vem som äger vad. Arkitekturen görs om mitt i projektet, eftersom besluten togs för tidigt och utan tillräcklig kontext. Experter för flera olika system fortsätter fakturera medan ingenting levereras. Stegen återställs varv efter varv, men budgeten gör det inte. Den loopar inte, den växer. Resan ser klar ut. Loopen är det som dödar projektet.

Det här är en verklig deadline, inte en hypotetisk. Stödet för BizTalk Server fasas ut mot slutet av decenniet, och varje kvartal i loopen kostar pengar utan att flytta dig närmare målet.

AI räddar dig inte. Och brute force är inte svaret

Den vanligaste reflexen just nu är att tro att AI fixar hela migreringen. Det gör den inte. Och den naivaste varianten, att kasta hela BizTalk-miljön på en stor språkmodell och be den lösa det, går rakt in i väggen.

Skälet är konkret. Du har en token-budget, och en migrering av den här storleken bränner den på några dagar. Agenter som läser om allt, gör nya försök och sammanfattar om träffar på kontextväggen snabbt, och chunking löser inte problemet. Sammanfattade delar tappar sambanden mellan artefakter, och du står kvar utan en användbar scope och utan ett försvarbart svar. Dyrt, långsamt, inte spårbart, inte repeterbart. Det är inget arbetssätt.

Vad betyder det att tänka som en agent?

Att tänka som en agent betyder att kopiera det sätt en AI-agent faktiskt arbetar på och tillämpa det på migreringen: läs, sök, matcha, bygg. En agent läser det den får, söker i en kunskapsbas, matchar innehållet mot behovet och bygger sedan något. Vi vände på perspektivet och lät vårt eget arbetssätt följa exakt samma mönster.

I en BizTalk-kontext betyder det: läs artefakterna i miljön, sök i best practices och beprövade lösningar, matcha fynden mot din egen stack av mallar och standarder, och bygg först därefter. Samma mönster upprepas i varje steg, så att ingenting missas. Vinsten är att varje steg producerar ren kontext för steget efter, i stället för antaganden som måste göras om senare.

Börja med vad du har, inte vad folk minns

Integrationer är långlivade. En lösning byggd för sex eller tio år sedan har ofta en eller två personer som kan den, och dokumentationen är antingen borta eller utspridd. Det traditionella svaret har varit workshops, intervjuer och scope byggd på antaganden.

Men dokumentationen finns. Den sitter i BizTalk. För en odokumenterad miljö behöver vi egentligen bara två saker, bindningsfilen och källkoden, körda genom en sekvens av skript som arbetar deterministiskt och tar in AI i specifika steg. Vårt analysverktyg BixRay gör det här. För de största miljöerna tar det runt 15 minuter, och resultatet är full visibilitet: vilka orchestrations som finns, hur de hänger ihop, vilka externa beroenden de har, komplexitet och risksignaler. Det här är inte tre workshops och tio möten. Det är scope baserad på fakta, inte gissningar i kostym.

Moln eller hybrid?

Många tror att BizTalk till Azure tvingar dem upp i molnet. Det stämmer inte. På webinaret var Harold tydlig: hybrid är ett fullt understött alternativ, där Logic Apps kan köras on-premises i containrar.

I en hybriduppsättning ligger körtid och data kvar on-premises. Kontrollplanet finns i molnet, i portalen, men dataplanet och datat lämnar aldrig din miljö. Det enda som går till molnet är faktureringsinformation från infrastrukturen. För verksamheter med krav på latens, regelefterlevnad eller isolering är det ofta det mest logiska valet, och för många blir svaret en kombination av moln och hybrid snarare än ett antingen eller.

Agents propose, architects decide

Grunden, landningszonen, är det steg där det är lätt att tappa kontrollen. Vår stack består av en single source of truth med drygt 50 dokument, över 80 justerbara mallar och verktyg, och egna MCP-servrar. Det är för mycket för en arkitekt att hålla i huvudet, särskilt när en standard kan ha uppdaterats igår.

Det är här AI gör verklig nytta. Med scope-kontexten från BixRay som utgångspunkt söker och matchar agenterna rätt delar ur stacken mot just din miljö, och föreslår en grund: landningszon, identitet och RBAC, nätverk, säkerhetsbaslinje och övervakning. Men agenterna beslutar inte. Arkitekterna validerar, justerar och godkänner, och loopar tillbaka tills grunden klarar granskning. Agenterna föreslår. Arkitekterna beslutar. Grunden är rättdimensionerad från dag ett.

The Migration Factory – eller på svenska, Migreringsfabriken

När scope, standarder och grund finns på plats startar själva migreringen med hela bilden, inte ett tomt blad. Microsofts Logic Apps Migration Agent sköter konverteringen, och vi pluggar in vår kontext, våra standarder och vår grund. Varje flöde migreras med rätt struktur från början.

Agenten tvingar dig inte in i ett visst arbetssätt. Den är öppen källkod, upptäcktsdelen går att anpassa till andra källsystem än BizTalk, och du behåller dina egna mallar och äger din infrastruktur. Som Harold påpekade är den i praktiken mer en refaktoreringsagent än en ren migreringsagent: den bygger en fungerande lösning, skapar syntetisk testdata, kör igenom happy path och felfall, och kan lägga till black box-testning mot dina egna målsystem. Det är så vi knyter ihop hela kedjan, från första mötet till att BizTalk kan stängas av. Det är det vi kallar The Migration Factory. Du hittar information om vårt migreringserbjudande här.

Så här hänger det ihop

Migreringsstegen är desamma som de alltid varit. Det som har förändrats är att rätt AI-verktyg används i rätt ögonblick, och att arbetet börjar långt innan själva konverteringen. Scoping som tog månader kan göras på minuter. Grund och mallar kan komma på plats på en vecka. Den tekniska delen av en BizTalk-migrering till Azure behöver inte längre ta år.

Du behöver inte vara AI-redo som organisation för att börja. Det handlar om ett nytt sätt att arbeta, steg för steg, där varje steg skapar kontexten för nästa. Och därifrån kan du flytta snabbare till en modern plattform och lägga tiden på det som faktiskt skapar affärsvärde.

Vill du se hela genomgången, med demo av BixRay och Logic Apps Migration Agent samt diskussionen om moln kontra hybrid, finns webinaret att se i sin helhet på YouTube: Webinar: How AI Cuts BizTalk Migration From Years to Weeks. Inspelningen har kapitelmarkörer så att du kan gå direkt till det som rör din miljö.

Och om du vill prata om din egen situation kan du alltid boka 30 minuter med våra ingenjörer. Berätta var du har fastnat, så säger vi hur vi skulle angripa det. Din miljö, dina beroenden, ingen säljpitch.