BizTalk Migration

Overview

Migrate from Microsoft BizTalk Server to Apache Camel 4.x using Camel-Kit’s automated parsing capabilities. Camel-Kit analyzes BizTalk orchestrations (.odx), pipelines (.btp), schemas (.xsd), maps (.btm), and port binding files to produce migration candidates for Camel YAML routes; unsupported or ambiguous constructs remain explicit for manual review.

Supported BizTalk versions: 2004, 2006, 2006 R2, 2009, 2010, 2013, 2013 R2, 2016, 2020.

Key features:

• Orchestration (.odx) analysis with 38 recognized shape element names; each recognized shape can be automatic, manual-review, or unsupported for conversion
• Maps (.btm) to canonical DataMapper mappings, rendered as inline Groovy or XSLT by the shared engine-selection rule (45 functoid type mappings)
• Pipelines (.btp) to Camel processor chains
• Port bindings to Camel endpoint configuration
• UTF-16 binding file detection (BizTalk Admin Console exports)

What Gets Parsed

Adapter Mapping

For each BizTalk adapter, the AI proposes a catalog-verified Camel component when a direct mapping exists. Otherwise it records the gap and asks for a target-platform decision.

Note on MSMQ: There is no direct Camel equivalent for MSMQ. When encountered, the AI will ask you to choose between ActiveMQ Artemis (camel-jms), a runtime- and catalog-verified RabbitMQ component such as camel-spring-rabbitmq, or Azure Service Bus (camel-azure-servicebus) as the target messaging platform.

Orchestration Shape Mapping

BizTalk orchestration shapes map to Camel EIPs and route patterns:

Note: The Suspend Shape is NOT supported. BizTalk dehydration has no Camel equivalent - the AI flags this for manual review.

Pipeline Mapping

Map & Functoid Conversion

BizTalk maps (.btm) define transformations through visual functoids. Camel-Kit first extracts the complete semantic mapping, then applies the shared DataMapper rule: inline Groovy when both schemas are absent or the mapping has fewer than 20 leaf fields; XSLT only when the mapping has at least 20 leaf fields and at least one schema.

source.customerName -> target.customerName

<xsl:value-of select="concat(firstName, ' ', lastName)"/>

- choice:
    when:
      - simple: "${body.status} == 'ACTIVE'"
        steps:
          - setBody:
              simple: "Approved"
    otherwise:
      steps:
        - setBody:
            simple: "Rejected"

- enrich:
    expression:
      constant: "sql:SELECT price FROM products WHERE id = :#${body.productId}"
    aggregationStrategy: "#bean:priceEnricher"

- script:
    groovy: |
      // MANUAL REVIEW REQUIRED - illustrative compatible replacement
      def calculateDiscount(amount) {
        return amount > 1000 ? amount * 0.1 : 0
      }
      calculateDiscount(body.amount)

Example: Order Processing Migration

This example assumes OrderToInvoiceMap has at least 20 leaf fields and an available schema, so the canonical engine selection is XSLT; the map is abbreviated below.

<ServiceBody>
  <ReceiveShape Name="ReceiveOrder"
    PortName="OrderPort" Operation="SubmitOrder"/>
  <TransformShape Name="MapOrder"
    Map="OrderToInvoiceMap"/>
  <DecisionShape Name="CheckAmount">
    <Branch Expression="OrderAmount > 1000">
      <SendShape Name="SendHighValue"
        PortName="HighValuePort"/>
    </Branch>
    <DefaultBranch>
      <SendShape Name="SendStandard"
        PortName="StandardPort"/>
    </DefaultBranch>
  </DecisionShape>
</ServiceBody>

- route:
    id: process-order
    from:
      uri: "platform-http:/api/orders"
      parameters:
        httpMethodRestrict: POST
      steps:
        - step:
            id: kaoto-datamapper-a1b2c3d4
            steps:
              - to:
                  id: kaoto-datamapper-xslt-a1b2
                  uri: "xslt-saxon:kaoto-datamapper-a1b2c3d4.xsl"
        - choice:
            when:
              - simple: "${body.amount} > 1000"
                steps:
                  - to: "direct:high-value-processing"
            otherwise:
              steps:
                - to: "direct:standard-processing"

Features Requiring Manual Review

The AI flags the following items for manual review during migration:

• Scripting functoids with C#/VB.NET code - preserved for manual review; compatible Groovy may be suggested, otherwise use a custom processor on Spring Boot or Quarkus
• Custom .NET pipeline components - no automatic equivalent, requires custom Camel processor
• MSMQ adapter - requires replacement decision (ActiveMQ, RabbitMQ, or Azure Service Bus)
• Suspend Shape - no Camel equivalent, redesign required
• EDI Disassembler/Assembler - select a catalog-verified DFDL or Smooks path from the actual EDI format and schema, then review the mapping manually
• External assembly calls in expressions - requires Java/Groovy reimplementation