Egna adaptrar och pipeline-komponenter
Egen BizTalk-kod kan bära protokoll, säkerhet, streaming, batching eller ett historiskt workaround. Microsofts Migration Agent listar inte custom adapters eller component assemblies som egna stödda artefakttyper, så de ska inventeras från källkod och deploymentpaket.
Läs koden och deploymenten
Inventera target framework, externa bibliotek, GAC-beroenden, certifikat, config, trådning, timeout, retry och vilka context properties komponenten läser eller skriver. Sök även i MSI, bindingfiler och serverinstallationer; en assembly kan vara produktionskritisk utan att ligga i samma solution som den pipeline som anropar den.
Välj minsta ersättningsyta
Om en dokumenterad connector täcker protokoll och autentisering, använd den och behåll bara den unika logiken. Om ett internt system redan har ett stabilt REST- eller SOAP-API kan en custom connector ge återanvändbara triggers och actions. Bygg inte en ny connector när ett vanligt HTTP-anrop och tydligt schema räcker.
Placera lokal kod inom dess gränser
Standard-workflows kan köra lokal .NET-kod och Microsoft nämner BizTalk-modernisering som scenario. Samma dokumentation avråder från modellen för körningar över tio minuter, stora transformationer, komplex batching/debatching och strömmande pipelinekomponenter. Dessa fall behöver en separat tjänst eller annan runtime.
Behandla det som en produkt
Kod som flyttas behöver repository, byggbar version, dependency scan, testdata, larm och en namngiven ägare. Dokumentera input, output och felkontrakt innan omskrivningen börjar. Att en gammal DLL går att referera är inte samma sak som att den kan patchas och drivas efter att BizTalk-teamet upplösts.
Bevisa beteendet före avveckling
Kör representativa payloads, gränsvärden, timeout, ogiltigt certifikat och beroendefel genom gammal och ny komponent. Mät minne och throughput om koden streamar eller batchar. Behåll rollback tills målkomponenten både ger rätt affärsresultat och producerar tillräcklig diagnostik för den som har jour.