Replacing the BizTalk MessageBox with an open-source broker
RabbitMQ exchanges or Apache Kafka topics can take over the publish-subscribe routing that the BizTalk MessageBox performs today, but they replace only the delivery layer. Subscriptions, correlation and tracking have to be rebuilt as Apache Camel routes, message headers and monitoring, so the broker is one part of the Camel-based target, not a drop-in swap. The MessageBox also holds state for orchestrations, retries and tracking data, and each of those needs an explicit owner in the new design before any queue is provisioned.
Start by inventorying every subscription in the MessageBox, grouped by the filter expressions on promoted properties, because each filter becomes a routing decision in Camel or a binding key on the broker. For RabbitMQ, decide between a topic exchange with routing keys and header exchanges, and use quorum queues for durable consumers, since classic queue mirroring was removed starting with RabbitMQ 4.0. For Kafka, decide how messages are keyed, because per-key ordering depends on partition keys, and confirm that the chosen topics meet your ordering needs before you rely on them for correlated business events.
Plan the broker's own lifecycle and security early. RabbitMQ 4.2 community support ended on July 31, 2026, so confirm the version you deploy against the RabbitMQ release information and whether you need commercial support. For Kafka, confirm your cluster runs in KRaft mode, since ZooKeeper mode was removed in 4.0, and set SASL and TLS listeners and ACLs before any production traffic. Monitoring changes too: BizTalk tracking data will not appear in the broker, so define which broker metrics, consumer lag or queue depth alerts, and Camel route logs replace the old tracking views.
Mapping MessageBox capabilities to RabbitMQ and Kafka
This table maps each MessageBox capability to a RabbitMQ or Kafka construct and marks where coverage is partial or missing. Read the coverage column as a design starting point, since several BizTalk behaviors must be rebuilt in code, configuration or a tracking store. The main takeaway is that the broker covers transport, durability and replay well, while subscription predicates, correlation and tracking need deliberate design.
| Capability | RabbitMQ | Kafka |
|---|---|---|
| Publish | Producers publish to an exchange, which routes messages to bound queues based on routing keys or headers. | Producers write records to a topic, optionally keyed so related records share a partition. |
| Subscription filtering | Partial: direct, topic and headers exchanges filter by key or header values, but there is no equivalent of BizTalk's XPath-style predicates on message content. | Partial: consumers subscribe to topics, and content filtering is done in consumer code or Kafka Streams, not by the broker. |
| Persistence | Quorum queues are durable, replicated queues based on the Raft consensus algorithm. Classic queue mirroring was removed starting with RabbitMQ 4.0. | Records are written to a retained log per partition, with retention set by time or size per topic. |
| Redelivery and dead-lettering | Acknowledgements, requeue on failure and dead-letter exchanges cover retry and poison-message handling. Retry counts and backoff are configured or coded. | No built-in acknowledgement per message. Consumers track offsets, so retries and dead-letter topics are built in the consumer application. |
| Ordering | Order is guaranteed per queue for a single consumer. Competing consumers on one queue can process messages out of order. | Order is guaranteed within a partition. Use a stable key so related messages land on the same partition. |
| Correlation | Gap: no native correlation sets like BizTalk orchestrations. Correlation IDs travel in headers and the consuming service must match them. | Gap: no native correlation sets. Keys and state stores in a stream processor can hold correlation state, but this is application code to design and test. |
| Tracking and monitoring | Gap: the broker's management interface and metrics show queue depth and throughput, not business-level message tracking. Build tracking with OpenTelemetry or a message store. | Gap: consumer lag and broker metrics are available, but BizTalk's message tracking and business activity views have no direct equivalent. Plan a tracking store. |
| Support and licensing | Community support follows release dates, and longer support requires a commercial support license. Confirm the current lifecycle on the vendor site. | Apache-2.0 with no paid edition from the project. Supported releases and Java requirements change by version, so confirm the target release before design. |
When RabbitMQ or Kafka fits the MessageBox role
The MessageBox does three jobs: it stores messages, matches them to subscriptions and tracks what each subscriber has received. RabbitMQ and Apache Kafka both cover parts of that role, but they model messages differently, so the choice depends on how your subscriptions and replay needs look today.
RabbitMQ for routed messaging
RabbitMQ was originally built around AMQP 0-9-1, and AMQP 1.0 became a core protocol in RabbitMQ 4.0. Its exchanges and bindings map closely to BizTalk subscription filters, so routing rules move most directly when most consumers want individual messages. Quorum queues, based on the Raft consensus algorithm, provide durable replicated delivery. Check that your subscriber count and routing patterns fit queue semantics, and confirm the current support windows on the RabbitMQ release information page.
RabbitMQ streams for replay
RabbitMQ Streams provide high-throughput, append-only access for consumers that need to read the same data more than once. This is closer to the replay behavior some BizTalk teams rebuild by hand from tracking data. Streams sit alongside classic and quorum queues in the same broker, so you can separate command traffic from event history. Test consumer offsets, retention and disk sizing against your own message volumes before committing.
Apache Kafka for partitioned event logs
Kafka stores events in partitioned, replicated logs, and consumer groups divide partitions among instances. It suits high-volume event streams where many independent services read the same events at their own pace. Kafka is released under Apache-2.0 with no paid edition from the project itself. Note that since Kafka 4.0 it runs only in KRaft mode, and ZooKeeper clusters must migrate to KRaft before upgrading.
Kafka trade-offs for per-message routing
Kafka has no broker-side equivalent of BizTalk filter expressions. Message selection moves into consumer code or into a stream processor, which changes where your business rules live and how they are tested. Ordering is guaranteed within a partition, not across the topic, so correlation keys must be chosen with care. Plan for this rework before assuming Kafka will reproduce MessageBox routing one to one.
Authentication and authorization on each broker
Kafka supports SSL and SASL mechanisms including SCRAM and OAUTHBEARER, and its StandardAuthorizer stores ACLs in the cluster metadata log. Resources without ACLs are restricted to super users unless allow.everyone.if.no.acl.found is set to true. RabbitMQ has its own user, vhost and permission model. Map each BizTalk host and adapter identity to a broker identity, and confirm the exact configuration against the security documentation for the version you deploy.
Operating cost and support windows
Both brokers are open source, so license cost is not the main line item. Operations are: clusters, upgrades, certificates, monitoring and on-call. RabbitMQ community support has fixed end dates, and commercial support is available through a Broadcom support license, so ask for current lifecycle terms before choosing a version. Kafka releases follow a time-based plan with bugfix releases only for supported versions. Ask any support provider what they cover for each.
How BizTalk subscriptions and correlation map to exchanges and topics
BizTalk subscriptions are property-based filters that the MessageBox evaluates for every message, while RabbitMQ and Kafka do not offer that model directly. In RabbitMQ, producers publish to an exchange, and the exchange type (direct, topic, headers or fanout) decides which queues receive a copy, using binding keys or message headers. A subscription that tests several promoted properties with equality and range conditions usually becomes a topic exchange with a routing key convention, or a headers exchange, and any condition the binding cannot express moves into a consumer. In Kafka, a consumer reads a whole topic, so filtering happens in application code, in Kafka Streams, or in a Camel route that filters before calling downstream systems. Each BizTalk filter needs an owner who decides which of these three places it lives.
Correlation sets and long-running orchestration state have no direct equivalent on either broker. A BizTalk orchestration that waits for a second message keyed on an order number stores that state in the MessageBox and resumes when the match arrives. In a Camel design, the usual options are an aggregator EIP that holds partial messages until a completion condition is met, a state store such as a key-value store, or rows in an application database keyed on the correlation value. Each option changes timeout behavior, restart recovery and the audit trail, so the choice should be made per interface in a design review. That review should list every correlation set, its timeout, its duplicate handling and the team that will answer when a message stays unmatched.
Guaranteed delivery and ordering in each broker
RabbitMQ gives guaranteed delivery through a combination of durable queues and acknowledgements rather than through a single setting. Quorum queues are durable, replicated queues based on the Raft consensus algorithm, and they are the replicated structure to use for work that must survive a node failure. Classic queue mirroring was removed starting with RabbitMQ 4.0, so teams moving from older BizTalk-style designs cannot carry over a mirrored queue pattern and should plan for quorum queues from the start.
- Quorum queues: Messages are written to a majority of replicas before they are considered safe, which is the basis for delivery guarantees during node loss.
- Publisher confirms: The publishing application waits for the broker to confirm each message, so a publisher can retry anything the broker did not accept.
- Consumer acknowledgements: Manual acknowledgements let a consumer keep a message unacknowledged until its work, such as writing to a downstream system, has finished.
- Redelivery and dead-lettering: Unacknowledged messages return to the queue, so consumers must be idempotent, and repeated failures need a dead-letter path.
- Ordering: A single quorum queue delivers in order for one consumer, but competing consumers break that order, so confirm which flows need strict sequence.
Before cutover, ask your RabbitMQ administrator to confirm which queue type each flow uses and to test broker restarts, node loss and consumer crashes with messages in flight.
Apache Kafka stores each topic as a replicated, append-only log. Durability depends on replication settings and on what the producer waits for before treating a write as complete, so the design lives mostly in configuration and in how applications handle retries. Kafka 4.0 and later run only in KRaft mode, so a new cluster has no ZooKeeper dependency, and clusters migrating from ZooKeeper must move to KRaft before upgrading to 4.x.
- Replication and acknowledgement: A producer with acks set to all, together with an adequate replication factor and minimum in-sync replicas, avoids acknowledging writes that a single broker could lose.
- Producer retries and idempotence: Idempotent producers prevent duplicate records from producer retries within a session, but they do not make the whole pipeline exactly once.
- Consumer offsets: Consumers commit offsets after processing, so a crash between processing and committing causes reprocessing that the consumer must tolerate.
- Ordering within a partition: Records keep their order inside one partition only, so the message key determines which records share an order.
- KRaft authorization: The StandardAuthorizer stores ACLs in the cluster metadata log, and resources without ACLs are restricted to super users unless allow.everyone.if.no.acl.found is set to true.
Before cutover, ask the platform team to confirm the replication factor, minimum in-sync replicas and ACL model, then test broker failover and consumer restarts against the exact keys and partition counts you plan to use.
Neither broker provides exactly-once processing across an entire business transaction on its own. Exactly-once behavior within Kafka applies to specific read-process-write paths, and RabbitMQ deliveries remain at-least-once unless consumers deduplicate. Global ordering across all messages is also not something either platform offers at scale, because ordering is scoped to a queue or a partition. The BizTalk MessageBox offered a single transactional store, so teams should expect to rebuild those guarantees explicitly.
- Idempotent consumers: Store a business key or message identifier and skip work that has already been completed.
- Scoped ordering: Choose keys or queues per entity, such as an order or account, rather than one global sequence.
- Outbox pattern: Write the business change and the outgoing event in the same database transaction, then publish from the outbox.
- Compensation: Define how a partially completed multi-step flow is reversed when a downstream system rejects a message.
- Tracking: Carry correlation identifiers in headers so monitoring can reconstruct a flow after a redelivery.
Ask your architects to document, for each business flow, which guarantee is required and where deduplication happens, and to review that document with the security and compliance teams.
Delivery guarantees only matter once they have been exercised under failure. Run the same failure tests against each broker you choose, using the message types, volumes and consumer code that will run in production. Record what happens to in-flight messages, duplicates and ordering, and compare the results with the BizTalk behavior your business currently depends on. Testing should include the failures that are easiest to forget, such as a restart during a rebalance or a consumer that dies after processing but before acknowledging.
- Broker failure: Stop a RabbitMQ node or a Kafka broker during publishing and confirm that no accepted message is lost.
- Consumer crash: Kill a consumer before and after its acknowledgement or offset commit, and count duplicates.
- Partition or queue rebalance: Add or remove consumers and check that per-key ordering holds.
- Poison messages: Send malformed payloads and verify that they reach a dead-letter path or an error topic without blocking the flow.
- Recovery evidence: Keep logs and test results that an auditor can review.
Ask the testing team to confirm the failure scenarios in writing before work starts, and make a passing run of them a condition for each wave of migration.
What changes for monitoring and tracking
BizTalk gave operators one place to see messages, tracking events and health in the same SQL Server estate that held the MessageBox. Moving to a broker and Camel splits that visibility across the broker, the routes and a tracing backend, so each signal needs a deliberate owner before cutover.
Replace Health Monitor and tracking
BizTalk Health Monitor and the Admin Console tracking database show host instances, send and receive ports and orchestration state. In Camel, the equivalent is broker metrics for queues and exchanges, Camel route metrics for exchanges and failures, and distributed tracing across hops. Map each BizTalk screen or report to a named signal before you decommission it, and confirm that your chosen metrics stack can scrape both the broker and the Camel runtime.
Message bodies leave SQL Server
In BizTalk, operators can query message context and tracked bodies with SQL, which many support teams use for ad hoc investigations. Broker messages are not indexed in a relational store, so a body-level search needs a deliberate design: a log or search store fed by selected fields, or a tracing payload policy. Decide which fields may be captured, mask personal and payment data, and document the query path support staff will use.
Re-establish retention and audit
BizTalk tracking retention and purge jobs were set and reviewed by the BizTalk team, and audit evidence often came from the same database. Brokers and tracing backends each have their own retention settings, and dead-letter and log stores may keep data for different periods. Write down retention per signal, who approves changes, and how an auditor will reconstruct a transaction from logs, broker records and trace data. Confirm the retention options in your broker and observability tools before you commit.
Alert on dead letters and lag
MessageBox problems often surfaced as suspended messages or growing queues that operators checked by query. In a broker design, the equivalent alerts are dead-letter queue depth, consumer lag on Kafka topics and unacknowledged or aging messages on RabbitMQ queues. Set thresholds per integration flow, route dead letters to a named owner, and test that an alert fires when a consumer stops. Confirm how your broker exposes these counters, since metric names and dead-letter behavior depend on the queue type you choose.
Choose the stack with your team
The tools that collect metrics, logs and traces are a separate decision from the integration design. Plan the collector, storage, dashboards and access controls as their own workstream, and assign ownership for each dashboard that replaces a BizTalk report. The observability pillar covers the self-hosted options if you need a comparison, but the integration team should first agree on the signals listed above.
Moving MessageBox routing without losing in-flight messages
This sequence moves publish-subscribe routing from the MessageBox to a secured broker in stages, so each subscription is verified and drained before its consumer is switched and the database is retired.
Inventory subscriptions and send ports
Export every subscription, send port, filter expression and orchestration receive shape from the BizTalk applications, with the owning team for each. Use the BizTalk Administration console and your own deployment records, and confirm the list against message volumes from tracking data. The step is done when every subscription has a named owner, a source and a count of its consumers, and the list is signed off by the integration team. The effort depends on subscription count and orchestration complexity, so ask your partner to size it from this inventory before quoting.
Classify each flow as request-reply or publish-subscribe
Mark each subscription as request-reply, where a caller waits for a response, or publish-subscribe, where a message fans out to independent consumers. Request-reply flows often need a synchronous Camel route or an HTTP endpoint rather than a broker queue, and pub-sub flows map to exchanges or topics. Record the ordering and duplicate-handling requirements for each flow. The step is complete when every row in the inventory has one classification and a target pattern, reviewed by someone who owns the business process.
Stand up the broker with TLS and authentication
Deploy the chosen broker, RabbitMQ or Apache Kafka, in your own environment with encrypted client connections and named credentials for each application. For RabbitMQ, use quorum queues for durable, replicated delivery. For Kafka, enable SSL and one of the documented SASL mechanisms, and set authorization rules so that resources without ACLs are not open by default. The step is done when a test client can publish and consume over TLS, unauthenticated connections are refused, and the security team has reviewed the configuration.
Run dual publish in a pilot route
Pick one low-risk publish-subscribe flow and configure Apache Camel to send each message to both the existing BizTalk path and the new broker topic or exchange. Compare the message counts, payload hashes and correlation identifiers from both paths over an agreed observation period. Investigate any mismatch before continuing. The step is complete when the two paths show the same messages for the whole period, and the results are written up as evidence for the change record.
Drain BizTalk queues before cutover
Stop new messages from entering each flow at the source, let the BizTalk host instances process the messages already in the MessageBox, and confirm that the suspended and in-progress queues are empty. Keep the BizTalk subscription in place until the drain is verified, so no message is left in an orchestration or send port with no consumer. The step is done when tracking shows zero pending instances for that flow and the operations team confirms the queue state in writing.
Cut over consumers one subscription at a time
Move each consumer to the broker subscription in a separate change, starting with the flows that carry the least business risk. Keep a rollback path that re-enables the BizTalk subscription until the consumer has run successfully for the agreed period. Check that duplicate handling and ordering behave as the classification in step two requires. The step is complete for a subscription when its consumer reads only from the broker, its monitoring shows normal throughput, and the change is recorded against the inventory line.
Retire the MessageBox database after retention review
Once every subscription has moved and the retention requirements from your compliance and audit teams are satisfied, export any tracking data you must keep, then stop the BizTalk hosts and decommission the MessageBox database. Confirm the backup and archive are readable before deletion. The step is done when the archive has been restored and checked, the database is removed under the change process, and the monitoring estate no longer reports BizTalk subscriptions.
Questions buyers ask about replacing the MessageBox
Is RabbitMQ or Kafka the better fit for BizTalk-style routing?
RabbitMQ usually fits BizTalk-style content routing best, because its exchanges and bindings route messages to queues by pattern, and each consumer gets its own queue with acknowledgements. Kafka fits better when you need a replayable log, very high throughput, or many independent consumer groups reading the same history. Many BizTalk estates end up with RabbitMQ for transactional, per-subscriber delivery and Kafka for event streams. Run a short proof with your real subscriptions before choosing, and check that your message ordering needs match the broker's per-queue or per-partition guarantees.
What drives the effort and cost of replacing the MessageBox?
The main drivers are the number of subscriptions, how complex your correlation logic is, how much tracking you need, and how much broker operations your team takes on. Each subscription typically becomes a binding, queue or consumer that needs testing and an owner. Correlation that BizTalk handles through orchestrations and correlation sets must be rebuilt in code, often with a state store. Tracking requirements decide how much auditing you rebuild. Support is a separate line: the RabbitMQ commercial support license and any Red Hat or other vendor subscription are recurring costs you can choose or skip, while the open-source software itself carries no license fee. Ask for a quote built from a written inventory of subscriptions and flows.
Can our internal team replace the MessageBox without outside help?
Some teams can, especially where they already run Java services and Linux, and have someone who knows the BizTalk subscriptions well. The harder parts are usually not the broker itself but correlation, error handling, poison message handling and rebuilding monitoring. Ask yourself whether you have people to run a clustered broker, Kafka brokers on Java 17, and an on-call rotation. DeployOpen works in a fixed-scope engagement where scope, deliverables and timelines are agreed in writing before work starts, and can also support you through a retainer after go-live. Compare the cost of a partial engagement, such as a design review and pilot, with the cost of learning on production traffic.
How long does a pilot take to replace one BizTalk flow?
The duration depends on the complexity of the flow, not on the broker. A pilot usually covers one representative flow, its subscriptions, error paths, and a parallel run against BizTalk. Define the scope in writing first: which flows, which subscribers, which correlation rules, which monitoring views and what success means for your team. Ask any partner for a timeline tied to that scope, and ask what they will not cover. No duration is given here because the answer depends on your subscription count, correlation logic and test environments.
Can we migrate the message history from the MessageBox?
In most cases you cannot migrate the full message history from the MessageBox into a broker, and you should not plan for it. A broker is designed to hold messages until they are consumed and then remove them, while the MessageBox also holds tracking data and state for long-running orchestrations. Plan retention instead: decide how long BizTalk tracking data must remain queryable, export what auditors or support teams need into an archive, and let in-flight instances drain before cutover. Kafka retains messages for a configured period, which helps replay, but it is still not a copy of the MessageBox. Confirm retention rules with your compliance and records owners.
What does the broker need from the operations team?
For RabbitMQ on Kubernetes, the team needs the RabbitMQ Cluster Kubernetes Operator, which is published under MPL-2.0, and it must manage upgrades, quorum queues and persistent volumes. RabbitMQ 4.0 removed classic queue mirroring, so run quorum queues for replicated data. For Kafka, brokers, Kafka Connect and tools require Java 17 from version 4.0, and clusters must run KRaft because ZooKeeper mode was removed in 4.0. Authentication uses SSL or SASL, and ACLs stored in the KRaft metadata log restrict resources without ACLs to super users unless you change that setting. Ask your operations team to confirm monitoring, certificate rotation, backups, and the upgrade path for whichever broker you pick.
Does moving off the MessageBox change how we monitor integrations?
Yes. BizTalk tracking, the Health and Activity Tracking tool and the Admin Console show message and orchestration state from one place. With a broker, you monitor queue depth, consumer lag, dead-letter queues and consumer health with separate tools, and you rebuild business-level tracking yourself, usually with OpenTelemetry, Prometheus and Grafana or a log platform. Decide early which business events must be visible to operations, and add correlation IDs to every message so a flow can be traced across services. Confirm the alerting thresholds and retention periods with the teams that will respond to incidents.
What the broker replacement costs by component
The broker itself is the cheapest line item in this replacement, and that is often the surprise. Apache Kafka is released under the Apache License 2.0 with no paid edition from the project, so there is no broker license fee to budget. RabbitMQ's server is licensed under MPL 2.0, and its open-source edition carries no license fee either. Commercial long-term support for RabbitMQ is optional and is sold only with a valid commercial support license, so ask whether your version line needs it and for how long. The larger costs sit around the broker: the servers or Kubernetes capacity that run three or more nodes for high availability, storage and network for durable replicas, and the staff time to size, patch and back them up. These are largely recurring. Migration work, meaning rebuilding MessageBox subscriptions as exchanges, bindings or topics with filters, writing Camel routes, and testing ordering and redelivery behavior, is one-time, though it can run for months on a large estate.
Monitoring and operations are where recurring cost is most often underestimated. BizTalk's tracking and Health and Activity Tracking views have no direct equivalent, so you will build dashboards, alerts on queue depth and consumer lag, and dead-letter handling with tools such as Prometheus and Grafana, which are one-time build costs followed by upkeep. Ongoing operations include broker upgrades (Kafka supports rolling upgrades from the last three releases to the latest version, per the project's time-based release plan), security configuration such as SASL and TLS listeners and ACLs, and on-call coverage. Ask any implementation partner to price these as separate line items: discovery and inventory, broker build and hardening, Camel development per integration, test and cutover, monitoring build-out, and a retainer for upgrades and support. Also ask for the assumptions behind each estimate, including the number of subscriptions, message volumes, and whether you need commercial support for the broker or only for Camel.
Before accepting a quote, confirm three things in writing. First, which Camel release line the work targets and its end-of-life date, since LTS and non-LTS releases differ in support length. Second, whether the scope covers the full cost of your current BizTalk licensing being retired on the same schedule, because parallel running adds effort and infrastructure for the overlap period. Third, who owns the ongoing upgrade and patch cycle after handover. If that is not assigned to a named team or retainer, the open-source savings on license fees can be lost to unplanned work. DeployOpen fixes scope, deliverables and timelines in writing before work starts, so the quote will follow directly from the scope you agree on.
How DeployOpen scopes a MessageBox replacement
A MessageBox replacement is scoped as a fixed-scope engagement with deliverables and timelines agreed in writing before work starts. The first deliverable is a subscription inventory: every send port filter, orchestration receive shape, correlation set and direct-bound port in the BizTalk group, mapped to the topic or exchange it will need. This is the step that decides how much of the routing logic moves into broker bindings and how much moves into Camel routes. DeployOpen expects the client to supply the BizTalk configuration exports, tracking settings and a list of any subscriptions owned by teams outside the integration group, since those are the ones most often missed.
The next deliverables cover the broker design and the Camel route build. The broker design records the choice between RabbitMQ exchanges with quorum queues and Apache Kafka topics, the partition or routing key strategy, retention, dead-letter handling and the access model, along with whether the broker will run in the client's own cloud account, data center or air-gapped network. The route build then implements those decisions in Apache Camel, followed by testing against replayed production-shaped messages, failure injection for broker and consumer outages, and a cutover runbook. Cutover support is delivered for the agreed window, and the engagement closes with documentation of the topology, configuration, runbooks and open risks.
DeployOpen implements inside the client's infrastructure and does not issue audit reports, attestations or certifications. Where a regulated client needs evidence for an assessment, DeployOpen prepares the systems, configuration records and test results, and the independent auditor or certification body makes the determination. Before signing a scope, ask the provider to name each deliverable, the acceptance criteria for it and who holds the environment credentials during testing and cutover. Those answers, not a headline estimate, are what make a quote comparable.
How DeployOpen works on this
DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure, so the replacement for the MessageBox runs in your cloud account, data center or air-gapped network. Engagements are fixed-scope, with scope and deliverables agreed in writing before work starts.
How we scope
- Inventory every BizTalk send port, receive location and orchestration subscription that depends on the MessageBox today.
- Agree the target broker choice, RabbitMQ exchanges or Kafka topics, with the message flows, ordering needs and delivery guarantees written down.
- Define in the written scope which monitoring, tracking and audit evidence must carry over, and what is retired.
How we build
- Implement subscriptions as queue bindings or consumer groups and reproduce correlation keys in Apache Camel routes.
- Configure durable, replicated queues or topics with access controls, TLS and authentication matched to the agreed design.
- Test redelivery, dead-letter handling and ordering under failure cases, and record the results against the written scope.
How we hand over
- Document topology, routing keys, topic layouts, configuration and runbooks in a form your platform team can operate.
- Walk your operations and integration staff through failure handling, scaling and upgrade procedures before cutover.
- Deliver the test evidence and configuration records your internal reviewers or external auditors will ask to see.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover.
- Plan broker and client library upgrades against the vendor support windows you confirm for your chosen versions.
- Confirm with your team which support tier, whether community or commercial, fits your recovery and audit obligations.
