Microsoft BizTalk Server Product Lifecycle Update
For more than 25 years, Microsoft BizTalk Server has supported mission-critical integration workloads for organizations around the world. From business process automation and B2B messaging to connectivity across industries such as financial services, healthcare, manufacturing, and government, BizTalk Server has played a foundational role in enterprise integration strategies. To help customers plan confidently for the future, Microsoft is sharing an update to the BizTalk Server product lifecycle and long-term support timelines. BizTalk Server 2020 will be the final version of BizTalk Server. Guidance to support long-term planning for mission-critical workloads This announcement does not change existing support commitments. Customers can continue to rely on BizTalk Server for many years ahead, with a clear and predictable runway to plan modernization at a pace that aligns with their business and regulatory needs. Lifecycle Phase End Date What’s Included Mainstream Support April 11, 2028 Security + non-security updates and Customer Service & Support (CSS) support Extended Support April 9, 2030 CSS support, Security updates, and paid support for fixes (*) End of Support April 10, 2030 No further updates or support (*) Paid Extended Support will be available for BizTalk Server 2020 between April 2028 and April 2030 for customers requiring hotfixes for non-security updates. CSS will continue providing their typical support. BizTalk Server 2016 is already out of mainstream support, and we recommend those customers evaluate a direct modernization path to Azure Logic Apps. Continued Commitment to Enterprise Integration Microsoft remains fully committed to supporting mission-critical integration, including hybrid connectivity, future-ready orchestration, and B2B/EDI modernization. Azure Logic Apps, part of Azure Integration Services — which includes API Management, Service Bus, and Event Grid — delivers the comprehensive integration platform for the next decade of enterprise connectivity. Host Integration Server: Continued Support for Mainframe Workloads Host Integration Server (HIS) has long provided essential connectivity for organizations with mainframe and midrange systems. To ensure continued support for those workloads, Host Integration Server 2028 will ship as a standalone product with its own lifecycle, decoupled from BizTalk Server. This provides customers with more flexibility and a longer planning horizon. Recognizing Mainframe modernization customers might be looking to integrate with their mainframes from Azure, Microsoft provides Logic Apps connectors for mainframe and midrange systems, and we are keen on adding more connectors in this space. Let us know about your HIS plans, and if you require specific features for Mainframe and midranges integration from Logic Apps at: https://aka.ms/lamainframe Azure Logic Apps: The Successor to BizTalk Server Azure Logic Apps, part of Azure Integration Services, is the modern integration platform that carries forward what customers value in BizTalk while unlocking new innovation, scale, and intelligence. With 1,400+ out-of-box connectors supporting enterprise, SaaS, legacy, and mainframe systems, organizations can reuse existing BizTalk maps, schemas, rules, and custom code to accelerate modernization while preserving prior investments including B2B/EDI and healthcare transactions. Logic Apps delivers elastic scalability, enterprise-grade security and compliance, and built-in cost efficiency without the overhead of managing infrastructure. Modern DevOps tooling, Visual Studio Code support, and infrastructure-as-code (ARM/Bicep) ensure consistent, governed deployments with end-to-end observability using Azure Monitor and OpenTelemetry. Modernizing Logic Apps also unlocks agentic business processes, enabling AI-driven routing, predictive insights, and context-aware automation without redesigning existing integrations. Logic Apps adapts to business and regulatory needs, running fully managed in Azure, hybrid via Arc-enabled Kubernetes, or evaluated for air-gapped environments. Throughout this lifecycle transition, customers can continue to rely on the BizTalk investments they have made while moving toward a platform ready for the next decade of integration and AI-driven business. Charting Your Modernization Path Microsoft remains fully committed to supporting customers through this transition. We recognize that BizTalk systems support highly customized and mission-critical business operations. Modernization requires time, planning, and precision. We hope to provide: Proven guidance and recommended design patterns A growing ecosystem of tooling supporting artifact reuse Unified Support engagements for deep migration assistance A strong partner ecosystem specializing in BizTalk modernization Potential incentive programs to help facilitate migration for eligible customers (details forthcoming) Customers can take a phased approach — starting with new workloads while incrementally modernizing existing BizTalk deployments. We’re Here to Help Migration resources are available today: Overview: https://aka.ms/btmig Best practices: https://aka.ms/BizTalkServerMigrationResources Video series: https://aka.ms/btmigvideo Feature request survey: https://aka.ms/logicappsneeds Reactor session: Modernizing BizTalk: Accelerate Migration with Logic Apps - YouTube We encourage customers to engage their Microsoft accounts team early to assess readiness, identify modernization opportunities, and explore assistance programs. Your Modernization Journey Starts Now BizTalk Server has played a foundational role in enterprise integration success for more than two decades. As you plan ahead, Microsoft is here to partner with you every step of the way, ensuring operational continuity today while unlocking innovation tomorrow. To begin your transition, please contact your Microsoft account team or visit our migration hub. Thank you for your continued trust in Microsoft and BizTalk Server. We look forward to partnering closely with you as you plan the future of your integration platforms. Frequently Asked Questions Do I need to migrate now? No. BizTalk Server 2020 is fully supported through April 11, 2028, with paid Extended Support available through April 9, 2030, for non-security hotfixes. CSS will continue providing their typical support. You have a long and predictable runway to plan your transition. Will there be a new BizTalk Server version? No. BizTalk Server 2020 is the final version of the product. What happens after April 9, 2030? BizTalk Server will reach End of Support, and security updates or technical assistance will no longer be provided. Workloads will continue running but without Microsoft servicing. Is paid support available past 2028? Yes. Paid extended support will be available through April 2030 for BizTalk Server 2020 customers looking for non-security hotfixes. CSS will continue to provide the typical support. What about BizTalk Server 2016 or earlier versions? Those versions are already out of mainstream support. We strongly encourage moving directly to Logic Apps rather than upgrading to BizTalk Server 2020. Will Host Integration Server continue? Yes. Host Integration Server (HIS) 2028 will be released as a standalone product with its own lifecycle and support commitments. Can I reuse BizTalk Server artifacts in Logic Apps? Yes. Most of BizTalk maps, schemas, rules, assemblies, and custom code can be reused with minimal effort using Microsoft and partner migration tooling. We welcome feature requests here: https://aka.ms/logicappsneeds Does modernization require moving fully to the cloud? No. Logic Apps supports hybrid deployments for scenarios requiring local processing or regulatory compliance, and fully disconnected environments are under evaluation. More information of the Hybrid deployment model here: https://aka.ms/lahybrid. Does modernization unlock AI capabilities? Yes. Logic Apps enables AI-driven automations through Agent Loop, improving routing, decisioning, and operational intelligence. Where do I get planning support? Your Microsoft account team can assist with assessment and planning. Migration resources are also linked in this announcement to help you get started. Microsoft CorporationAnnouncing the General Availability of the XML Parse and Compose Actions in Azure Logic Apps
The XML Operations connector We have recently added two actions for the XML Operations connector: Parse XML with schema and Compose XML with schema. With this addition, Logic Apps customers can now interact with the token picker during design time. The tokens are generated from the XML schema provided by the customer. As a result, the XML document and its contained properties will be easily accessible, created and manipulated in the workflow. XML parse with schema The XML parse with schema allow customers to parse XML data using an XSD file (an XML schema file). XSD files need to be uploaded to the Logic App schemas artifacts or an Integration account. Once they have been uploaded, you need to enter the enter your XML content, the source of the schema and the name of the schema file. The XML content may either be provided in-line or selected from previous operations in the workflow using the token picker. For instance, the following is a parsed XML: XML compose with schema The XML compose with schema allows customers to generate XML data, using an XSD file. XSD files need to be uploaded to the Logic App schemas artifacts or an Integration account. Once they have been uploaded, you should select the XSD file along with entering the JSON root element or elements of your input XML schema. The JSON input elements will be dynamically generated based on the selected XML schema. For instance, the following is a Composed file: Learnings from Transition from Public Preview to General Availability: Upon feedback received from multiple customers, we would love to share the following recommendations and considerations, that will you maximize the reliability, flexibility, and internationalization capabilities of XML Parse and Compose actions in Azure Logic Apps. Handling Array Inputs in XML Switch to array input mode when mapping arrays. By default, the Logic App Designer expects individual array items for XML elements with maxOccurs > 1. If you want to assign an entire array token, use the array input mode icon in the Designer. This avoids unnecessary For Each loops and streamlines your workflow. For instance, the following: Click the Switch to input entire array Enter your array token. Managing Non-UTF-8 Encoded XML Leverage the encoding parameter in XML Compose. Customers can specify the desired character encoding (e.g., iso-2022-jp for Japanese). This controls both the .NET XML writer settings and the output encoding, allowing for broader internationalization support. Example configuration: Use the XML writer settings property to set encoding as needed. Safe Transport of Binary and Non-UTF-8 Content Utilize the Logic App content envelope. The XML Compose action outputs content in a safe envelope, enabling transport of binary and non-UTF-8 content within the UTF-8 JSON payload. Downstream actions (e.g., HTTP Request) can consume this envelope directly. Content-Type Header Management XML Compose now specifies the exact character set in the Content-Type header. This ensures downstream systems receive the correct encoding information. For example, application/xml; charset=iso-2022-jp will be set for Japanese-encoded XML. Consuming XML Output in HTTP Actions Reference the XML output property directly in HTTP actions. The envelope’s content-type is promoted to the HTTP header, and the base64-encoded content is decoded and sent as the raw HTTP body. This preserves encoding and binary fidelity. Documentation and External References Consult official documentation for advanced scenarios: Support non-Unicode character encoding in Azure Logic Apps. Content-Type and Content-Encoding for clarifying header usage. Do not confuse Content-Type with Content-Encoding. Content-Type specifies character set encoding (e.g., UTF-8, ISO-2022-JP), while Content-Encoding refers to compression (e.g., gzip). Normalization and prefix and trailer trimming: Here is a sample that shows how XML normalization works for values, and how to achieve prefix and trailing trimming: XSD: <?xml version="1.0" encoding="utf-8"?> <xs:schema id="XmlNormalizationAndWhitespaceCollapsed" targetNamespace="http://schemas.contoso.com/XmlNormalizationAndWhitespace" elementFormDefault="qualified" xmlns="http://schemas.contoso.com/XmlNormalizationAndWhitespace" xmlns:mstns="http://schemas.contoso.com/XmlNormalizationAndWhitespace" xmlns:xs="http://www.w3.org/2001/XMLSchema"> <!-- simple type that preserves whitespace (like xs:string) --> <xs:simpleType name="PreserveString"> <xs:restriction base="xs:string" /> </xs:simpleType> <!-- normalizedString collapses CR/LF/TAB to spaces, but preserves leading/trailing and repeated spaces --> <xs:simpleType name="NormalizedName"> <xs:restriction base="xs:normalizedString" /> </xs:simpleType> <!-- token collapses runs of spaces and trims leading/trailing spaces --> <xs:simpleType name="TokenName"> <xs:restriction base="xs:token" /> </xs:simpleType> <!-- explicit whitespace collapse facet (equivalent to xs:token for this purpose) --> <xs:simpleType name="CollapsedName"> <xs:restriction base="xs:string"> <xs:whiteSpace value="collapse" /> </xs:restriction> </xs:simpleType> <xs:element name="root"> <xs:complexType> <xs:sequence> <xs:element name="header"> <xs:complexType> <xs:sequence> <xs:element name="id" type="xs:int" /> </xs:sequence> </xs:complexType> </xs:element> <xs:element name="row" maxOccurs="unbounded"> <xs:complexType> <xs:sequence> <xs:element name="id" type="xs:int" /> <!-- the three variants on whitespace handling for name and aliases --> <xs:element name="name" type="mstns:TokenName" /> <xs:element name="nameNormalized" type="mstns:NormalizedName" minOccurs="0" /> <xs:element name="nameCollapsed" type="mstns:CollapsedName" minOccurs="0" /> <xs:element name="namePreserved" type="mstns:PreserveString" minOccurs="0" /> </xs:sequence> </xs:complexType> </xs:element> </xs:sequence> </xs:complexType> </xs:element> </xs:schema> JSON: { ":Attribute:xmlns": "http://schemas.contoso.com/XmlNormalizationAndWhitespace", "header": { "id": 1002 }, "row": [ { "id": 1, "name": "cyckel1", "nameNormalized": " cyckel1 end ", "nameCollapsed": "cyckel1", "namePreserved": "cyckel1\r\n\tend" }, { "id": 2, "name": "cyckel2", "nameNormalized": "line1 line2 ", "nameCollapsed": "cyckel2", "namePreserved": "line1\nline2\t" }, { "id": 3, "name": "cyckel12", "nameNormalized": " tabs and lines", "nameCollapsed": "cyckel12", "namePreserved": "\ttabs\tand\r\nlines" } ] } XML: <?xml version="1.0" encoding="utf-8"?> <root xmlns="http://schemas.contoso.com/XmlNormalizationAndWhitespace"> <header> <id>1002</id> </header> <row> <id>1</id> <name>cyckel1 </name> <nameNormalized> cyckel1
	end </nameNormalized> <nameCollapsed>cyckel1 </nameCollapsed> <namePreserved>cyckel1
	end</namePreserved> </row> <row> <id>2</id> <name>cyckel2 </name> <nameNormalized>line1
line2	</nameNormalized> <nameCollapsed>cyckel2 </nameCollapsed> <namePreserved>line1
line2	</namePreserved> </row> <row> <id>3</id> <name> cyckel12</name> <nameNormalized>	tabs	and
lines</nameNormalized> <nameCollapsed> cyckel12</nameCollapsed> <namePreserved>	tabs	and
lines</namePreserved> </row> </root> Check this short video to learn more:Announcing the General Availability of the Azure Logic Apps Rules Engine
This week we announced our agent loop, a groundbreaking new capability in Azure Logic Apps to build AI agents into your enterprise workflows. With agent loop, you can embed advanced AI decision-making directly into your processes – enabling your apps and automation to not just follow predefined steps, but to reason, adapt, and act autonomously towards goals. Now, we are announcing the General Availability of our Azure Logic Apps Rules Engine. A deterministic rules engine runtime based on the RETE algorithm that allows in-memory execution, prioritization, and reevaluation of business rules in Azure Logic Apps. The Azure Logic Apps Rules Engine is a decision management inference engine in Azure Logic Apps, which provides the capability for customers to build Standard workflows in Azure Logic Apps and integrate readable, declarative, and semantically rich rules that operate on multiple data sources. The native data sources available today for the Rules Engine are XML and .NET objects. These data sources are called "facts" and are used to construct rules from small building blocks of business logic or "rulesets". To create rules, you need the Rules Composer. It can be downloaded from the download center. The Rules Engine can also interact with the data exchanged by all the connectors available for Standard logic app resources. This design pattern promotes code reuse, design simplicity, and business logic modularity. Our Rules engine uses a VSCode experience to create Logic Apps projects with Rules engine support. For more information on how to create projects with Rules Engine, visit here. Now. What can I do with it? In a world of AI that essentially follows a probabilistic approach, rules engines are vital because they provide consistency, clarity, and compliance across different business goals. When you use rules with a workflow in Azure Logic Apps, you can define the logic, constraints, and policies that govern how to process, validate, and exchange data across systems, while you avoid AI hallucinations. Rules also help you make sure that applications follow the regulations and standards of their respective industries and markets. By using a rules engine, you can manage and update your workflow's business logic independently from the code and without having to alter your workflow. This approach helps you reduce the complexity and maintenance costs of your applications and increase their agility and scalability. From a technical perspective, the Azure Logic Apps rules engine allows you to do forward chaining or forward reasoning, in other words to do a re-evaluation of rules triggered by changes in the facts because of a rule’s execution. This is one of those scenarios where rules engine is unique; instead of writing complex code or creating complex “state-machine” workflows, the logic apps rules engine conducts this task with an instruction called “Update”. Getting started In the example below, I will show how to use the Logic Apps rules engine to ground an AI workflow loop. For this to scenario, I am adding a Rules Engine workflow, to an existing agent loop workflow, and use it to correct rates and provide a “cross-sell” recommendation. First, I need to deploy the workflow from VSCode to Azure. As the rules engine currently only supports XML and .NET Framework objects, I create an XSD schema (using Copilot if you don’t have an existing one) and use it with a “Compose XML with schema” action to create the XML fact that is needed. To obtain the returned data, I am using the “Parse XML with schema” action as well. After the logic app was deployed, I added it as a tool in the Logic Apps agent workflow loop, with a Call workflow in this logic app. I then pass the values that I need for parameters for the Rules engine to work. And I leave the rules engine return values empty. Then I updated my system prompt to indicate how I want the Rules engine to be used. The agent loop will find the right tool for the right job. Once the system prompt has been updated, I proceed to run the workflow with a payload. I have highlighted in red in the Agent chat, the guardrails imposed by the Rules Engine. Those rules have been used to make sure that the AI responses fall within the internal compliance and cross-sell company criteria. Some of the business rules can have different priorities and might require re-calculation for accuracy. The Logic Apps Rules Engine takes care of it without coding or adding complex business logic through additional workflows. Further adjustments to the rules using the Rules Composer will ground the agent’s results even more. What else can I do with it? You can use a Rules Engine in any context. In fact, decision management that falls under Intelligent business processes automation is growing in customers who want to provide flexibility, governance and compliance with their cloud workloads. Another well-known scenario is for BizTalk Migrations to Azure Logic Apps. For customers who have implemented the BizTalk BRE for decision management, content redirection, SWIFT or .NET framework. Demo Please watch the following short demo of this sample. How to use it If you are running the public preview version of the Rules engine, we recommend you to recreate your Rules engine project to get the latest rules engine nuget package loaded. If you cannot recreate your project, conduct the following steps: Update to csproj file by adding the rules engine nuget and updating the Webjob sdk nuget as follows: <PackageReference Include="Microsoft.Azure.Workflows.RulesEngine" Version="1.0.0" /> <PackageReference Include="Microsoft.Azure.Workflows.WebJobs.Sdk" Version="1.2.0" /> Update to the code making the rule explorer to be created as part of the constructor: public user_function_class(ILoggerFactory loggerFactory) { logger = loggerFactory.CreateLogger<user_function_class>(); this.ruleExplorer = new FileStoreRuleExplorer(loggerFactory); } The above rule explorer needs to be used for getting any rule set in the RunRules method as: var ruleSet = this.ruleExplorer.GetRuleSet(ruleSetName); Open a terminal and run dotnet restore Run dotnet build. Contact Us Have feedback or questions about the Rules Engine? We’d love to hear from you. Reply directly to this blog post or reach out to us through this form. Your input helps shape the future of Logic Apps and the rules engine.
