AWS som målplattform
AWS kan vara rätt när identitet, kompetens och driftmodell redan finns där. Det är inte en ensam BizTalk-ersättare: AWS dokumenterar flera tjänster för workflow, kö, pub/sub, event routing och EDI som måste sättas ihop efter flödets krav.
Välj meddelandetjänst efter semantik
AWS Decision Guide skiljer mellan SQS för köad punkt-till-punkt-kommunikation, SNS för pushbaserad pub/sub och EventBridge för regelstyrd event routing. EventBridge garanterar inte ordning; SQS FIFO kan ge ordning inom sin modell. Översätt därför inte en BizTalk subscription till EventBridge utan att först skriva ned krav på ordning, persistens och återleverans.
Workflow är en separat byggsten
Step Functions är AWS-tjänsten för sekvenser, villkor, parallella grenar, felhantering och retries. Ett state machine-flöde ersätter inte automatiskt maps, partneravtal eller en broker. Inventera vilka delar som är processlogik och vilka som behöver SQS, SNS, EventBridge, Amazon MQ eller egen kod.
Avgränsa EDI-påståendet
AWS B2B Data Interchange dokumenterar i dag konvertering mellan X12 och JSON eller XML. AS2- eller SFTP-transport kan läggas i AWS Transfer Family. Det är inte underlag för att lova en rak flytt av EDIFACT, alla acknowledgements eller ett befintligt BizTalk-partnerregister; kontrollera dokumenttyp och partnerflöde separat.
Ingen automatisk BizTalk-konvertering
AWS-källorna beskriver tjänsternas funktion, inte en BizTalk-parser eller migreringsagent. Schemas, maps, bindings, pipelinekomponenter och BRE-regler behöver därför inventeras och mappas manuellt till måltjänster. Kör ett komplett flöde med transport, transformation, felväg och replay innan plattformen väljs för resten.
När AWS är ett dåligt val
Om teamet saknar AWS-IAM, nätverk, drift och kostnadsuppföljning blir migreringen samtidigt ett kompetens- och styrningsprojekt. Jämför hela tjänstekedjan och dess operativa ägarskap med andra mål, inte priset för en Step Functions-körning med en gammal BizTalk-licensrad.