BizTalk Server end of support: Logic Apps or open source

BizTalk Server end of support: what your options are before 2028

For most BizTalk Server estates, the support calendar now sets the timing of the move. BizTalk Server 2020 is the last version, sales end in March 2027, and mainstream support lapses in April 2028, according to Microsoft's published lifecycle. Microsoft's stated path is Logic Apps Standard. The main open-source route is self-hosted Apache Camel with an open-source message broker, run on your own servers or Kubernetes. Both answer the same question but differ in where the integration runs and who operates it. Treat April 2028 as the end of your window and plan backward from it, because orchestrations, maps and adapters take time to move and a late start leaves little room for testing.

The deciding question is where each workload must run. Logic Apps Standard is a Microsoft service, so confirm with Microsoft which hosting and connectivity options it requires for each flow. That answer tells you whether it fits a controlled network. Apache Camel is Apache-2.0 licensed, runs standalone, on Spring Boot, on Quarkus or on Kubernetes, and lists more than 350 connectors, so it can stay on premises or inside a network with no outbound internet path. Before choosing, sort your BizTalk applications into three groups: those that can move to a cloud service, those that must stay in an on-premises or controlled network, and those that depend on adapters or trading partner links you have not yet mapped. Your network and compliance teams should confirm each group, since the group usually determines the target platform.

Start with two checks. First, ask Microsoft exactly what paid extended coverage for BizTalk Server includes, how long it runs and what it excludes, because it buys time without changing the platform underneath your integrations. Second, pin your Camel target to a long-term support line. Apache Camel 4.22.1 is an LTS release supporting Java 17, 21 and 25, with end of life in August 2027, and LTS releases receive bug and security fixes for up to one year. Check the Apache Camel download page for the current line before you commit. Then plan migration waves that begin with low-risk flows, so the most heavily connected orchestrations move after the team has tested the pattern. Cost detail for each path follows in the sibling pages.

Requirements that shape the migration target

Five constraints decide whether Logic Apps or self-hosted Apache Camel fits your BizTalk estate. Work through them in order, because hosting and connector coverage often rule options out before cost is considered.

Hosting and network path

Decide first whether integrations must run on your own servers, in a private cloud or on an air-gapped network. Camel runs standalone, on Spring Boot, on Quarkus, or on Kubernetes through Camel K, so it can run without an outbound internet path. Confirm whether your BizTalk hosts reach Azure today, because that dependency changes the hybrid option.

Adapter and connector coverage

Inventory every BizTalk adapter, including the SQL, file, HTTP, SOAP and MSMQ endpoints your ports use. Apache Camel's repository lists more than 350 connectors, including Kafka, REST, JDBC and cloud services, but a Camel component for each adapter is not guaranteed. Map each adapter to a named component and flag any gaps for custom code.

Orchestration and map reuse

Count orchestrations, XSLT maps and XSD schemas before choosing a target, since reuse effort drives the migration plan. Camel routes are written in Java, YAML or XML, so orchestration logic is rewritten rather than converted automatically. XSLT maps and schemas are portable assets that many teams keep and call from new routes.

Support window of the chosen platform

Choose a Camel release line by its end-of-life date, not only its latest version. Camel LTS releases receive bug and security fixes for up to one year, and the download page lists Camel 4.22.1 LTS with end of life in August 2027. Pin your production line to an LTS release and schedule upgrades before its end-of-life date.

Licensing model and commercial support

Camel is Apache-2.0 licensed, so software licensing carries no per-core fee, but you still pay for runtime infrastructure, skilled staff and any vendor support. Red Hat sells commercial support for its build of Camel through Red Hat Application Foundations or Red Hat Integration subscriptions. Ask whether a commercial support contract is required by your risk policy and what it covers.

Skills and operating model

Your team's skills decide how much rework is realistic. BizTalk staff know XML, schemas, maps and pipelines, which transfer to Camel, but the runtime is Java-based and operated through Kubernetes, Spring Boot or Quarkus tooling. Plan training or hire for Java and container operations, and check whether Kaoto's visual designer suits analysts who review flows.

Logic Apps Standard or self-hosted Apache Camel, by situation

Teams whose security policy allows integration workloads and message data in Azure can evaluate Logic Apps Standard as Microsoft's continuation path. On the Azure side, you need a subscription, a region your policy approves, storage and networking for the workflow runtime, and identity and access controls that your cloud team reviews. Microsoft operates the platform, but your team still owns connectivity to on-premises systems, monitoring, and the workflow design itself. If you choose Apache Camel in this situation, your team must run it in Azure containers or virtual machines, which removes most of the managed-service benefit.

Azure prerequisites: subscription, region, storage, networking and identity set-up must pass your cloud governance review before any build starts.
Skills transfer: BizTalk teams often find Microsoft tooling and Azure operations closer to their current work than Java development.
Feature coverage: confirm each BizTalk adapter, pipeline component and mapping feature against Microsoft's current Logic Apps documentation, because no supplied fact covers that comparison.
Data location: confirm where message payloads, run history and tracking data are stored, and how traffic to on-premises systems is connected.
Recurring cost: Azure consumption charges vary with message volume and environment design, so ask for a written estimate that shows each component.

Before committing, check Logic Apps feature coverage, licensing terms and support commitments in writing with Microsoft or your licensing partner.

Which open-source option fits which BizTalk workload

This table maps the main BizTalk workloads to the open-source options that could carry them, with the trade-off for each. Read it by finding your workload in the first column, then checking whether the trade-off is acceptable for your team and network. Apache Camel covers orchestration and mapping work, a broker covers messaging, and NiFi covers data-flow work, but none of them replaces BizTalk's admin console or tracking out of the box.

Workload	Open-source option	Trade-off
Orchestrations and message routing	Apache Camel with enterprise integration patterns, routes in Java, YAML or XML	Camel is a framework, so you build the operations console, tracking and deployment pipeline yourself or buy them separately
Kubernetes-hosted integration services	Camel K, built from Apache Camel for serverless and microservice deployment	Suited to teams already running Kubernetes; confirm your cluster policies and operator support before committing
Visual route design for BizTalk developers	Kaoto, an Apache-2.0 visual designer for Camel integrations	Eases the move for developers used to designers, but confirm it covers every component and pattern your routes use
Message persistence and publish-subscribe	RabbitMQ or Apache Kafka as the broker behind Camel routes	Replaces the MessageBox role, but you must design ordering, correlation and guaranteed delivery explicitly
Commercial support for Camel in production	Red Hat build of Apache Camel through Red Hat Application Foundations or Red Hat Integration subscriptions	Supports Spring Boot and Quarkus only; OSGi (Karaf) and JBoss EAP are no longer supported, so check existing runtimes first
Data-flow and file-based ETL	Apache NiFi, an Apache-2.0 system for automating data flows between systems	Better for data movement and transformation than for orchestrated business processes; confirm fit with your message patterns
Legacy Windows-based adapters	Camel components for databases, files, SOAP and REST, plus custom components where none exists	Each BizTalk adapter needs an equivalent component or custom code; inventory adapters before estimating effort

How to run Apache Camel under your constraint

This sequence moves BizTalk workloads to Apache Camel in controlled waves, so each stage is verified on your own servers or Kubernetes before BizTalk mainstream support ends. It ends with a running, monitored, supported stack that your team operates.

Inventory orchestrations, ports and adapters
Your BizTalk administrator and integration owners list every orchestration, send and receive port, adapter, pipeline, schema and map, then record the business owner, message volume, and downstream systems for each. Mark which flows depend on the MessageBox for routing, which use custom .NET components, and which rely on BizTalk Business Activity Monitoring or tracking. Done means a signed inventory that every flow is assigned to a migration wave or marked for retirement.
Choose runtime and supported Java version
Your architects pick Spring Boot, Quarkus or standalone Camel based on team skills, startup needs and container strategy, then select a Java version from the list Camel's download page supports (Java 17, 21 or 25 for the current releases). Confirm the choice against the Camel documentation for each connector your flows use, since not every component has the same feature set on every runtime. Done means a written runtime standard and a proof-of-concept route that builds and starts in your pipeline.
Select the Camel LTS line and end-of-life date
Platform leads choose a Camel LTS release rather than a non-LTS standard release for production, because LTS lines receive bug and security fixes for a longer period. Check the end-of-life dates on the download page against your planned migration and retirement dates, and set a calendar reminder to plan the next line before the current one ends. Done means an approved version pin in your build files and a documented upgrade owner.
Deploy to your servers or Kubernetes
Your platform team deploys Camel applications either as containers on your own Kubernetes cluster, using Camel K for lightweight, serverless-style integrations, or as standalone services on your existing virtual machines. Set up health checks, resource limits, secrets handling and configuration per environment. Done means a non-production environment where a test flow runs end to end under the same deployment method you will use in production.
Add a self-hosted message broker
Integration engineers install a self-hosted broker such as RabbitMQ or Apache Kafka in the same environment to replace MessageBox-based routing and decoupling. They define topics or exchanges, retention, dead-letter handling and access rules that match the subscriptions in your inventory. Done means that test messages published by one route reach every subscribed consumer, and failed messages land in a dead-letter path that someone monitors.
Set up monitoring and message tracking
Operations staff rebuild the tracking that BizTalk provided, using your chosen observability stack to capture message IDs, route timings, errors and business correlation fields. Alerts go to the same on-call rotation that supports the current BizTalk estate during the overlap period. Done means a dashboard shows each migrated flow's throughput and error rate, and a test failure triggers an alert that reaches a named responder.
Run migration in waves
The integration team moves flows in groups, starting with low-risk, well-understood interfaces, and runs old and new paths in parallel for each wave, comparing output messages before switching traffic. Each wave has a rollback step and a sign-off from the business owner. Done means every flow in the first waves has matched output for an agreed period and BizTalk receive locations for those flows are disabled. Plan the waves against BizTalk's mainstream support end date, which you should confirm with Microsoft for your agreement.
Confirm offline installs use mirrored artifacts
If the environment has no internet path, your build pipeline must mirror Maven artifacts, container images and the broker packages inside your network before deployment, and the mirror must be tested with a clean build. Confirm with your security team how the mirror is updated and verified. Done means a fresh build and deployment succeeds with outbound access disabled.

Evidence auditors and project sponsors ask for

A BizTalk exit produces a paper trail that sponsors, security teams and auditors will ask to see. The cards below list the records that connect the lifecycle decision to the running Camel routes. DeployOpen prepares this evidence, while independent auditors and certification bodies issue any opinion on it.

Lifecycle and end-of-support record

Keep a dated record of the BizTalk Server 2020 version in use, its sales end and mainstream support dates, and the decision that set your exit deadline. Include the Windows Server and SQL Server versions that host it, since those platforms have their own support windows. Confirm each date with Microsoft's current lifecycle pages rather than relying on older internal notes. This record justifies the wave plan and any paid extended coverage.

Route and adapter inventory

List every orchestration, send and receive port, pipeline, adapter and map, then assign each one a target Camel route, component or endpoint. Mark the adapters with no direct Camel component so they are visible as gaps needing custom code. The inventory is the baseline every later test and sign-off refers back to, so version it alongside the source of the BizTalk artifacts.

Test and cutover records per wave

For each migration wave, retain test scripts, message samples, expected outputs, defect logs and the sign-off by the business owner. Record how traffic was switched, how it was rolled back and how long both stacks ran in parallel. Ask your team to define the acceptance criteria before the first wave starts so the evidence is not written after the results are known.

Logging and tracking proof

BizTalk Tracking and the BAM views show message history to operations staff. Replace that with a defined set of logs, correlation IDs and dashboards in your monitoring stack, and show with test messages that a single transaction can be traced end to end. Confirm with your compliance lead which retention period and access controls the tracking data must meet, since those requirements are set by your own policies and regulations.

Licensing and retirement record

Document each BizTalk, Windows Server and SQL Server license or subscription, the date it stops being used, and the decommissioning evidence for each server and database. Include paid extended support contracts and their end dates. Procurement and finance will use this to show which recurring costs were retired, so ask your vendor for the exact terms in writing before the record is finalized.

Questions buyers ask before hiring help with BizTalk migration

What does extended coverage for BizTalk Server cost, and what does it exclude?

Extended coverage is a paid option Microsoft offers after mainstream support ends, but no price is supplied for this page, so request the written terms from Microsoft or your licensing partner before you decide. Ask what the coverage includes, such as security updates and non-security fixes, how long it runs, and whether it covers every installed component. Ask just as directly what it excludes, including new features, design guidance and any Windows Server or SQL Server version changes your BizTalk environment depends on. Then compare the total with the one-time cost of moving and the recurring cost of running the replacement.

How long does a BizTalk to Apache Camel migration take?

The duration depends on the size and shape of your estate, and no timeline is supplied for this page. The main drivers are the number of orchestrations, ports, pipelines and adapters, the number of schemas and XSLT maps that need reuse or rewriting, how tracking is re-created, how many trading partners and downstream systems must be tested, and whether your team can move in waves. Expect the inventory stage to set the real estimate. Ask any implementation partner for a fixed-scope plan built on that inventory, with the wave order and exit criteria written down.

What does a migration need from our own internal team?

A migration needs a named owner for each business interface, people who can confirm expected message behavior, and testers who can run end-to-end cases against partner or test endpoints. Your platform team must provide the target environment, the message broker, identity and secrets access, and change windows for cutover. Your integration or Java developers need to review and maintain the Camel routes after handover. Your operations team should agree on monitoring, alerting and backup responsibilities for the new stack before the first production wave.

Can our own engineers migrate BizTalk to Camel without outside help?

Yes, many teams can, provided they have Java or YAML skills, a working understanding of enterprise integration patterns and time to learn the Camel component model. Routes can be written in Java, YAML or XML, and the Kaoto visual designer can help engineers read and draw flows. The harder parts are usually not the routes themselves: they include recreating BizTalk tracking, replacing MessageBox routing and proving that maps and schemas behave the same. A common approach is to migrate one low-risk interface first, measure what your team needed, and then decide how much outside help the remaining waves need.

Does Logic Apps Standard meet our on-premises data residency rule?

That depends on your specific rule and on where Microsoft's hosting model runs your workloads, so confirm it in writing with Microsoft before relying on it. Ask where the runtime, storage and any managed connector traffic live, whether the deployment needs outbound connectivity to Azure, and how logs and message payloads are retained. If your rule requires a network with no internet path, ask Microsoft directly whether any supported option works fully offline. Give your compliance lead these answers as written evidence, since DeployOpen prepares controls and evidence but does not issue attestations.

How do Apache Camel LTS end-of-life dates affect our migration plan?

Choose a Camel release line whose end-of-life date falls well after your planned cutover and the period you expect to run it in production. The Camel download page lists Camel 4.18.5 LTS with end of life in February 2027 and Camel 4.22.1 LTS with end of life in August 2027, and it lists Camel 4.23.0 as a non-LTS release. LTS releases receive bug and security fixes for up to one year, so plan a scheduled upgrade before each end-of-life date. Build the upgrade into the project plan rather than treating it as a later task. Also confirm the Java version each release supports with your platform team.

How are fixed-scope migration engagements quoted from written scope?

DeployOpen does not publish a price list. Most engagements are fixed-scope, so scope, deliverables and timelines are agreed in writing before work starts, and the quote follows from that written scope. Ask for the inventory assumptions, the list of interfaces in and out of scope, the acceptance criteria for each wave, the testing responsibilities on both sides, and what happens if the inventory finds more artifacts than expected. Also ask whether post-cutover support or continuous testing should be a separate retainer, since ongoing support and upgrades are offered that way.

What changes for operations after cutover

Moving from BizTalk Server to self-hosted Apache Camel changes who runs the platform. Logic Apps Standard keeps much of the runtime and patching with Microsoft's managed services, while a Camel estate puts the JVM runtimes, the message broker, the gateway or ingress tier, upgrades and monitoring in your team's hands. The operational shift is fewer vendor-managed components and more components you own end to end. Before cutover, name the owner of each one, because a runtime nobody patches becomes the first finding in your next assessment.

Camel publishes two release types you must plan around. LTS releases, such as the 4.22.1 line listed on the Apache Camel download page with end of life in August 2027, receive bug and security fixes for up to one year, and the page also lists 4.18.5 LTS with end of life in February 2027. Standard releases, such as 4.23.0 listed as the latest standard release in October 2026, are non-LTS and shorter-lived. Pick the line your organization can keep current, record its end-of-life date in your change calendar, and confirm the Java versions your runtime needs against the supported list, since Camel supports Java 17, 21 and 25 on the listed releases.

Assign patch windows, on-call rotations and upgrade ownership in writing before the first production route goes live. Decide who receives Camel and Java security advisories, who approves a Camel minor upgrade, and who owns the broker's disk, partitions and consumer lag alerts. Ask your support provider, whether that is Red Hat for the Red Hat build of Apache Camel or an implementation partner, which tasks are covered under contract and which fall to your staff. Rehearse one full upgrade in a non-production environment so the runbook is tested before it is needed under pressure.

How DeployOpen plans and deploys this migration

DeployOpen plans and implements self-hosted open-source integration platforms inside your own infrastructure, including Apache Camel and its supporting brokers. For BizTalk Server end of support, we start with a written inventory and scope, build in waves that keep existing interfaces running, and hand over documented, tested systems that your team can operate.

How we scope

Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.
The written scope lists which orchestrations, maps, ports and adapters are in and which are retired.
We confirm your hosting target, whether on-premises, cloud accounts or air-gapped networks, before any design begins.
The scope names the message broker, tracking needs and monitoring that the replacement must cover.

How we build

We rebuild orchestrations as Apache Camel routes and reuse XSD schemas and XSLT maps where they still fit.
Each wave is tested against recorded production-like messages before cutover to the new routes.
Security testing of APIs and integration endpoints can run alongside the build as part of the scope.
Compliance evidence, such as access controls and logging configuration, is prepared for your assessors to review.

How we hand over

You receive runbooks, architecture records and configuration documented for your own operations team.
Knowledge transfer sessions cover running, troubleshooting and upgrading the Camel routes and broker.
Backup and recovery procedures are documented and tested for the integration platform as delivered.
Handover is complete when the agreed deliverables in the written scope are accepted in writing.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after handover.
Retainers can cover Camel LTS upgrades, patching and periodic security testing of your integration layer.
Your own assessors or certification bodies make any audit decision. DeployOpen prepares the systems and evidence.
Ask any proposal to state support response expectations and the upgrade approach in writing.