BizTalk/Migrering

Dolda kostnader i en BizTalk-migrering

De kostnader som överraskar ligger ofta utanför själva arbetsflödet. Gör dem till namngivna poster innan den första migreringsvågen.

Upptäckt före konvertering

Microsofts aktuella migreringsguide lägger teknisk upptäckt och teamets samsyn i den första sprinten. Det arbetet omfattar bland annat inventering, målarkitektur, första backlog och definition av vad den första vågen ska stödja. Räkna därför inte bara antal orkestreringar. Okända beroenden, gemensamma scheman, certifikat, schemalagda jobb och manuella driftsteg blir arbete även om själva workflow-definitionen kan konverteras.

Partnerarbete

EDI- och API-partners behöver kontaktväg, testdata, testfönster och ett godkännande av resultatet. För EDI ligger partner, identiteter, avtal, scheman, kartor och certifikat i eller nära Integration Account-konfigurationen. Den informationen följer inte automatiskt med bara för att en BizTalk-karta eller ett schema kan återanvändas. Planera per partner och protokoll, särskilt när certifikat eller nätverksregler ändras.

Test, cutover och återgång

Microsofts vägledning anger en kommunikationsplan, cutover-plan, generalrepetition, valideringstest, återställningsplan och produktionssupport inför driftsättning. Alla är kostnadsposter. För varje våg behövs representativa positiva och negativa meddelanden, jämförelse av affärsutfall och bevis för omsändning. Om flödet påverkar ekonomi eller order bör verksamheten namnge vem som godkänner resultatet och hur avvikelser hanteras.

Parallelldrift och dubbla verktyg

Under en våg kan både BizTalk och målplattformen behöva licens, övervakning, beredskap och felsökning. Bestäm vilka flöden som verkligen måste köras parallellt och hur dubbletter förhindras. Sätt ett avvecklingskriterium med ansvarig person och datum: exempelvis godkänd belastning, avslutad partnerverifiering och dokumenterad återställning. Utan ett sådant beslut blir tillfällig dubbel drift lätt en permanent kostnad.

Specialkod, kompetens och förvaltning

Egen kod och egna adaptrar kräver ett separat beslut: bygg om, kapsla som API eller ersätt funktionen. Microsoft dokumenterar begränsningar för lokal .NET-kod i Logic Apps Standard, bland annat för stora filer, långvariga funktioner och avancerad batchning. Lägg också tid på identiteter, secrets, nätverk, deployment, larm, loggkostnad och jourrutiner. Målplattformen är inte klar när den första körningen lyckas; den är klar när teamet kan driftsätta, felsöka och återställa den utan projektgruppen.

Räkna på era egna artefakter →