Vanliga misstag i en BizTalk-migrering

Att välja målplattform före inventeringen

Ett målval före inventeringen gör att alla problem ser ut som målplattformens problem. Diskussionen handlar sedan om produkten i stället för om era flöden.

Börja i stället med beroenden, driftkrav och vilka flöden som faktiskt bär risk. Målbilden kan mycket väl bli densamma, men då vet ni varför — och ni vet vilka flöden som inte passar den.

Att räkna artefakter i stället för beteende

Antalet orkestreringar är en startpunkt, inte en budget. Två miljöer med lika många orkestreringar kan ändå kräva olika mycket arbete.

Det som styr är beteendet omkring dem:

• korrelation och convoy-mönster, som är svåra att återskapa av någon som inte skrev dem
• egna pipeline-komponenter och adaptrar i .NET som ingen längre äger
• BRE-policies som läser databasfakta, vilka inte följer med rakt av
• EDI-partners, där ombordningen sker i motpartens takt och inte i er

Att blanda flytt och förbättring

Om ni migrerar och refaktorerar samtidigt blir det svårare att avgöra om en avvikelse beror på flytten eller på ändringen. Separata acceptanskriterier gör orsaken lättare att isolera.

Flytta först så att beteendet går att jämföra rad för rad. Förbättra sedan, som ett eget beslut med egna acceptanskriterier.

Att migrera flöden som borde avvecklas

En inventering kan hitta orkestreringar utan trafik: säsongsflöden, integrationer mot avstängda system och testflöden som blev kvar i produktion.

Kontrollera faktisk trafik och ägarskap per flöde innan ni estimerar. Ett avvecklat flöde behöver inte byggas på nytt.

Att glömma avvecklingen

Migreringen är inte klar när det nya flödet kör. Den är klar när gammal runtime, host instances, jobb, certifikat, brandväggsregler och övervakning är avvecklade — och när någon har bekräftat att de är det.

Utan ett avvecklingsdatum i planen blir parallelldriften permanent, och ni betalar för två plattformar i flera år.