How a team migrates from BizTalk Server to Apache Camel
BizTalk Server 2020 is the last release, so a team running it must plan its move well before mainstream support ends in April 2028. The migration is a re-platforming: orchestrations, send and receive ports and pipelines become Camel routes, XSD schemas and XSLT maps are carried over largely as they are, and the MessageBox's publish-subscribe role passes to a broker such as RabbitMQ or Kafka. Most teams do the work with their own integration engineers, who know the business flows, and bring in an implementation partner for the Camel and broker design, the hardest orchestrations and test automation. The effort follows the inventory. A set of simple one-way mappings is a far smaller job than a chain of stateful orchestrations with long-running correlations. The sibling pages on support timing and cost cover the commercial side in detail.
Start with an inventory, because it sets the wave plan. Export every orchestration, port, pipeline, adapter, binding and schema, then tag each item with its owner, its message volume and whether it keeps state across messages. Simple flows are usually the first wave. Stateful orchestrations, long-running transactions and flows that depend on BizTalk's tracking belong in later waves, after the team has a working pattern for correlation and compensation on Camel. Check each adapter against a Camel component. File, FTP, HTTP, JDBC and queue adapters usually have direct counterparts, while WCF and SAP-specific adapters need an explicit decision on what replaces them. Confirm each mapping against the Camel component catalog before its wave starts, and record the decision for auditors.
Run each wave alongside BizTalk, sending a copy or a limited share of traffic through the Camel flow first, and keep the old flow available until production message counts, error handling and retries match. Plan the tracking replacement early, because Camel does not ship a drop-in equivalent of BizTalk's tracking. Decide on OpenTelemetry tracing, a message store and dashboards before the first production wave. Choose the Camel line deliberately: the Apache Camel download page lists 4.22.1 as an LTS release with end of life in August 2027, and LTS releases receive bug and security fixes for up to one year. Confirm the current LTS line at the time of your plan and schedule upgrades against it.
Which BizTalk capabilities map cleanly to Camel and which need rework
This table maps each BizTalk capability to its closest Apache Camel equivalent and labels it clean, needs rework or gap. Read it as a planning checklist: the rework rows drive most of the design and testing effort, so confirm them against your own applications before estimating a wave.
| BizTalk capability | Apache Camel equivalent | Status and what to confirm |
|---|---|---|
| Orchestrations | Camel routes written in Java, YAML or XML, with EIP steps for sequencing, splitting and aggregation | Needs rework. Stateless flows map directly, but long-running orchestration state needs an explicit design (persistence, correlation keys, timeouts). |
| Ports and adapters | Camel endpoints and components, such as Kafka, JDBC, REST, AWS, Azure and Salesforce | Clean for common transports. Confirm each adapter (for example, SQL, SFTP, MQ or SAP) has a Camel component or a third-party component in your environment before committing. |
| Pipelines and pipeline components | Camel processors, data format transformations and EIP steps in the route | Clean for parsing, validation and enrichment. Custom pipeline components in .NET need reimplementation in Java. |
| XSD schemas | Reused as-is for validation with Camel's validator and XML data formats | Clean. Keep schemas under version control and confirm namespace and import paths resolve in the new build. |
| XSLT maps | Reused through Camel's XSLT component, with the same XSLT version and extension functions checked | Needs rework where maps call .NET extension objects or BizTalk-specific functoids. Test output with sample messages from production. |
| MessageBox subscriptions | RabbitMQ exchanges and queues, or Apache Kafka topics, with routing keys or consumer groups replacing filter expressions | Needs rework. Subscription filters and correlation must be redesigned, and guaranteed delivery and ordering need explicit configuration. |
| BizTalk tracking and BAM | Re-created observability with OpenTelemetry traces, structured logs and dashboards, plus an explicit business activity record | Gap. Tracking and BAM views are not carried over automatically, so define the business events, retention and audit fields before cutover. |
What data and integration assets move, and what must be rebuilt
A BizTalk inventory produces a list of assets that fall into two groups: those that can be carried over as files and data, and those that must be re-created as Camel routes, components and secrets. Each card below covers one asset type or one migration risk, so the inventory can be checked item by item before any wave is scheduled.
Orchestration definitions and their logic
Export the list of orchestrations, their shapes, expressions, correlation sets and exception handling from each BizTalk application. Orchestrations do not map one to one onto Camel routes, so each one needs a written design that states its steps, state handling and compensation. Treat the Camel route as a rebuild, and use the inventory to decide which orchestrations need long-running state at all.
XSD schemas and XSLT maps
XSD schemas are plain XML Schema documents and can usually be reused as they are in Camel, for validation and for generating Java classes. XSLT maps are also standard XSLT and are often portable, but BizTalk-specific functoids and extension objects must be found and replaced. Run each map against sample messages on both platforms and keep the output diffs as evidence.
Send and receive ports, bindings and adapters
Record every send port, receive location, binding and adapter setting, including filters, retry policies and transport addresses. Camel connectors such as Kafka, REST, JDBC and others from its 350-plus connector set take over most of these roles, but BizTalk adapters that have no direct Camel counterpart must be identified early. Confirm adapter parity for each protocol with the Camel component documentation and a test against your own endpoints.
Certificates and credentials in a secrets store
BizTalk commonly keeps certificates in the Windows certificate store and credentials in SSO or binding configuration. Move private keys, certificates and passwords into a secrets manager that Camel can read at startup, and rotate them during cutover rather than copying them as they are. Record which service accounts each port used so access can be granted to the new runtime with the same limits.
In-flight messages in the MessageBox
Messages already inside the MessageBox, including those awaiting correlation or retry, do not have a documented export path that carries their state into a broker or a Camel runtime. Plan a drain window per application in which senders are paused and the BizTalk queues empty, or in which each message is replayed from its source. Confirm with your Microsoft contact which message states can be inspected and counted before cutover.
Tracking, monitoring and audit history
BizTalk Health and Activity Tracking records message and orchestration history in its databases, and that history will not move into Camel by default. Decide which records must be kept for audit, keep the BizTalk databases read-only for the retention period your policy requires, and define the replacement metrics and logs for the Camel routes before the first wave goes live.
Migration sequence from inventory to decommission
This sequence moves BizTalk workloads to Apache Camel in controlled waves, proving each interface against live traffic before BizTalk is switched off. Each step produces a signed artifact that gates the next one.
Inventory and classify every BizTalk artifact
Build a register of every receive location, send port, orchestration, pipeline, map, schema, adapter binding and business rule, with its owner, message volume, partners and downstream dependencies. Classify each interface by business criticality, data sensitivity and complexity, and record which BizTalk Server environments are in scope. The integration team and the application owners do this together, and it is done when each artifact has one owner and one classification. The output is the inventory register, which becomes the baseline for every later wave.
Select and build the pilot flow
Choose one low-risk, well-understood flow with a single adapter type and a tolerant partner, then rebuild it as a Camel route. Reuse the existing XSD schemas through Camel's data format support and convert XSLT maps with an XSLT step, testing each transformation against sample messages exported from BizTalk. Confirm the broker choice (RabbitMQ for queue-style routing or Kafka for replayable streams) and the Camel LTS release the platform will pin. Ask the platform team to confirm the Java version and runtime (Spring Boot or Quarkus) against the Camel release notes before build starts.
Run the pilot acceptance test
Execute the pilot in a non-production environment with replayed production-shaped traffic, then compare outputs message by message against BizTalk for payload content, routing decisions, error handling and retry behavior. Confirm that tracking data for each message can be found in the new tooling, since BizTalk's Health and Activity Tracking does not carry over automatically. The pilot is accepted when the defect list is closed and the business owner signs the acceptance report. That report, with test evidence and the list of known differences, authorizes the parallel run.
Operate a parallel run with reconciliation
Configure the source system or a fan-out component so that BizTalk and Camel receive the same inbound messages, with only BizTalk's output reaching the partner. Run a reconciliation job that matches message counts, identifiers, payload hashes and timing between the two paths, and raises exceptions for any mismatch. Hold the parallel run until mismatches are explained and resolved for a period agreed in the cutover plan. Its output is a reconciliation report per interface that shows mismatch causes, and the decision to move on rests on that evidence.
Cut over each interface with a rollback path
Switch one interface at a time by moving the partner-facing endpoint or the source routing to Camel, following a written cutover runbook. The runbook lists the change window, the named approvers, the health checks, the rollback trigger and the exact steps to restore BizTalk routing. Keep BizTalk in a warm state so the rollback can be executed without rebuilding. The interface is complete when the runbook is signed off and the post-cutover monitoring has shown normal operation. Repeat this step for each wave, and record the outcome in the inventory register.
Decommission BizTalk and archive its databases
After every interface in scope has run on Camel with no open rollback decision, stop the BizTalk host instances and disable the receive locations, then remove the send ports so no traffic can flow. Back up the BizTalk databases, including MessageBox, Tracking and BAM, and store them under the retention rules your compliance team defines, confirming with auditors which records must be kept and for how long. Remove or re-license the Windows and SQL Server capacity that BizTalk used only after the archive is verified. The decommission is closed when the archive is restorable, the register shows every interface as migrated, and the change record is approved.
Choosing RabbitMQ or Kafka to replace the MessageBox
Pick RabbitMQ when the MessageBox job is routing messages to consumers, and pick Kafka when the job is keeping a replayable record of events. BizTalk's MessageBox pairs publish-subscribe routing with persistence in SQL Server, so the question is which of those two duties your broker must carry. RabbitMQ fits point-to-point delivery and fan-out through exchanges and bindings, with each consumer reading from its own queue. Its durable queues are quorum queues, which replicate through the Raft consensus algorithm. Kafka fits high-volume streams where several consumers read the same topic at their own pace and need to reprocess history, such as when a new downstream system must be backfilled.
Protocol and version choices follow from that split. RabbitMQ was built around AMQP 0-9-1, and AMQP 1.0 became a core protocol in RabbitMQ 4.0, which matters if partner systems speak AMQP 1.0 directly. Classic queue mirroring was removed in RabbitMQ 4.0, so high availability for BizTalk-style queues must use quorum queues or streams. On the Kafka side, version 4.x runs only in KRaft mode, so ZooKeeper-based clusters must be migrated first. Confirm that your chosen Kafka release is one of the supported lines on the Kafka downloads page, and that Java 17 is available for brokers and Kafka Connect. Security also differs: Kafka offers SSL/TLS and SASL mechanisms such as SCRAM-SHA-512 and OAUTHBEARER, and in KRaft clusters, ACLs are enforced through the authorizer, so resources without ACLs are restricted to super users by default.
Before you select a version, check the support windows on the RabbitMQ release information page and the Kafka downloads page, because community support can end months before a line is retired and commercial support for RabbitMQ is sold separately. Plan a proof of concept that replays a representative set of BizTalk subscriptions against both candidates, then record which delivery, ordering and monitoring behaviors your business rules depend on. That record, not a general comparison, should decide the broker.
How the migration changes by starting point
A small estate has a handful of orchestrations, a few send and receive ports and limited reuse of schemas and maps. Here the migration is mostly a matter of finishing the inventory quickly and moving everything in one or two waves, because the dependency graph is short enough to hold in one team's head. Testing effort is concentrated on message correctness and on the handful of external endpoints.
- Inventory in one pass: list every orchestration, port, pipeline and adapter in a single spreadsheet, then mark which ones are still receiving traffic.
- Retire dead flows first: unused ports and orchestrations are cheaper to delete than to port, so confirm with business owners before writing any Camel routes.
- Run a single pilot wave: move one low-risk flow end to end, including error handling and tracking, before committing the rest.
- Replay recorded messages: capture real inbound payloads from the current system and replay them against the Camel routes, comparing outputs field by field.
- Keep the MessageBox logic simple: a few subscriptions can usually map directly to broker queues without a full redesign.
Confirm with your team whether the small estate still has undocumented scheduled jobs or file drops that are not visible in the BizTalk admin console.
A large estate shares many XSD schemas, XSLT maps and pipeline components across dozens of orchestrations. The main risk is sequencing: moving one consumer before its shared schema or map exists in the new stack causes failures that look like data problems. Work is therefore organized around shared assets first, then the flows that depend on them, and testing covers regression across every consumer of a changed map.
- Move shared assets before consumers: port the common schemas and maps into a versioned Camel library so each wave can reference them.
- Build a dependency map: record which orchestrations call which maps and which subscriptions depend on which message types.
- Plan parallel waves by domain: group flows by business domain and business owner so each wave has a clear sign-off.
- Run dual-running comparisons: send the same inbound traffic to BizTalk and Camel for a period and reconcile outputs, which is the largest testing effort in this profile.
- Budget for coexistence: BizTalk and Camel will run side by side for longer, so ask for a quote that covers operating both platforms during the transition.
Check that every shared map has a test suite before the first wave starts, because regression coverage determines how fast later waves can move.
An estate with heavy B2B and EDI traffic depends on trading partners who test and certify their connections, often with agreed acknowledgments, envelope handling and retry rules. Cutover is constrained by partner calendars, not only by your own readiness, so sequencing starts with partner communication. Testing requires partner-side test environments and a clear plan for in-flight transactions.
- Start with partner inventory: list each trading partner, its protocol, its certificate and its acknowledgment behavior before choosing a first wave.
- Plan partner-by-partner cutover: move one partner at a time, with a fallback path back to BizTalk for each.
- Handle in-flight messages: define how transactions already sent or half-processed are reconciled at cutover, including duplicates and missing acknowledgments.
- Test with partner sandboxes: use each partner's test environment and agree acceptance criteria in writing before production.
- Confirm EDI component coverage: EDI parsing and envelope handling are not part of the core Camel stack, so confirm which EDI libraries or components your team will use and who supports them.
Confirm with each partner whether they accept a change of endpoint, certificate or message format before you schedule their wave.
In an air-gapped environment, the broker, Camel, build tooling and dependencies must all come from inside the network. Migration therefore includes an offline artifact pipeline: Maven dependencies, container images, broker packages and documentation are mirrored in, scanned and approved before anything is deployed. Testing is done entirely on isolated infrastructure, so there is no external service to call during verification.
- Mirror dependencies first: build an internal repository for Camel and its libraries, and verify every artifact before it enters the network.
- Plan offline upgrades: because patch cycles depend on transfers across the boundary, schedule Camel and broker versions with that delay in mind, and confirm the support window of the release you choose.
- Test with isolated replicas: build a staging environment inside the same restricted network so behavior matches production.
- Recreate external dependencies locally: replace cloud or SaaS endpoints with internal stubs so flows can be exercised without outbound access.
- Document the evidence: keep records of approved artifacts, test results and change approvals, since assessors will ask for them.
Confirm with your security team which transfer process, approval chain and scanning rules apply before the first artifact is requested.
What drives migration cost and duration, and how to control it
This table lists the factors that most change the effort of moving BizTalk applications to Apache Camel, with a note on how each one moves cost and what to do about it. Read it against your own inventory, since the largest driver is usually the number of orchestrations and custom components you actually run. No price or duration is given here, so use the rows to scope a fixed-scope quote.
| Driver | Why it moves cost or effort | How to keep it down |
|---|---|---|
| Orchestration count and complexity | Each orchestration with long-running transactions, compensation blocks, or nested sagas needs its own redesign as Camel routes and state handling. | Group orchestrations by business flow, retire unused ones first, and split the largest into smaller routes before migrating. |
| Custom pipeline components | Custom pipeline components written in .NET have no direct equivalent and must be rewritten as Java processors or Camel components. | Count and classify them early, and reuse existing Java libraries where they already exist. |
| Schema and map reuse | XSD schemas usually carry over, but XSLT maps and BizTalk-specific functoids may need review or rewriting for the Camel data path. | Keep schemas as the contract, validate XSLT output with sample messages, and rewrite only the maps that use BizTalk-only functoids. |
| Adapter diversity | Each BizTalk adapter (for example SQL, SFTP, SOAP, or MSMQ) maps to a Camel component, but some have configuration differences or no close match. | Build a table of adapter-to-component mappings and confirm each component version against the Camel download page before design starts. |
| Message volume and ordering needs | Ordering and guaranteed delivery requirements push the design toward specific broker features, and high volumes need more testing and tuning. | Document ordering rules per flow, pick the broker feature that matches them, and load test the busiest flows first. |
| In-flight state | Instances still running in the MessageBox at cutover must be drained, completed, or migrated, which adds planning and dual-running effort. | Plan cutover per flow, drain long-running instances before the switch, and agree on a rule for in-flight messages. |
| Test automation | Without existing automated tests, comparing BizTalk and Camel output for the same inputs is manual and slow. | Capture representative messages from production, build replay tests, and compare outputs automatically in each wave. |
| Compliance evidence | Assessors expect records of changes, test results, access controls and monitoring for the new platform, which adds documentation work. | Map existing controls to the new stack early and generate evidence from pipelines and tracking as the work proceeds. DeployOpen prepares evidence, but auditors and certification bodies issue any assessment outcome. |
| Team skills in Java and Camel | Teams that know BizTalk and .NET need training or support in Java, Camel routes, and JVM operations, which can extend the timeline. | Plan pairing and training in the first wave, and confirm the internal skills gap during the inventory phase. |
What usually goes wrong when moving BizTalk to Camel
Most failed BizTalk migrations fail quietly rather than loudly, because the old behavior was implicit in the platform. The six risks below cover behavior, delivery, audit evidence, secrets and transformations, and each one has a check to run before a wave goes live.
Silent behavior changes in orchestrations
BizTalk orchestrations carry implicit behavior: transactional scopes, exception handlers, retry settings, and default message properties that the team never wrote down. A Camel route will run without any of these unless someone re-declares them. Before cutover, list every orchestration shape, exception path and send port setting, then compare outputs for the same test messages in both systems. Treat any difference as a defect until a business owner signs it off.
Lost correlation and message ordering
BizTalk correlation sets tie long-running orchestration instances to incoming messages, and ordered delivery depends on how the MessageBox handled subscriptions. In Camel and a broker such as RabbitMQ or Kafka, you must decide explicitly how correlation keys are carried, where state is held, and which queues or partitions preserve order. Test with out-of-order and duplicate messages, not only the happy path, and document the key used for every correlated flow.
Duplicate delivery during parallel runs
Running BizTalk and Camel side by side is the safest way to validate a wave, but both systems can then send the same business message to the same downstream partner. Duplicate payments, orders or notifications are a common result. Use a separate test endpoint or a message filter for the parallel period, and make sure every consuming system can reject a repeated transaction ID before any live traffic is shared.
Missing tracking that auditors expect
BizTalk Health and Activity Tracking and the message tracking database give operations and auditors a per-message history without custom code. Camel does not provide an equivalent out of the box, so the replacement must be designed and tested: message IDs, timestamps, routing decisions, payload retention rules and access control. Ask your compliance lead which evidence they will sample, and confirm that the new trail can answer those questions before retiring the old one.
Unmanaged credentials in ports and adapters
BizTalk stores adapter credentials in send and receive port configuration, often with shared service accounts and passwords that have not rotated in years. When these move to Camel, the same secrets tend to end up in properties files, environment variables or route code. Inventory every adapter credential, move them to a managed secrets store, assign one identity per integration, and set a rotation procedure before the first wave goes live.
Underestimated map conversion
XSLT maps look portable, but BizTalk maps often depend on scripting functoids, custom extension objects, and schema behavior that differs in other XSLT processors. Teams that estimate map work by counting maps usually underestimate it. Classify each map by complexity, check whether the XSLT version and extension functions are supported by the Camel XML or XSLT components you choose, and run each converted map against a regression set of real-format sample messages from production.
Running BizTalk and Camel in parallel and cutting over safely
The safest cutover keeps BizTalk and Camel both receiving and processing the same business traffic for a defined period, so that each wave can be proven before BizTalk is removed from the path. Start with shadow traffic: copy inbound messages from each receive location to the Camel route, let the Camel route process into a non-production target or a sandbox endpoint, and leave BizTalk as the only system of record. Mirroring can be done at the broker or at the partner gateway, depending on what your transport supports. Confirm with your network and security teams that the copy does not create a second route for regulated data outside the approved zones.
Reconciliation is what turns shadow running into evidence. For each partner and message type, compare counts of messages received, routed, transformed and delivered, and compare a content hash of the normalized payload against the hash BizTalk produced for the same message ID. Expect differences in timestamps, generated identifiers and map-version metadata, so define the fields to exclude before the first run and record every exception with an owner. Keep the tracking data from both sides so that a mismatch can be traced to a map, a schema or a correlation rule, not argued about after the fact.
Move traffic one partner at a time by changing the routing switch for that partner, such as a DNS record, a load balancer pool, a gateway route or a sendTo setting in the sending system, and never all partners in one change. Keep BizTalk able to receive traffic until acceptance is signed off: the BizTalk receive locations and send ports stay enabled, the partner endpoint can point back to them within a single change window, and any messages in flight on the Camel side are drained or replayed from the broker before the switch back. Test the rollback procedure in a rehearsal before the first live switch, and agree in writing with the business owner what counts as acceptance for each partner.
Questions buyers ask before moving BizTalk to Apache Camel
What drives the cost of moving BizTalk applications to Apache Camel?
The main driver is how many orchestrations, ports, pipelines, maps and adapters you have, and how many of them carry business logic that needs rework rather than a direct translation. Apache Camel is free under Apache-2.0, so the cost of the move is people, infrastructure and a message broker, not a license fee for the framework. Recurring costs include the servers or Kubernetes capacity, broker operations, and commercial support if you buy it. Red Hat sells commercial support for the Red Hat build of Apache Camel through its subscriptions, and that is optional. Ask any provider for a quote that separates inventory, route build, testing, broker setup, tracking rebuild, cutover and handover, with each item tied to a written scope.
How does the move timing relate to BizTalk support dates?
Plan the waves against the BizTalk dates in the sibling pages, which list sales ending in March 2027 and mainstream support ending in April 2028. Migration usually runs in waves: low-risk, well-understood interfaces first, then the core orchestrations, with the highest-volume or most regulated flows last. Each wave needs parallel running, reconciliation of messages and a rollback path, so start early enough that the last wave finishes before your chosen end date. Confirm the current BizTalk support terms with Microsoft and your licensing contact, because extended coverage and its exclusions are not something this page can state for your agreement.
What does the migration need from our internal staff?
Your staff must own the business rules, message contracts and operational decisions, because no outside team knows your partners, data meanings or exception handling as well as your integration owners do. Expect needs in four areas:
Can our own team migrate BizTalk to Apache Camel without a partner?
A team with Java, integration and messaging experience can do it, and many do the first waves themselves. The harder part is the cutover discipline: running two systems side by side, reconciling messages across the broker and the old MessageBox, and rebuilding tracking that operations relies on. Your team should confirm whether it has capacity for these tasks while keeping production running. An external partner usually earns its place on the riskiest flows, on the broker design and on testing, and the split of work should be written into the scope before anyone starts.
How are XSLT maps and XSD schemas handled in a Camel migration?
XSD schemas usually carry over directly, because Camel routes can validate XML against them and the schemas describe your message contracts regardless of the engine. XSLT maps can often be reused, since Camel supports XSLT transformation, but each map must be tested against the same inputs and outputs, including namespaces, date formats and edge cases. Maps that call BizTalk-specific functoids or extension objects need rewriting. Inventory every map and mark it as reuse, adjust or rewrite before estimating the work, and confirm the XSLT version and processor behavior with a sample test run.
Do Apache Camel LTS releases fit a BizTalk replacement plan?
Camel LTS releases fit well if you pick the right line and plan upgrades. The download page lists Apache Camel 4.22.1 as LTS with end of life in August 2027, and Camel 4.18.5 LTS with end of life in February 2027. LTS releases receive bug and security fixes for up to one year, so a migration that finishes after February 2027 should target 4.22.1 or a later LTS line. The current standard release, 4.23.0, is not LTS and needs more frequent upgrades. Also check the Java version: Camel supports Java 17, 21 and 25 in these releases. Build an upgrade calendar into the plan from day one.
What should a fixed-scope quote for this migration include?
A fixed-scope quote should list the agreed interfaces, the inventory method, the target architecture and each deliverable with its acceptance test. Ask for the following in writing:
Does DeployOpen handle the BizTalk migration from start to finish?
DeployOpen plans, implements, customizes, integrates, hardens, backs up, documents and supports self-hosted open-source platforms inside your own infrastructure, which covers Apache Camel, the broker and the surrounding operations. Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts, and ongoing support or upgrades can run as a retainer. DeployOpen does not publish a price list, so a quote follows from the written scope. Your team stays in the decision loop for business rules and cutover approval.
How DeployOpen scopes and delivers the migration
DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure, so a BizTalk move to Apache Camel runs on your cloud accounts, data centers or air-gapped network rather than on a vendor's hosted service. Most engagements are fixed-scope, and the written scope is where the BizTalk work gets defined: which orchestrations, send and receive ports, pipelines, adapters and BAM or tracking dependencies are in, which are retired, and which MessageBox subscriptions move to a broker such as RabbitMQ or Apache Kafka. Deliverables are named per wave, and timelines are agreed in writing before work starts. Ask for the inventory as a deliverable in its own right, because a count of applications is not the same as a list of ports, schemas and maps that each wave must carry across.
Scope also needs decisions that only your team can make. Confirm which XSD schemas and XSLT maps will be reused as-is, which will be rewritten, and who signs off on message format changes for partners who still send the old shape. Confirm the Java version and Camel release line you will standardize on, since the Camel download page distinguishes LTS releases from standard releases, and confirm the broker's support model before you choose it. The written scope should name these owners, because the most common delay in a migration of this kind is an unresolved interface contract, not the code itself.
After the first wave, the support question starts. DeployOpen can run ongoing support, upgrades and continuous testing under an optional retainer, and it can prepare systems, controls and evidence (such as configuration baselines, access records, backup test results and change logs) for compliance assessments. DeployOpen does not issue audit reports, attestations or certifications; your independent auditor or certification body does. Ask any delivery partner, including DeployOpen, to show in writing which operational tasks transfer to your team at handover and which stay under retainer.
