Logic Apps Aviators Newsletter - November 2026
In this issue: Ace Aviator of the Month News from our product group News from our community Ace Aviator of the Month November 2026's Ace Aviator: Steef-Jan Wiggers Coöperatie VGZ What's your role and title? What are your responsibilities? I'm a Domain Architect Technology in the Business Change department at VGZ, one of the largest health insurers in the Netherlands. I'm responsible for defining architecture building blocks and target architectures. I also investigate which technologies can help us and what changes our IT landscape needs to support the IT capabilities VGZ requires. Can you give us some insights into your day-to-day activities and what a typical day in your role looks like? Each week starts on Monday with our week start, where I meet with peers on a range of architectural topics. From there, no two weeks are the same. I create target architectures for IT capabilities such as integration, cloud, artificial intelligence and, most recently, search. These building blocks describe the “what” and feed into solution architecture, which works out the “how”. Getting to a well-defined target architecture means talking every day with peers and stakeholders across the organisation. I also make time to explore new technology hands-on, to see whether it fits our needs. I share what I find internally in what we call Business Change colleges, knowledge sessions for colleagues. And I'm in frequent contact with Microsoft, both the local team in the Netherlands and the product groups in Redmond. What motivates and inspires you to be an active member of the Aviators/Microsoft community? I've worked in integration for over 20 years. I started with BizTalk Server and today I work with Azure Integration Services. Along the way I've designed, built and deployed many integration solutions, on-premises, hybrid and in the cloud. I've always enjoyed sharing what I learn with peers, through blogging, writing books, editing for InfoQ, and speaking at user groups and conferences such as Integrate and NIS. Sharing knowledge comes back to you many times over: it has given me great opportunities, and above all many friends in the community. Looking back, what advice do you wish you had been given earlier that you'd now share with those looking to get into STEM/technology? Stay curious, and don't wait until you feel like an expert to share what you know. Writing a blog post, giving a talk at a local user group, or just asking questions in the community speeds up your learning enormously and connects you with people who will help you grow. Also, learn the fundamentals well. Technologies change; integration went from BizTalk to Logic Apps. But patterns, principles and how you approach a problem last a whole career. What has helped you grow professionally? Curiosity about how things work. I learn by trying things out and building demos, and I read a lot: books, blogs, documentation. Attending, and later speaking at, user groups and conferences has been just as important. So has staying close to Microsoft, locally and with the product groups in Redmond. The conversations with peers and product teams have taught me as much as any technology. If you had a magic wand that could create a feature in Logic Apps, what would it be and why? A seamless, browser-based development experience with native GitHub integration. The designer in the browser offers the best experience for building Logic Apps, better than VS Code. But today, getting a workflow into source control means exporting it, working locally, and then pushing it. I'd love to do it all in the browser: design the Logic App, commit it straight to the repository, and let a pipeline deploy it to the other environments. That would bring the ease of the designer and proper DevOps practices together. News from our product group Introducing the Logic Apps local CLI: develop Standard workflows from your terminal Microsoft has introduced a public preview Azure CLI extension for local Logic Apps Standard development. It supports project creation, connector discovery, connection configuration, runtime management, workflow validation, and execution diagnostics from the terminal. Developers can invoke commands directly, automate them in scripts, or let coding agents use them with approval. The extension complements the visual designer and existing Azure resource-management commands rather than replacing them. An accompanying Copilot skill guides schema discovery, authentication choices, validation, and execution checks, helping teams ground development and review in observable tool results instead of assumptions. Hybrid Logic Apps - SQL as storage provider benchmarking This benchmark examines SQL Server storage behavior under a file-triggered Hybrid Logic Apps workload in a disconnected, single-node OpenShift environment. SQL Server 2025, file storage, and the cluster share one Windows host and backing disk. Two thirty-minute tests recorded no failed runs; the one-hour dashboard showed 45,821 successful executions. SQL averaged 1.83% of host CPU capacity, while storage contention and tail latency remained important scaling considerations. The article recommends dedicated storage as volumes grow and capacity planning based on peak and tail measurements, stressing that these results describe one workload rather than a general capacity guarantee. 🆕Orchestrate Foundry Prompt and Hosted Agents with Logic Apps Automation Logic Apps Automation can orchestrate Microsoft Foundry Prompt Agents and Hosted Agents as steps in business workflows. API calls, schedules, and connector events can trigger agents, with deterministic actions gathering inputs and validating or acting on outputs. The article distinguishes configured Prompt Agents from container-based Hosted Agents that support custom code and orchestration. Logic Apps provides branching, retries, timeouts, parallel execution, and run history around agent calls. It also outlines a migration path ahead of Foundry workflows retiring on December 1, 2026, helping teams move interactive agents into traceable, event-driven business processes. From Form to Action: A Governed, Event-Driven AI Intake Pipeline with Azure Integration Services This reference architecture turns document-heavy permit intake into governed, asynchronous processing with Azure Integration Services and Microsoft Foundry. API Management controls entry and model access, while Logic Apps validates, enriches, and routes submissions to Service Bus. An Azure Function uses Document Intelligence and a Foundry model before writing a case record and publishing an Event Grid event. A shared correlation ID connects intake, processing, and downstream notifications. The article emphasizes durable hand-off, explicit failure handling, controlled model consumption, and traceability, with an accompanying repository that supports offline exploration without an Azure subscription. 💲Announcing Free Grant and Pricing for Logic Apps Automation Microsoft has announced pricing and free grants for Logic Apps Automation, currently in public preview. Monthly allowances per Azure subscription include 108,000 workflow execution-seconds, 1 GB of data retention, 1,000 Standard and 500 Enterprise managed connector calls, knowledge storage, and AI usage. One managed environment is free only for the first sixty days, unlike the recurring monthly usage grants. Usage beyond the included limits is billed separately. The article explains how teams can experiment and run initial automations within those allowances, then plan paid usage as business process and AI orchestration workloads grow. News from our community Logic Apps Community Day 2026: Agenda and Speakers Announced Event by Ahmed Bayoumy and Sebastian Meyer The agenda and speaker lineup for Logic Apps Community Day 2026 are now published, with the event taking place on December 3, 2026. This free, online community event will stream live on YouTube and is open to attendees worldwide. Eight talks combine longer sessions and lightning talks, covering AI and automation, enterprise architecture, production operations, scalability, and BizTalk migration. Q&A slots between talks provide opportunities to engage with the speakers. The official event page includes the full agenda, speaker details, and an option to add the event to a calendar. Don't Rebuild Your Workflows Inside Agents: Calling Azure Logic Apps from Microsoft Foundry, Securely Post by Rob McKenna Enterprise agents can reuse reviewed business processes rather than duplicate workflow logic inside prompts or agent code. This article demonstrates a Microsoft Foundry agent invoking a Logic Apps workflow through an OpenAPI tool, using managed identity and Entra authorization instead of SAS keys. A synthetic prior-authorization scenario combines a lookup, business-day calculation, escalation, and notification before returning a plain-language response. The approach keeps business rules in the existing workflow while separating conversational interaction from execution, providing a concrete pattern for securely exposing established integrations as agent tools. When Liquid transform in Logic Apps doesn't Behave like Liquid: A subtle string to integer pitfall Post by Şahin Özdemir Generating a date ten years ahead exposes a subtle type-conversion problem in Logic Apps Liquid transformations. The underlying DotLiquid implementation can treat a formatted year as a string, producing concatenation rather than the expected arithmetic result. Common integer-conversion techniques do not reliably resolve the issue. The article demonstrates converting through a floating-point value with the Times: 1.0 filter and applying Round before completing the calculation. This practical example helps integration developers distinguish Liquid syntax from runtime-specific behavior and avoid prolonged debugging of seemingly simple transformation logic. Logic Apps Standard brings freedom Post by Mikael Sand Choosing between Logic Apps Consumption and Standard involves more than comparing per-action charges with a fixed runtime cost. This article argues that Standard allows integration design to focus on business requirements rather than minimizing transactions, particularly when built-in operations process large volumes of records. It describes greater cost predictability within runtime capacity while acknowledging additional infrastructure ownership and networking complexity. Capacity, connectivity, DNS, routing, and firewall configuration remain operational responsibilities. The comparison helps teams weigh architectural flexibility against management overhead when treating integration as a strategic platform capability. Logic Apps and AI Agents: Building Agentic Workflows on Azure Integration Services Post by Mirko Peters Agentic integration design requires choosing an appropriate platform owner as well as connecting a model to business systems. This guide compares Logic Apps with Power Automate, distinguishing Azure resource management, managed identities, infrastructure templates, and monitoring from maker-oriented environments and governance. It explains agent workflow concepts and describes tools as named collections of actions with clear responsibilities. Model configuration and pricing vary by hosting plan, and some capabilities remain in preview. The discussion helps architects separate ownership, tool design, and runtime considerations before building AI-driven business processes. Microsoft Fabric and Logic Apps Side by Side Video by Sebastian Meyer Connecting real-time analytics to operational workflows allows detected business events to initiate action rather than remain dashboard observations. This video demonstrates combining Microsoft Fabric Real-Time Intelligence with business processes built in Logic Apps. The accompanying post describes events arriving from coffee stores and handing relevant information to the integration platform through the Logic Apps Automation SKU. The example separates event detection on the data platform from process execution on the integration platform, illustrating how teams can connect these responsibilities without treating analytics and business automation as unrelated systems. Getting Started Logic App Standard in Azure Video by Stephen W. Thomas Moving locally developed workflows into Azure requires a configured hosting environment as well as a deployment step. This fourteen-minute walkthrough demonstrates creating a Logic Apps Standard environment and deploying a local project from Visual Studio Code. It covers the Workflow Service Plan, storage, application settings, portal-based workflow creation, and connection-string management. The accompanying post also highlights removing the unused hosting plan during demo cleanup to stop further charges. The tutorial gives developers a practical sequence for taking local integration work into the cloud while considering configuration and resource lifecycle. Azure Logic Apps Automation: A New Approach to Dynamic, AI-Powered Business Process Automation Post by Manoj Sethuraman Business processes involving unstructured information, changing rules, and frequent exceptions can be difficult to express as fully predefined workflows. This article introduces Logic Apps Automation as an adaptive approach combining contextual AI decisions, organizational knowledge, human involvement, and enterprise integrations. It outlines project boundaries for governance and isolation, deployable applications containing process assets, and executable workflows combining triggers and actions. The comparison with traditional deterministic automation helps architects consider where runtime flexibility is useful while retaining explicit boundaries around deployment, oversight, and integration responsibilities across business functions. 📈 Daily Exchange Rates, Zero Manual Effort: D365FO + Logic Apps Post by Anitha Eswaran Daily exchange-rate imports can become repetitive and error-prone when an SFTP folder retains both historical and newly delivered files. This article describes a Logic Apps integration that identifies current-day files before submitting them to Dynamics 365 Finance and Operations through an enqueue-based approach. A scheduled workflow starts after the expected delivery time, lists files with the built-in SFTP connector, and evaluates metadata to filter processing. The example demonstrates how selection and validation steps reduce repeated historical imports and unnecessary work while automating a recurring finance integration requirement. What's New with Logic Apps Automation Post by Sagar Sharma The NIS 2026 updates connect Logic Apps Automation capabilities with practical environment and subscription planning. This recap covers managed AI models, reusable templates, development-platform connectors, and orchestration of Foundry and managed agents. It separates agent construction and governance from workflow triggering and business-system integration. Pricing combines a managed-environment base fee, compute that scales to zero, and optional capabilities, alongside free allowances. The article also distinguishes announced features from roadmap items, helping integration architects assess operational ownership, environment counts, and experimentation costs before designing an automation platform. Coders, What's new with Low Code Logic Apps? Post by Sagar Sharma Integration developers need local build, test, debug, and deployment loops that work with source control and coding agents. This NIS recap examines the Logic Apps Standard SDK, which expresses workflows through typed C# and a fluent API, allowing compiler feedback to catch mistakes earlier. It also discusses the local CLI lifecycle and Connector Namespace as managed connectivity for applications and agents. The article frames these capabilities as complementary developer surfaces, helping teams combine low-code orchestration with familiar software-engineering practices while checking release details before relying on illustrative commands. BizTalk End of Support: Logic Apps Migration Agent, Hybrid and Microsoft Migration Incentives Post by Sagar Sharma Planning a BizTalk migration requires more than waiting for the support deadline or converting individual artifacts. This article reviews lifecycle considerations and introduces the AI-assisted Logic Apps Migration Agent for assessing, planning, converting, validating, and deploying workloads to Standard. Three Copilot agents share a five-stage pipeline, with human approval between stages. The discussion also covers map reuse, hybrid deployment, and migration incentives. It positions tooling as an accelerator rather than a replacement for architectural judgment, helping teams structure discovery and validation around the dependencies and business behavior of an existing integration estate.Modernize Any Integration Platform to Azure Logic Apps Standard with the Logic Apps Migration Agent
Explore the open-source Logic Apps Migration Agent Enterprise integration is entering a new era Enterprise integration platforms have powered business-critical processes for decades. They connect applications, data, partners, devices, and industries, often carrying transactions that an organization cannot afford to interrupt. Expectations have changed. Organizations want cloud-native architectures, AI-assisted automation, stronger governance, improved developer productivity, and faster response to business change. Yet many integration estates contain years of accumulated dependencies, custom code, transformations, operational procedures, and platform-specific knowledge. The challenge is not simply moving an orchestration or flow from one runtime to another. This is not lift and shift. It is a refactoring exercise that preserves business intent and expected behavior while translating source-platform constructs into cloud-ready workflows, connectors, code, operational patterns, and deployment practices for Azure Logic Apps Standard. That is why we created the Logic Apps Migration Agent. Introducing the Logic Apps Migration Agent: An Open-source project to provide an AI End-to-End Modernization Experience The Logic Apps Migration Agent is an open-source Visual Studio Code extension that provides an AI-assisted, end-to-end modernization experience. It uses GitHub Copilot and the Visual Studio Code Language Model API to guide teams through a structured five-stage workflow, while keeping people in control at every stage. Rather than treating modernization as a single conversion step, the agent helps teams discover what they have, understand dependencies, design an appropriate target, generate baseline implementation artifacts, validate expected behavior, and prepare the solution for deployment to Azure Logic Apps Standard. Refactor the implementation, preserve the business intent Lift and shift attempts to reproduce the source platform as closely as possible in a new environment. That approach can carry forward legacy topology, operational assumptions, platform-specific patterns, and technical debt. The Migration Agent supports a different outcome. It uses the source implementation as evidence of the required business behavior, then helps teams design and generate an appropriate Logic Apps Standard implementation. Some components may map directly, while others require restructuring, consolidation, decomposition, replacement, or custom implementation. The objective is functional and semantic continuity, not structural duplication. A successful migration should preserve contracts, transformations, routing rules, ordering requirements, error behavior, and essential business outcomes while allowing the target solution to adopt Azure-native identity, connectivity, observability, resiliency, deployment, and operating practices. Preserve what the integration must do. Refactor how it does it. Start by understanding what you have For many organizations, discovery is one of the most difficult parts of modernization. Documentation may be incomplete, original developers may no longer be available, and relationships between applications, endpoints, schemas, maps, pipelines, and custom components may be difficult to reconstruct. The Migration Agent scans the source project, catalogs supported artifacts, organizes related components into flow groups, and identifies dependencies and migration gaps. It can also generate architecture and message-flow visualizations for review before conversion begins. This discovery output becomes the foundation for migration sequencing, refactoring decisions, effort discussions, and risk management. Use AI to accelerate the work, not remove accountability The Migration Agent uses specialized GitHub Copilot agents for analysis, planning, and conversion. AI helps interpret source artifacts, propose mappings, create task plans, and generate baseline Logic Apps artifacts. Enterprise integration, however, requires more than plausible code generation. Human-in-the-loop checkpoints let teams review discovered flows, resolve missing dependencies, reshape the proposed architecture, approve conversion plans, and validate generated behavior before progressing. This combines the speed of AI assistance with the governance and technical review required for mission-critical integration. Modernize incrementally and reduce migration risk Large integration estates do not need a single big-bang program. The Migration Agent organizes work into logical flow groups so teams can refactor one business capability or integration path at a time. Prioritize workloads by business value, risk, complexity, or platform urgency. Validate target architecture and operating patterns with a representative first migration. Run phased cutovers and coexistence strategies when required. Apply reusable refactoring patterns, templates, and engineering standards to subsequent waves. A phased approach helps teams build experience with Azure Logic Apps while reducing migration risk and preserving delivery momentum. Bring your own tests and validate continuously Migration confidence depends on behavior, not structural similarity. The agent supports validation using source specifications, sample files, test cases, and customer-provided black-box tests. This helps compare expected inputs and outputs and identify semantic differences earlier. Generated artifacts are a baseline. Domain-specific transformations, error-handling behavior, performance characteristics, security controls, and edge cases still require customer and partner expertise. Built for BizTalk today and extensible for other platforms BizTalk Server 2016 and BizTalk Server 2020 are the first fully implemented source platforms. MuleSoft Anypoint support is represented as an in-progress built-in parser. The architecture is open and extensible so contributors can add parsers and platform-specific migration capabilities for other integration technologies. That extensibility is central to the vision. A common modernization workflow can help teams apply consistent governance, target patterns, refactoring practices, and validation across mixed integration estates. Why Azure Logic Apps Standard? Azure Logic Apps Standard provides a modern destination with a local project structure, Visual Studio Code development experience, source-control alignment, CI/CD support, stateful and stateless workflows, enterprise connectivity, and Azure and hybrid deployment options. Modernization is not about reproducing a legacy topology component by component. The target design should be optimized for Logic Apps Standard rather than constrained by the source architecture. The migration preserves valuable business logic while refactoring the implementation around modern practices for identity, networking, observability, reliability, deployment, and operations. What your team should still own The Migration Agent accelerates repeatable work, but it does not replace the decisions that define a production-ready integration platform. Responsibility Refactoring focus Target architecture Refactor application and workflow boundaries for Logic Apps Standard. Select reliability, networking, deployment, and supporting Azure patterns rather than copying the source topology. Semantic equivalence Validate contracts, mappings, transformations, business rules, error behavior, ordering, retries, and edge cases. Capability gaps Redesign source capabilities without direct equivalents using connectors, custom code, local functions, API Management, Service Bus, or other appropriate Azure patterns. Production hardening Implement identity, secrets management, security policies, monitoring, cost controls, performance testing, resiliency, and operational ownership. Cutover and coexistence Plan backlog reconciliation, dual-run periods, data consistency, partner coordination, rollback, and decommissioning. More mission critical features for Logic Apps Standard and Hybrid We are weeks away from shipping the following features, aimed at any customers in the Enterprise Application Integration space: HL7 In-App operations in general availability. MLLP Receive/Send In-App connector in Public Preview. Rules Engine In-App operation for XML facts in Public Preview. MSMQ In-App connector in Public Preview. Oracle DB In-App connector in Public Preview. Flat File generation In-App operations in Public Preview. Integration accounts support (Hybrid On premises). NMS In-App connector in Public Preview. Improvements to our EDI capabilities. BizTalk Mapper to Data Mapper Migration path What about other integration platforms? Yes—the Logic Apps Migration Agent is designed to be customizable so you can migrate from any integration platform to Logic Apps (not just BizTalk). The open architecture lets you plug in new discovery, analysis, and conversion skills for the source product you’re modernizing, while keeping the same stage-gated workflow and human-in-the-loop checkpoints. We provide guidance and examples to help you extend the agent for other platforms than BizTalk —so you can tailor mappings, transformation rules, and validation to your customer’s standards and target patterns in Logic Apps. Benefits Faster time to value with a guided process: A structured discovery→planning→conversion workflow reduces uncertainty and helps teams move from assessment to execution with clear checkpoints. Higher confidence migrations: Human-in-the-loop validation, artifacts generation, and black-box testing support mission‑critical correctness and governance. Customizable for your source platform and standards: Extend the agent with product-specific discovery and conversion steps, tailor mappings and transformation rules, and align outputs with your target Logic Apps patterns and engineering conventions. Open-source transparency and control: Review how the tool works end-to-end, validate what it produces, and adopt changes at your pace without waiting for a closed release cycle. Community-driven innovation: Benefit from contributions across Microsoft, partners, and customers—new adapters, mapping packs, and best practices can be shared and reused. Lower total migration cost: Automating repeatable tasks reduces manual effort while preserving the ability to invest partner expertise where it matters most (architecture, governance, reliability, and operations). Reusable accelerators for partners: Partners can create differentiated offerings by packaging templates, validation suites, CI/CD pipelines, and domain-specific patterns on top of the agent. An accelerator for customers and partners For customers, the Migration Agent provides a practical starting point and a consistent process for moving from assessment to a refactored implementation. For professional services organizations and system integrators, the agent augments delivery rather than replacing it. Automating inventory, analysis, baseline generation, and validation scaffolding allows experts to focus on architecture, governance, security, reliability, domain-specific transformation, DevOps, performance, cutover, and operating-model change. Because the project is open source, partners can contribute parsers or package reusable templates, mapping packs, test suites, CI/CD assets, and industry-specific modernization patterns. Review our public documentation here: https://learn.microsoft.com/en-us/azure/logic-apps/migration/migration-agent-overview How to get started Download VSCode and install the Logic Apps Migration Agent extension. Organize source projects and dependencies in a clear directory structure. Include project files, bindings, schemas, maps, pipelines, orchestrations, custom code, configuration, certificates or certificate references, and available documentation. Once you have all your artifacts ready, point the Migration Agent to the directory with all the artifacts. Review every migration stage. Confirm the discovered architecture, resolve missing dependencies, and refine the target design before authorizing conversion. Prepare a representative test environment. The workstation running Visual Studio Code must be able to reach the systems needed for local or end-to-end validation. Bring known inputs, expected outputs, specifications, and existing test cases whenever possible. These materials improve validation and reduce ambiguity. Treat the first migration as a reusable foundation. Capture architecture patterns, naming standards, deployment templates, observability practices, and lessons that can accelerate subsequent waves. Use Claude Opus 4.8 or higher. Make sure you increase the Maximum number of requests for the Copilot Chat as follows (we recommend changing the value from 60 to 1000) Check the following video for a demonstration on how the Agent works and let us know if you have any questions in the comments.A BizTalk Migration Tool: From Orchestrations to Logic Apps Workflows
As organizations move toward cloud-native architecture, this project addresses one of the most challenging aspects of modernization: converting existing BizTalk artifacts into their Azure Logic Apps equivalents while preserving business logic and integration patterns. Architecture and Components The BizTalk Migration Starter is available here: haroldcampos/BizTalkMigrationStarter and consists of four main projects and a test project, each targeting a specific aspect of BizTalk migration: BTMtoLMLMigrator - BizTalk Map Converter The BTMtoLMLMigrator is a tool that converts BizTalk Maps (.btm files) to the Logic Apps Mapping Language (.lml files). BizTalk maps define data transformations between different message formats, using XSLT and functoids to implement complex mapping logic. Input: Output: Key Capabilities: Parses BizTalk map XML structure to extract transformation logic. Translates BizTalk functoids (string manipulation, mathematical operations, logical operations, date/time functions, etc.) to equivalent LML syntax Preserves source and target schema references Generates Logic Apps-compatible Liquid maps that can be directly deployed to Azure Integration Accounts Core Components: BtmParser.cs: Extracts map structure, functoid definitions, and link connections from BTM files FunctoidTranslator.cs: Converts BizTalk functoid operations to Logic Apps Maps template equivalents LmlGenerator.cs: Generates the final LML output BtmMigrator.cs: Orchestrates the entire conversion process Models.cs: Defines data structures for representing maps, functoids, and links To convert a single map: BTMtoLMLMigrator.exe -btm "C:\BizTalkMaps\OrderToInvoice.btm" -source "C:\Schemas\Order.xsd" -target "C:\Schemas\Invoice.xsd" -output "C:\Output\OrderToInvoice.lml" To Convert all maps in a directory: Be mindful of having the right naming for schemas in the BizTalk maps to avoid the tool picking up the wrong schemas: BTMtoLMLMigrator.exe -batchDir "C:\BizTalkMaps" -schemasDir "C:\Schemas" -outputDir "C:\Output\LMLMaps" Recommendations and Troubleshooting: Make sure to use the real schemas, source and destination, and the corresponding map. Most BizTalk functoids are supported, however for those who don’t, like scripting, it will add the code into the lml file, expecting you to conduct a re-design of the scenario. Currently the Data Mapper does not have a direct function that replaces scripting functoids. We are exploring alternatives for this. Use GHCP agent to troubleshoot the tool if you run into issues. ODXtoWFMigrator - Orchestration to Workflow Converter The ODXtoWFMigrator tackles one of the most complex aspects of BizTalk migration: converting BizTalk Orchestrations (.odx files) to Azure Logic Apps workflow definitions. Orchestrations represent business processes with sequential, parallel, and conditional logic flows. It requires the orchestration and bindings file, exported from the BizTalk Application. If you don't have orchestration, for Content Routing Based scenarios, it uses the bindings file only. Go to BizTalk Central Admin. Select your BizTalk Application: Export all bindings. You can have multiple orchestrations in one binding file, so is important to export all the information available. Input: Output: Key Capabilities: Parses BizTalk orchestration XML to extract process flows, shapes, and connections Maps BizTalk orchestration shapes (Receive, Send, Decide, Parallel, Loop, etc.) to Logic Apps actions and control structures Generates connector configurations for common integration patterns Creates comprehensive migration reports documenting the conversion process and any limitations Produces standard Logic Apps JSON workflow definitions ready for deployment Core Components: BizTalkOrchestrationParser.cs: Analyzes orchestration structure and extracts workflow patterns LogicAppsMapper.cs: Maps BizTalk orchestration shapes to Logic Apps equivalents LogicAppJSONGenerator.cs: Generates the final Logic Apps workflow JSON OrchestrationReportGenerator.cs: Creates detailed migration reports. Schemas/Connectors/connector-registry.json: Registry of connector mappings and configurations Recommendations and Troubleshooting: Most BizTalk shapes are supported, however for those who don’t, it will default to compose actions and inject the code or a comment. It supports most BizTalk adapters. If you need to add support to a new Logic Apps connector/service provider, you can update the connector-registry.json file by adding the trigger or action following the pattern for the other entries. This tool has been tested with multiple patterns and orchestrations. Use GHCP agent to troubleshoot the tool if you run into issues. The following are some of the supported commands. Please run the command line and review the README files to see all supported commands. Command Sample Usage MIGRATE / CONVERT With output file ODXtoWFMigrator.exe convert "C:\BizTalk\InventorySync.odx" "C:\BizTalk\BindingInfo.xml" "C:\Output\InventorySync.workflow.json" With refactored generator ODXtoWFMigrator.exe migrate "C:\BizTalk\MessageRouter.odx" "C:\BizTalk\BindingInfo.xml" --refactor BINDINGS-ONLY Basic bindings-only ODXtoWFMigrator.exe bindings-only "C:\BizTalk\ProductionBindings.xml" With output directory ODXtoWFMigrator.exe bindings-only "C:\BizTalk\BindingInfo.xml" "C:\LogicApps\BindingsWorkflows" With refactored generator ODXtoWFMigrator.exe bindings-only "C:\BizTalk\BindingInfo.xml" --refactor REPORT / ANALYZE Basic HTML report ODXtoWFMigrator.exe report "C:\BizTalk\OrderProcessing.odx" With output file ODXtoWFMigrator.exe report "C:\BizTalk\OrderProcessing.odx" --output "C:\Reports\OrderProcessing_Analysis.html" BATCH REPORT Process directory ODXtoWFMigrator.exe batch report --directory "C:\BizTalk\Orchestrations" Short directory flag ODXtoWFMigrator.exe batch report -d "C:\BizTalk\ContosoProject\Orchestrations" BATCH CONVERT Basic batch convert ODXtoWFMigrator.exe batch convert --directory "C:\BizTalk\Orchestrations" --bindings "C:\BizTalk\BindingInfo.xml" Alternative migrate syntax ODXtoWFMigrator.exe batch migrate -d "C:\BizTalk\AllOrchestrations" -b "C:\BizTalk\BindingInfo.xml" Specific files ODXtoWFMigrator.exe batch convert --files "C:\BizTalk\Order.odx,C:\BizTalk\Invoice.odx" --bindings "C:\BizTalk\BindingInfo.xml" With output directory ODXtoWFMigrator.exe batch convert -d "C:\BizTalk\Orchestrations" -b "C:\BizTalk\BindingInfo.xml" -o "C:\LogicApps\Workflows" With refactored generator ODXtoWFMigrator.exe batch convert -d "C:\BizTalk\Orchestrations" -b "C:\BizTalk\BindingInfo.xml" --refactor GENERATE-PACKAGE Basic package generation ODXtoWFMigrator.exe generate-package "C:\BizTalk\OrderProcessing.odx" "C:\BizTalk\BindingInfo.xml" With output directory ODXtoWFMigrator.exe generate-package "C:\BizTalk\OrderProcessing.odx" "C:\BizTalk\BindingInfo.xml" "C:\Deploy\OrderProcessing" With refactored generator ODXtoWFMigrator.exe package "C:\BizTalk\CloudIntegration.odx" "C:\BizTalk\BindingInfo.xml" --refactor ANALYZE-ODX / GAP-ANALYSIS Analyze directory ODXtoWFMigrator.exe analyze-odx "C:\BizTalk\LegacyOrchestrations" With output report ODXtoWFMigrator.exe analyze-odx "C:\BizTalk\Orchestrations" --output "C:\Reports\gap_analysis.json" LEGACY MODE Legacy basic ODXtoWFMigrator.exe "C:\BizTalk\OrderProcessing.odx" "C:\BizTalk\BindingInfo.xml" "C:\Output\OrderProcessing.json" BTPtoLA - Pipeline to Logic Apps Converter BTPtoLA handles the conversion of BizTalk pipelines to Logic Apps components. BizTalk pipelines process messages as they enter or leave the messaging engine, performing operations like validation, decoding, and transformation. Key Capabilities: Converts BizTalk receive and send pipelines to Logic Apps processing patterns Maps pipeline components (decoders, validators, disassemblers, etc.) to Logic Apps actions Preserves pipeline stage configurations and component properties Generates appropriate connector configurations for pipeline operations Input: Output: Core Components: Pipeline parsing and analysis logic Connector registry (Schemas/Connectors/pipeline-connector-registry.json) for mapping pipeline components Logic Apps workflow generation for pipeline equivalents To convert a receive pipeline: BTPtoLA.exe -pipeline "C:\Pipelines\ReceiveOrderPipeline.btp" -type receive -output "C:\Output\ReceiveOrderPipeline.json" To Convert a send pipeline: BTPtoLA.exe -pipeline "C:\Pipelines\SendInvoicePipeline.btp" -type send -output "C:\Output\SendInvoicePipeline.json" BizTalktoLogicApps.MCP - Model Context Protocol Server The MCP (Model Context Protocol) server provides a standardized interface for AI-assisted migration workflows. This component enables integration with AI tools and assistants to provide intelligent migration suggestions and automation. Key Capabilities: Exposes migration tools through a standardized MCP interface Enables AI-driven migration assistance and recommendations Provides tool handlers for map conversion and other migration operations Facilitates interactive migration workflows with AI assistance Core Components: McpServer.cs: Main MCP server implementation Server/ToolHandlers/MapConversionToolHandler.cs: Handler for map conversion operations test-requests.json: Test request definitions for validating MCP functionality BizTalktoLogicApps.Tests - Test Project A complete test project ensuring the reliability and accuracy of all migration tools, with integration tests that validate end-to-end conversion scenarios. Key Capabilities: Integration tests for BTM to LML conversion across multiple map files Schema validation and error handling tests Batch processing tests for converting multiple artifacts Output verification and quality assurance Where to upload your data: Upload your BizTalk artifacts in the Data directory, and run your tests using the Test explorer. For a complete demonstration, watch the video below:Logic Apps Aviators Newsletter - October 2026
In this issue: Ace Aviator of the Month News from our product group News from our community Ace Aviator of the Month October 2026's Ace Aviator: Hicham Boutaleb & Azure Solution Architect @ 5-Nines Consulting What's your role and title? What are your responsibilities? I work as an Enterprise Integration Architect, helping organizations design, implement, and modernize integration platforms using Microsoft technologies. My responsibilities include defining architecture, leading technical delivery, supporting development teams, ensuring best practices around security and governance, and helping customers get the most value from Azure services such as Logic Apps, API Management, Service Bus, and Azure Functions. Can you give us some insights into your day-to-day activities and what a typical day in your role looks like? No two days are exactly the same, which is one of the things I enjoy most about my role. A typical day usually involves a mix of: - Designing integration and automation solutions. - Reviewing architectures and code with project teams. - Supporting customers in solving complex technical challenges. - Running workshops and knowledge-sharing sessions. - Evaluating new Azure capabilities and how they can benefit ongoing projects. - Collaborating with business stakeholders to translate requirements into scalable technical solutions. I also dedicate time to continuous learning because the cloud ecosystem evolves incredibly fast, and staying up to date is essential. What motivates and inspires you to be an active member of the Aviators/Microsoft community? The community is one of the best accelerators of professional growth. What motivates me most is the opportunity to learn from others while also giving back through sharing experiences, lessons learned, and practical solutions. I believe that technology is not just about tools—it's about people. The Microsoft community creates an environment where professionals can collaborate, innovate, and help each other succeed. Seeing someone solve a problem using knowledge I've shared is incredibly rewarding. Looking back, what advice do you wish you had been given earlier that you'd now share with those looking to get into STEM/technology? I would tell my younger self: Don't focus only on technology, focus on problem-solving and communication. Technical skills are important, but the ability to understand business challenges, communicate clearly, and work effectively with others often has an even greater impact on your career. I would also encourage people to: - Stay curious and never stop learning. - Build real projects rather than only collecting certifications. - Don't be afraid of failure—every mistake is an opportunity to learn. - Invest in your professional network early. The technology will change throughout your career, but adaptability and curiosity will always remain valuable. What has helped you grow professionally? Several factors have contributed to my growth: - Working on diverse and challenging projects. - Learning from experienced mentors and colleagues. - Being willing to step outside my comfort zone. - Participating in technical communities and events. - Maintaining a mindset of continuous improvement. Some of my biggest learning moments came from difficult projects where I had to solve problems I had never encountered before. Those experiences often teach more than success alone. If you had a magic wand that could create a feature in Logic Apps, what would it be and why? If I had a magic wand, I'd add an AI-powered end-to-end message tracking feature in Logic Apps that automatically follows a message across all workflows and Azure services it traverses. It would provide a single, intelligent view of the entire journey, making troubleshooting and root-cause analysis much faster and easier. News from our product group Your Certificate Renewed. Your Gateway Didn't Notice. Learn how certificate renewal can create outages when Azure Application Gateway does not detect an updated certificate in Azure Key Vault. The article explains certificate refresh behavior and practical steps for ensuring renewed certificates propagate reliably to dependent gateway infrastructure. How to Validate That Your BizTalk SB-Messaging Adapter Is Really Using AMQP Prepare BizTalk Server integrations for the retirement of the legacy Service Bus Messaging Protocol by confirming that the SB-Messaging adapter uses AMQP. This guide covers the required BizTalk Server 2020 hotfix and shows how to verify active AMQP-over-TLS connections on port 5671 across every relevant host and messaging configuration. Migrate Data Ingestion from Data Collector to Log Ingestion - Part 2 Continue migrating from the deprecated Data Collector API to the Azure Monitor Log Ingestion API by handling its smaller payload limit. The article demonstrates how to calculate and split large datasets into appropriately sized chunks in Azure Logic Apps so ingestion requests remain below the 1 MB limit. Bring Azure Logic Apps connectors into your .NET applications with the Azure Connectors SDK Explore the preview Azure Connectors SDK for calling Azure Logic Apps connectors directly from .NET applications without hosting a workflow. Strongly typed asynchronous clients, Azure Identity integration, and support for managed identities make it easier to connect application code to Microsoft and third-party services. Agentic Refactoring of Legacy Integration Workloads to Azure Logic Apps Standard See how agentic AI can accelerate the refactoring of legacy integration workloads into Azure Logic Apps Standard. This Microsoft Azure Developers video explores an AI-assisted modernization approach for analyzing existing solutions and moving them toward cloud-native workflows. Connect Azure Functions to SharePoint using Managed Connectors Learn how Azure Functions can connect to SharePoint using managed connectors. This Microsoft Azure Developers video demonstrates how connector capabilities simplify authentication and integration between function code and SharePoint. Connect SaaS & Enterprise Systems with Azure Functions This Microsoft Azure Developers video showcases how Azure Functions can use managed connectors for scalable, event-driven automation. It demonstrates integration with services such as SharePoint and Teams, highlighting how triggers and actions can reduce the need for manual polling and simplify authentication handling. The session walks through building practical workflows that connect SaaS and enterprise systems using Azure Functions. News from our community Logic Apps Community Day — 3 December 2026 Post by Ahmed Bayoumy Logic Apps Community Day returns on 3 December 2026 as a free, online event streamed live on YouTube. The program focuses on Logic Apps, the wider Azure integration stack, and AI patterns built on integration platforms. Organizers describe eight community speaking slots, combining longer sessions with lightning talks, and invite practitioners to submit examples, client cases, comparisons, or AI features. The event is intended for a worldwide audience and includes discussions, a published agenda, and opportunities for community members to share practical experience. Azure Logic Apps: Workflow Automation, Enterprise Integration, Connectors, B2B, Security, Networking, Monitoring, DevSecOps, Governance, and AI-Enable Post by Sanjeeve Kumar Gajadi This extensive guide presents Azure Logic Apps as an enterprise orchestration and integration layer rather than only a visual automation tool. It discusses Consumption and Standard hosting, triggers, actions, connectors, API Management, Service Bus, Event Grid, SAP, B2B protocols, managed identities, private networking, monitoring, reliability, DevOps, governance, and cost management. The article also considers AI-enabled orchestration and human approval patterns. Its central guidance is to design workflows around business processes, resilience, security, observability, and operational ownership while moving complex computation to suitable application services. Azure Logic Apps Handbook: 50 Expert Tips and Best Practices Post by Sandro Pereira Sandro Pereira introduces a free handbook containing 50 expert tips and best practices for Azure Logic Apps. The guide is aimed at architects, developers, integration specialists, DevOps engineers, and leaders working with cloud automation. Its coverage includes Logic Apps capabilities, practical use cases, workflow optimization, security, common pitfalls, and implementation strategies. The accompanying article explains that the handbook is intended to help readers design reliable, scalable, and maintainable workflows, and provides access to the downloadable resource through the linked publication. Build and Debug Logic Apps Standard Locally in VS Code Post by Stephen W. Thomas Stephen W. Thomas demonstrates how to build and debug Azure Logic Apps Standard workflows locally in Visual Studio Code without deploying resources to Azure. The walkthrough covers installing the extension, creating a stateful workflow with built-in operations, using local storage emulation, and sending a request from Postman. It also shows how to pause workflow execution at a breakpoint and inspect the results. The accompanying guide helps developers reproduce the setup and explore a practical local development loop while avoiding Azure charges during development and debugging. Azure API Management Premium v2 Workspaces and Dedicated Workspace Gateways in a Private Network Post by Şahin Özdemir Şahin Özdemir shares lessons from configuring Azure API Management Premium v2 workspaces and dedicated workspace gateways in a fully private network. The article covers Premium v2 virtual network integration, workspace isolation for multiple teams, internal-only workspace gateways, required Bicep resources and associations, and network security group rules. It also calls out deployment pitfalls and the less obvious Microsoft.ApiManagement/gateways/configConnections resource used to associate workspaces with gateways. The first part keeps API Management externally accessible while placing workspaces and their gateways inside the private network. Getting Started with Logic Apps Standard (in 2026) Video by Stephen W. Thomas Stephen W. Thomas shows how to set up Azure Logic Apps Standard locally in Visual Studio Code in under five minutes with no Azure charges. The updated installation brings in the Azure Functions runtime, Azure tooling, C# support, and storage emulators. The video creates a local workspace using built-in connectors, starts the workflow with F5, copies its callable URL, and sends a request from Postman. It also demonstrates breakpoints, debugger variables, action inputs, and stepping into custom in-process C# code for a complete local development experience.How to Validate That Your BizTalk SB-Messaging Adapter Is Really Using AMQP
On September 30, 2026, Azure Service Bus stops accepting the Service Bus Messaging Protocol (SBMP) — the protocol the BizTalk SB-Messaging adapter has always used. The failure mode is not a warning in a log file; it is a refused connection. To keep those integrations running, a BizTalk Server 2020 hotfix adds a new Azure.Messaging.ServiceBus AMQP implementation to the adapter in place of the legacy SBMP path. This post walks through how to validate the hotfix was successfully deployed and is using AMQP and not SBMP. Required baseline: BizTalk Server 2020 with Cumulative Update 6 or Cumulative Update 7 installed, plus the SB-Messaging AMQP hotfix — KB5091379, obtained by opening a Microsoft support case. The hotfix is not offered through Windows Update or the regular CU download, and it will not install on a CU5 or earlier baseline. Every node in the BizTalk group needs it. A multi-server group will happily run the affected host instance on an unpatched node, and your test may land on the one server where the fix is not active. Patch and restart host instances everywhere, then record the edition, CU level, hotfix number, and component build per server. Hotfix location: https://1drv.ms/f/c/cac4b5f5988b8228/IgCrzn_KTaZ8T5tuKmcdPgXxARuOLcGHDhxVLgeysj44GWE?e=w5AcpM Once the baseline is confirmed, test in a non-production environment that reproduces production topology, authentication, and the full network path — proxy, firewall, private endpoint, and DNS. And list every materially different configuration you intend to validate: each send port and receive location, queue, topic, and subscription usage, 32-bit versus 64-bit hosts, and features such as sessions, ordered delivery, or transactions. A green result on one port does not validate the others. Method 1: Verify the active connection on port 5671 (recommended) The adapter selects AMQP over TCP, and Azure Service Bus uses TCP port 5671 for AMQP over TLS. Correlating an established 5671 connection with the correct BTSNTSvc or BTSNTSvc64 process demonstrates that the BizTalk host is using the AMQP transport. Run elevated PowerShell while the receive location is enabled and actively polling: $hostProcesses = Get-Process BTSNTSvc, BTSNTSvc64 -ErrorAction SilentlyContinue Get-NetTCPConnection -State Established -RemotePort 5671 | Where-Object OwningProcess -in $hostProcesses.Id | ForEach-Object { $process = Get-Process -Id $_.OwningProcess [pscustomobject]@{ Process = $process.ProcessName ProcessId = $_.OwningProcess LocalAddress = $_.LocalAddress LocalPort = $_.LocalPort RemoteAddress = $_.RemoteAddress RemotePort = $_.RemotePort State = $_.State } } Expected result: Process is BTSNTSvc or BTSNTSvc64. Remote port is 5671. State is Established. The remote address resolves to or corresponds to the Service Bus namespace. What an empty result means: not much, on its own. An empty result is inconclusive, not a failure. Confirm the port or receive location is enabled, the host instance is running, traffic is actually flowing during the check, and that DNS, firewall, or private endpoint rules permit the connection — then repeat. One important exception: if your environment routes AMQP over WebSockets on TCP 443, you should not expect a 5671 connection at all. In that case skip to Method 2. Method 2: Capture adapter traces When the connection view is unavailable or ambiguous, the trace is the more definitive answer, because it shows which code path executed rather than which socket happened to be open. BizTalk adapter tracing uses ETW through BT.Trace.Tracer, and entries containing [SBMessaging-AMQP] confirm that the new AMQP-specific implementation executed. Start BizTalk adapter tracing immediately before the test — not hours earlier. Send or receive a single, uniquely identifiable test message through the target port or receive location. Stop tracing as soon as the message completes. Search the captured output for [SBMessaging-AMQP] entries inside the test window, and match them to the host instance and configuration you were exercising. Method 3: Block the legacy SBMP ports Methods 3 and 4 are corroborating tests, not proof, and belong in an isolated environment. Legacy SBMP commonly uses TCP ports 9350 through 9354. If the isolated AMQP workload continues to operate while those ports are blocked and TCP 5671 remains available, the result corroborates that the workload does not depend on SBMP. Record the original firewall rules before you start and restore them immediately afterwards — this test has a real blast radius if it escapes the test subnet. Method 4: Large message functional test In Basic and Standard tiers, the maximum message size is 256 KB, regardless of SDK or protocol, so this test does not apply there. In Premium, the legacy SBMP path supports messages only up to 1 MB, whereas AMQP supports larger messages up to the entity’s configured maximum of 100 MB. Successfully processing a Premium message larger than 1 MB therefore provides supplementary evidence that the adapter is using AMQP. Read a failure carefully: entity limits, timeouts, and pipeline constraints all produce the same symptom, so a failed large-message test is not by itself evidence that the hotfix did not take. Verify payload integrity and the event log, then remove the test message and restore any temporary entity settings. Do not stop at the protocol Confirming that AMQP is in use answers the transport question. It does not answer whether your solution still behaves the same way. AMQP and SBMP differ in a handful of behavioural details, so before you call the validation complete, run the scenarios your integrations depend on and compare against a pre-change baseline: Send and receive across each representative queue, topic, and subscription path, checking message body and application-property fidelity. Peek-lock completion, abandon, defer, dead-letter, and retry behaviour, plus sessions, ordering, transactions, and duplicate detection where you use them. Authentication renewal, and recovery after a host instance restart or a brief network interruption. Throughput and latency within your accepted baseline, with no new event log errors, suspended instances, duplicates, or lost messages.Service Bus SBMP Retirement: What BizTalk Server 2020 Customers Need to Know
On September 30, 2026, the Azure Service Bus team will retire support for the Service Bus Messaging Protocol (SBMP). This is important BizTalk Server 2020 customers who use the BizTalk Service Bus (SB-Messaging) adapter, as SBMP is the protocol that adapter relies on today. To help customers maintain continuity while planning their transition to Azure Logic Apps, we’ve released a BizTalk Server 2020 hotfix that adds support for Advanced Message Queuing Protocol (AMQP) in the adapter. What’s changing SBMP support retires on September 30, 2026 in Azure Service Bus. A hotfix enables AMQP for the BizTalk Service Bus (SB-Messaging) adapter (request KB5091379 opening a support case). AMQP becomes the default transport with the hotfix installed. The hotfix is available for BizTalk Server 2020 CU6 and CU7. What you need to do If you plan to continue using the BizTalk Server 2020 Service Bus adapter, you should: Migrate your adapter configuration to AMQP. Install the hotfix well before September 2026, and run validation in a non-production environment. Validate your scenarios, including large message/file patterns and any operational fallback strategies you depend on. How to obtain the hotfix You can obtain the hotfix by opening a support case (request KB5091379) or using the download below. The hotfix enables AMQP support for the BizTalk Service Bus (SB-Messaging) adapter How to test the hotfix works Follow the steps here: How to Validate That Your BizTalk SB-Messaging Adapter Is Really Using AMQP | Microsoft Community Hub Support and lifecycle context Microsoft remains committed to supporting BizTalk Server 2020 and its features in accordance with the official product lifecycle. Extended paid support will be available after April 2028. Closing thoughts If you’re using the SB-Messaging adapter today, now is the right time to plan your move to AMQP and schedule validation in a non-production environment. This keeps you ahead of the September 2026 retirement date and helps ensure a smooth path as you modernize toward Azure Logic Apps. Temporary Download Location: https://1drv.ms/f/c/cac4b5f5988b8228/IgCrzn_KTaZ8T5tuKmcdPgXxARuOLcGHDhxVLgeysj44GWE?e=w5AcpMLogic Apps Aviators Newsletter - September 2026
In this issue: Ace Aviator of the Month News from our product group News from our community Ace Aviator of the Month September 2026's Ace Aviator: Parth Talaviya What's your role and title? What are your responsibilities? AI-Powered Azure/.NET Solution Architect I work as an Azure/.NET Solution Architect, combining technical leadership with building a Microsoft-focused boutique company. My work mainly revolves around application modernization and migration, cloud architecture, integrations, and team leadership. I also stay hands-on with development, architecture reviews, production troubleshooting, and mentoring developers. Can you give us some insights into your day-to-day activities and what a typical day in your role looks like? My day usually starts with thinking about how we can add more value to our clients' businesses. It includes reviewing project priorities, solving technical challenges, discussing architecture, supporting developers, and collaborating with stakeholders. I mainly work across .NET, Azure, APIs, integrations, DevOps, and AI automation, so every day brings something new to learn and solve. What motivates and inspires you to be an active member of the Aviators/Microsoft community? What really motivates me is how active and supportive the Microsoft community is. People are genuinely willing to help each other, share experiences, and solve problems together. Being able to use my own experience to help someone overcome a challenge genuinely makes my day, while learning from others keeps me motivated to continuously improve. Looking back, what advice do you wish you had been given earlier that you'd now share with those looking to get into STEM/technology? You don’t have to do everything alone. In technology, especially when you are stuck on a very specific problem, it can sometimes feel that way. Asking questions, learning from the community, and collaborating with others can make a huge difference. I would also say: embrace AI early, but use it wisely. Don’t use AI only to generate code. Use it to understand concepts, challenge your thinking, explore better approaches, review your work, and become a better problem-solver. What has helped you grow professionally? Continuous learning and solving real-world challenges have helped me grow the most. Working on legacy modernization, cloud architecture, large-scale data systems, automation, and AI has taught me to think beyond writing code and understand the broader business impact. Being part of a strong technical community has also helped significantly. Whenever you are stuck, there is often someone who has faced a similar challenge and is willing to share their experience. If you had a magic wand that could create a feature in Logic Apps, what would it be and why? I would create an AI-powered Copilot troubleshooting and self-healing assistant for Logic Apps. It could analyze failed workflows, understand the execution context, identify the likely root cause, suggest a fix, and provide safe recovery options. For complex integrations, this could save significant troubleshooting time and allow developers to focus more on building solutions rather than spending hours finding where something went wrong. News from our product group Use connectors with Managed Identity in the Logic Apps Standard extension Managed Identity is Azure's built-in way to authenticate to Microsoft Entra-protected resources without storing credentials, secrets, or connection strings. Deployed Logic Apps have supported it for some time, and this post explains connector support in the Logic Apps Standard extension. Introducing dependency telemetry in Application Insights for Azure API Management policies Running API platforms at scale requires both handling load and understanding where inefficiencies occur. This post introduces dependency telemetry in Application Insights for Azure API Management policies to help teams identify performance bottlenecks. Power Azure SRE Agent with the tools it needs Azure SRE Agent is an AI-powered service designed to reduce operational toil. Teams can use it to investigate incidents, identify probable causes, and automate health-related operational work using connected tools. Give your Copilot agents real tools, without hand-wiring MCP GitHub Copilot coding agents can work independently on branches, but some tasks require access to external systems. This post shows how to equip agents with real tools without manually wiring Model Context Protocol integrations. Zonal redundancy in API management Standard v2 APIs power modern mobile experiences, microservices, AI-driven applications, and business-critical integrations. This post explains zonal redundancy in Azure API Management Standard v2 for improving resilience as customers modernize their API platforms. BizTalk Server 2020 End-of-Sale Announcement Microsoft announces that BizTalk Server 2020 and Host Integration Server 2020 sales are expected to end on March 31, 2027. Existing licensed deployments can continue to be used, while mainstream support for BizTalk Server 2020 is scheduled through April 12, 2028. An optional paid extended-mainstream support offering is planned for eligible customers through April 10, 2030, with final terms to be published later. The post recommends beginning migration planning now, evaluating Azure Logic Apps Standard or Azure Logic Apps Hybrid, inventorying dependencies, and using the Logic Apps Migration Agent to assess and convert supported workloads. Logic App Storage Inspector Logic App Storage Inspector is a read-only Kudu site extension for examining storage used by an Azure Logic App Standard application. It supports searching workflow action and trigger history by workflow, date, or text, with results exportable as CSV or JSON. Users can browse and compare workflow-definition versions, review table and queue information, and monitor health indicators and refresh status. The extension isolates access to the current Logic App site, uses asynchronous paged operations for large storage accounts, and can be installed from Kudu Site Extensions. News from our community Azure Logic Apps Automation – A Practical Infrastructure Lab with Agentic Remediation Post by João Paulo Costa João Paulo Costa tests Azure Logic Apps Automation through an after-hours virtual-machine remediation lab. The workflow uses an agent to inspect VM metadata, tags, and runtime state, then apply guardrails before deciding whether to deallocate the resource, leave it unchanged, or request review. The article contrasts agentic decision-making with deterministic workflows, documents tool and connector choices, and examines preview limitations such as runtime-state retrieval and managed-identity support. It also emphasizes constrained permissions, explicit policies, verification after actions, and negative testing for production, exemptions, missing ownership, and disabled remediation. Agentic Integration: Non-Deterministic Experience, Solid Core Post by Massimo Crippa Massimo Crippa examines whether agentic capabilities make enterprise integration non-deterministic. He separates an agent’s variable decision-making from the predictable integration layer that executes selected capabilities. The article highlights durable messaging, reliable contracts, idempotency, transactional boundaries, retries, compensation, governance, and observability as continuing requirements. It presents tools as the boundary between reasoning and execution: agents determine what should happen, while integration platforms control how operations are performed safely. Azure Logic Apps is positioned as both a deterministic integration foundation and a platform that can expose governed capabilities to emerging agentic experiences. Build AI Agents in Azure Logic Apps (Conversational + Autonomous) Video by Rafsan Huseynov Rafsan Huseynov presents a video on building conversational and autonomous AI agents with Azure Logic Apps. The session describes Logic Apps as more than a background integration layer, covering orchestration, managed identities, agent loops, and the use of workflows as MCP tools. Demonstrations explore connections with Document Intelligence, Blob Storage, Microsoft Foundry, and Copilot Studio workflows, alongside conversational and autonomous agent patterns. The video also introduces a separate low-code automation experience with scoped permissions, while noting that the demonstrations use synthetic data and that the experience remains in preview. BizTalk to Logic Apps migration (three things, everyone gets wrong) Post by Brajesh Sinha Brajesh Sinha explains why simple counts of BizTalk orchestrations and maps produce unreliable Logic Apps migration estimates. One orchestration can fan out into several Azure resources, supposedly simple maps may hide substantial transformation complexity, and operational requirements are often omitted from statements of work. The article highlights the architecture, mapping, and production-readiness effort that teams frequently underestimate. It encourages migration planners to assess actual behavior and dependencies rather than relying on inventory totals, helping create more realistic timelines, scope, and delivery expectations. Hybrid Logic Apps on RKE2: a self-managed cluster with MetalLB Post by Sonny Gillissen Sonny Gillissen demonstrates how to run Azure Logic Apps Hybrid on a self-managed RKE2 Kubernetes cluster. Because RKE2 does not include a native load balancer, the walkthrough uses MetalLB to assign the ingress IP required by the deployment. It covers creating the cluster, configuring networking, connecting the environment to Azure Arc, and handling the platform-specific details needed for Logic Apps. The article provides a practical alternative for teams evaluating hybrid integration workloads outside managed Kubernetes services, extending earlier guidance for OpenShift environments. An Introduction to Logic Apps Standard SDK Video by Marcel Medina Marcel Medina shares a Coding Night ANZ recording introducing the Logic Apps Standard SDK. The session shows how the SDK brings a modern, code-first .NET development experience to Azure Logic Apps while retaining the platform’s connectors, triggers, monitoring, and managed runtime. It is aimed at developers who want familiar tooling and stronger source-driven workflow development without giving up managed integration capabilities. The post also thanks the community for its questions and participation and provides the complete session recording for anyone who missed the live event. Managed Identity in Logic Apps Standard: A Zero Trust Read Post by Steef-Jan Wiggers Steef-Jan Wiggers examines new Managed Identity support for connectors in the Logic Apps Standard local development experience. Developers can now use a consistent authentication model from development through production instead of swapping connection strings before deployment, removing a common source of unmanaged secrets. The article frames this improvement through Zero Trust while stressing that authentication alone does not replace disciplined RBAC. A working azd sample demonstrates the setup and highlights a critical application setting whose absence causes the otherwise correctly configured connection, access policy, and role assignment to fail.BizTalk Server 2020 End-of-Sale Announcement
Executive Summary: BizTalk Server 2020 is the final release of BizTalk Server, and Microsoft expects sales of BizTalk Server 2020 and Host Integration Server 2020 to end March 31, 2027. Mainstream support for BizTalk Server 2020 continues through April 12, 2028, after which the product remains subject to Microsoft’s Fixed Lifecycle Policy. Microsoft also plans to offer eligible customers an optional, paid extended-mainstream support offering through April 10, 2030. Customers should begin planning their migration to Azure Logic Apps Standard or Azure Logic Apps Hybrid now, based on their deployment requirements. Closing a chapter Microsoft currently expects sales of BizTalk Server 2020 and Host Integration Server 2020 to end on March 31, 2027. Customers with existing valid licenses may continue to deploy and use the software in accordance with their licensing terms. Mainstream support for BizTalk Server 2020 continues through April 12, 2028. The end-of-sale date does not require customers to stop running licensed deployments, but customers should begin migration and licensing planning now because the extended-mainstream support offering described below remains subject to final eligibility, coverage, pricing, and purchasing terms. Microsoft plans to offer eligible BizTalk Server 2020 customers a paid, time-limited extended-mainstream support option from April 13, 2028, through April 10, 2030. The offering is intended to provide additional migration time, will have narrower coverage than the original mainstream-support phase, and will not add new product features. Eligibility, availability, supported components, servicing commitments, purchasing terms, and the official offering name will be published before enrollment opens. If you need to buy BizTalk Server 2020, or Host Integration Server 2020, you can do it until March 31, 2027. Recommended action Begin migrating your BizTalk Server workloads now, selecting Azure Logic Apps Standard or Azure Logic Apps Hybrid according to your organization’s hosting, networking, latency, data-residency, and operational requirements. Treat additional support coverage as contingency time rather than the default destination. Starting early gives teams time to inventory dependencies, redesign excluded capabilities, validate migrated solutions, and make commercial decisions before mainstream support ends. The Logic Apps Migration Agent can accelerate assessment and planning, convert supported artifacts, and assist with validation and deployment of refactored solutions on Azure Logic Apps Standard or Azure Logic Apps Hybrid. Extended-mainstream support scope Paid extended-mainstream support is planned as an optional, temporary bridge for eligible customers completing their migration. It is separate from the Extended Support phase available under Microsoft’s Fixed Lifecycle Policy and is expected to provide a different, narrower scope than the original mainstream-support phase. Microsoft expects the paid offering to run from April 13, 2028, through April 10, 2030. Certain BizTalk Server capabilities are expected to be excluded from the paid offering; the following list identifies the currently expected exclusions. Business Activity Monitoring (BAM) — The framework and tooling for capturing, tracking, and presenting near real-time business milestones, KPIs, and operational data from running BizTalk processes. Servicing, fixes, and updates for BAM components will not be provided under extended support. Enterprise Service Bus Toolkit (ESB Toolkit) — The libraries, itinerary services, and patterns that extend BizTalk with dynamic, itinerary-based routing, transformation, and centralized exception handling for service-oriented solutions. The ESB Toolkit will not receive servicing or support under extended support. Industry accelerators (SWIFT, HL7, and RosettaNet) — The domain-specific accelerators that provide schemas, pipelines, and validation for financial (SWIFT), healthcare (HL7), and supply-chain (RosettaNet) messaging standards. These accelerators will not receive servicing, schema updates, or support under extended support. Legacy enterprise adapters — The adapters that connect BizTalk to line-of-business and enterprise applications such as Siebel, PeopleSoft, TIBCO, and JD Edwards. These adapters will not receive servicing or support under extended support. Application Lifecycle Management (ALM) tooling and integrations — The BizTalk-specific tooling and integrations used for source control, automated build, deployment, and testing of BizTalk applications. These BizTalk-specific ALM components will not receive servicing or support under extended support. BizTalk Server images in Azure Marketplace — Microsoft currently expects to deprecate the BizTalk Server virtual-machine offer in Azure Marketplace. This affects the future availability of the Marketplace deployment image; it does not, by itself, make an otherwise eligible existing BizTalk Server 2020 deployment ineligible for paid extended-mainstream support. Microsoft will publish the effective date and guidance for existing virtual machines, new or replacement deployments, scaling, disaster recovery, customer-managed images, licensing, billing, patching, and support. New Visual Studio version support — Compatibility with Visual Studio versions newer than Visual Studio 2022 will not be added under extended support. Customers should review the Visual Studio 2022 lifecycle and support offering separately, because its coverage terms are independent of BizTalk Server extended support. Customers that depend on an excluded capability should prioritize the affected workloads in their migration plan. Use the Logic Apps Migration Agent to assess dependencies, inform target-architecture decisions, convert supported artifacts, and validate the migrated solution. Excluded BizTalk capabilities may require architectural redesign or manual implementation outside the agent. Customers are not required to purchase paid extended-mainstream support. Customers that do not enroll remain subject to Microsoft’s Fixed Lifecycle Policy and the applicable BizTalk Server 2020 lifecycle dates. The availability of technical support, non-security updates, security updates, and other services during the standard Extended Support phase depends on the policy requirements and the customer’s applicable support arrangement. The paid extended-mainstream support offering described here is an optional, separate offering for eligible customers that require additional coverage while completing their migration. After the end-of-sale date, customers that already hold valid BizTalk Server 2020 licenses may continue to deploy and use the software in accordance with the applicable licensing terms. Eligibility Paid extended mainstream support will be available to eligible customers with properly licensed BizTalk Server 2020 deployments. The final eligibility requirements will be provided in the published offering terms. Eligible products and versions: Paid extended-mainstream support is expected to be available for eligible deployments of BizTalk Server 2020 Enterprise, Standard, or Branch editions. Customers using Host Integration Server 2020 may also purchase the BizTalk Server paid extended-mainstream support offering to receive the applicable extended mainstream-support coverage for their HIS 2020 deployments, including customers that acquired BizTalk Server licences primarily to obtain HIS usage rights. BizTalk Server 2016, HIS 2016, and earlier versions will not be eligible. Azure Marketplace deployments: Existing BizTalk Server 2020 deployments created from eligible Azure Marketplace images are expected to qualify for paid extended-mainstream support, subject to the final offering terms. Customers must meet the applicable licensing, Software Assurance, supported-configuration, and complete-deployment coverage requirements. Microsoft will clarify how eligibility, licensed-core quantities, pricing, and purchasing apply when BizTalk Server software charges are included in the Azure Marketplace virtual-machine rate rather than acquired through a separate BizTalk Server licence agreement. Valid licenses: Customers are expected to maintain sufficient BizTalk Server licenses for each covered deployment in accordance with the applicable licensing model, including relevant core minimums, licensing of physical or virtual environments, and license-reassignment rules. Final extended-support licensing requirements will be stated in the published offering terms. Software Assurance: Active Software Assurance will be required at enrollment and throughout the applicable coverage period. Complete deployment coverage: Extended mainstream support must be purchased for all licensed cores in each enrolled deployment. Partial coverage of an enrolled production environment will not be permitted. Supported configuration: Covered environments must remain on a supported BizTalk Server 2020 configuration and meet published requirements for cumulative updates, operating systems, databases, and dependent components. Annual validation: Eligibility and licensed-core quantities will be confirmed for each coverage year. Customers must remain eligible to purchase Year 2 coverage. As part of the eligibility review, Microsoft may request licensing records, deployment inventories, configuration details, and migration-plan information. Complete requirements and enrollment instructions will be published before the offering becomes available. Purchasing details Paid extended mainstream support will be offered as annual coverage based on the licensed cores in each enrolled BizTalk Server 2020 deployment. Microsoft will publish final pricing, availability, enrollment dates, purchasing channels, and transaction terms before sales begin. Purchasing paid extended-mainstream support is optional and is not required for BizTalk Server 2020 to follow the Fixed Lifecycle Policy. Host Integration Server 2020: Eligible HIS 2020 customers will purchase coverage through the BizTalk Server paid extended-mainstream support offering. Customers that do not require HIS IBM Systems Network Architecture (SNA) capabilities should also evaluate Azure Logic Apps Standard or Azure Logic Apps Hybrid as a modernization alternative before purchasing additional support coverage. Azure Logic Apps Standard does not support SNA; customers that depend on HIS 2020 SNA capabilities must transition to Host Integration Server 2028. Coverage periods: Year 1 is expected to begin the next day mainstream support ends, on April 13, 2028, and continue through April 13, 2029. Year 2 is expected to run from April 14, 2029, through April 10, 2030. The final offering terms will confirm whether the boundary dates are inclusive and will specify the exact enrollment and coverage periods. Purchase sequence: Microsoft expects customers to purchase Year 1 coverage by April 11, 2028, to remain eligible to purchase Year 2 coverage. The final enrollment deadline and Year 2 eligibility conditions will be specified in the published offering terms. Price: Microsoft expects annual extended-mainstream support pricing to be 100% of the applicable BizTalk Server license cost under the customer's licensing agreement. Extended mainstream support is expected to be offered as an annual add-on for eligible BizTalk Server licenses. Final pricing and costs may vary by licensing agreement, geography, currency, available discounts, and the published offering terms. How to purchase: Customers will purchase coverage through an authorized Microsoft commercial licensing channel with support from their Microsoft account team or licensing partner. Separate support services: The annual extended-mainstream support fee is expected to cover only the servicing and support rights defined in the final offering terms. It will not include unlimited incident support, advisory services, migration delivery, solution implementation, or other professional services; customers may need a separate support plan or services agreement for those needs. Annual purchase: Coverage will not renew automatically. Customers must place a separate order and complete an eligibility review for each year. Support beyond April 10, 2030, is not planned. Contact your Microsoft account team or licensing partner to review eligible deployments, confirm licensed-core quantities, and obtain a quote when the offering becomes available. Discounts and incentives Microsoft plans to offer a targeted incentive for eligible existing BizTalk Server customers that are actively migrating to Azure Logic Apps Standard or Azure Logic Apps Hybrid. The incentive is designed to reduce near-term migration costs and support a faster move to the selected Logic Apps deployment model. It will not be automatic or broadly available; eligibility, approval, and final commercial terms must be confirmed by the customer’s Microsoft account team. Timing and important conditions Who can qualify: The incentive is intended exclusively for existing BizTalk Server 2020 customers approaching the announced BizTalk Server lifecycle milestones and actively migrating workloads to Azure Logic Apps Standard or Azure Logic Apps Hybrid. Redemption period: The incentive is expected to become available on August 31, 2026, and remain available through April 12, 2028, subject to publication of the program terms, eligibility approval, continued availability, and any applicable funding limits. Discount duration: The approved discount is expected to apply during the customer’s first qualifying Enterprise Agreement term after approval. The published program terms will define the eligible agreement types, qualifying start date, covered Azure services, discount duration, and treatment of renewals or agreement changes. Qualification: The incentive is subject to eligibility review and approval. Recommended action Ask your Microsoft account team or licensing partner to assess your migration scope, confirm which eligible migration path applies, and request consideration for the incentive. Migration support Contact your Microsoft account team to determine whether your organization is eligible for migration assistance delivered by the Azure Logic Apps product group or through another available migration-factory program. Program names, eligibility criteria, engagement scope, and availability will be confirmed through your account team. Migration options for Host Integration Server workloads Customers using Host Integration Server 2020 for application, data, messaging, or terminal integration—and who do not depend on HIS SNA capabilities—should evaluate Azure Logic Apps Standard or Azure Logic Apps Hybrid as a modernization target. Azure Logic Apps provides mainframe and midrange integration capabilities for scenarios involving IBM CICS, IMS, IBM i programs, DB2, IBM MQ, host files, and 3270 applications. Customers should assess each workload against the available connectors, supported protocols, networking, security, and operational requirements. Azure Logic Apps Standard does not support SNA. Customers running HIS 2020 workloads that depend on SNA capabilities must plan to transition to Host Integration Server 2028. Key dates March 31, 2027: Sales of BizTalk Server 2020 and Host Integration Server 2020 are expected to end. April 12, 2028: Mainstream support for BizTalk Server 2020 ends. April 13, 2028: BizTalk Server 2020 enters the Extended Support phase under Microsoft’s Fixed Lifecycle Policy, subject to the applicable policy requirements and lifecycle dates. April 13, 2028–April 10, 2030: Planned paid extended-mainstream support period for eligible BizTalk Server 2020 customers, subject to the final published offering terms. September 30, 2027: Host Integration Server 2028 is planned for release as a standalone product. Release timing is subject to change. July 7, 2030: Extended Support for Host Integration Server 2020 is currently scheduled to end. This date is separate from the planned BizTalk Server 2020 paid extended mainstream support period, which is expected to end April 10, 2030. Start your modernization journey with the Logic Apps Migration Agent. Use the agent to inventory and assess your BizTalk applications, prioritize integrations, build a phased migration plan, convert supported artifacts and workflows, and support validation, testing, and deployment to Azure Logic Apps Standard or Azure Logic Apps Hybrid. Excluded or unsupported BizTalk capabilities may require architectural redesign or manual implementation outside the agent. The agent’s AI-assisted, human-in-the-loop approach can accelerate modernization while your teams retain control of architecture and implementation decisions. Contact your Microsoft account team to discuss migration-assistance eligibility and commercial options. Learn more: BizTalk Server product lifecycle update | Bringing all your integration workloads to Logic Apps Standard | Fixed Lifecycle Policy – Extended SupportMicrosoft 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 Migration Agent (Complete refactoring from BizTalk to Logic Apps): Bringing all your Integration workloads to Logic Apps Standard | Microsoft Community Hub 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 is the end of sale date for BizTalk Server? We will announce an end of sale date for BizTalk Server on July 2026. 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 Corporation
Announcing Flat File Schema Generation support in Azure Logic Apps Standard
We’re excited to announce the preview of Flat File Schema Generation for Azure Logic Apps Standard. This new built-in action helps integration teams move faster by generating BizTalk compatible flat-file XSD schemas directly from sample flat-file payloads, reducing the manual effort required to model CSV, delimited, and positional files before encoding or decoding them in workflows. Why this matters Flat files continue to power enterprise mission critical integrations, from partner feeds and batch exports to finance ledgers, operational reports, and legacy system exchanges. While Azure Logic Apps already helps teams encode and decode flat files, creating the required flat-file schema has often been a separate design-time step. With Flat File Schema Generation, you can now accelerate that onboarding experience by generating a starter schema from real sample data within the workflow itself. What’s new The new Flat File Schema Generation action generates a flat-file XSD schema from sample content that you pass into the action. The generated schema includes BizTalk-compatible flat-file annotations, making it suitable for downstream Flat File Encoding and Flat File Decoding actions in Azure Logic Apps Standard workflows. Runtime schema generation: Generate schemas directly from sample flat-file payloads in the workflow. Delimited and positional support: Create schemas for common CSV, semicolon-delimited, tab-delimited, and fixed-width files. BizTalk-compatible annotations: Use generated schemas with the existing flat-file processing model familiar to BizTalk and enterprise integration teams. Flexible naming: Configure root element names, namespaces, record names, delimiters, and field positions to match your integration needs. How it works You provide a representative sample payload, specify whether the file structure is delimited or positional, and configure the relevant parsing details such as field delimiters, record delimiters, header handling, or fixed-width field positions. Once you run the workflow, the action returns the generated XSD schema as XML output, which can then be passed into subsequent flat-file operations or stored as part of your onboarding flow. Get started To try the preview, add the Flat File Schema Generation action to a Logic Apps Standard workflow, provide a sample flat-file payload, choose the record structure, and configure the field or record settings that match your format. Use the generated schema output with Flat File Decoding or Encoding in the same workflow or incorporate it into your broader onboarding process for flat-file integrations. Reference document: Encode, Decode, or Generate Schemas for Flat Files - Azure Logic Apps | Microsoft Learn. A walkthrough of generating a flat-file schema from sample data Use the following walkthrough to try the preview end to end with a simple customer order file. The same pattern can be adapted for semicolon-delimited, tab-delimited, or fixed-width positional files. Delimited sample: For this example, assume a trading partner sends a comma-separated order file with a header row and repeating order records. Sample file: OrderId,CustomerName,OrderDate,Amount,Region 10001,Contoso Retail,2026-07-01,1250.75,North 10002,Fabrikam Foods,2026-07-02,890.00,West 10003,Northwind Traders,2026-07-03,2400.50,South Configuration values Parameter Example value Record Structure Delimited Has header Yes Record delimiter newline Field delimiter , Field delimiter order Infix Escape character Double quote, if the source file uses quoted values Root element name (Advanced Parameters) Orders Record name (Advanced Parameters) Order Target namespace (Advanced Parameters) http://schemas.contoso.com/orders In the Azure portal, open your Logic Apps Standard resource and select the workflow where you want to generate the schema. Add a trigger, such as When an HTTP request is received, or use any trigger/action that provides the sample flat-file content. Add a new action and search for Flat File. Select the Flat File Schema Generation action. In the action, provide the sample flat-file content. Select the file structure type. For this example, choose Delimited. Enter the schema metadata under advanced parameters, such as the root element name, record name, and target namespace. Configure the delimiter settings, including the field delimiter and record delimiter. If the first row contains column names, enable the option to use the first row as headers. Save and run the workflow. Open the workflow run history and review the action output. The action returns a generated XSD schema with flat-file annotations. Review the generated schema, validate field names and inferred data types, and use the schema with Flat File Decoding or Flat File Encoding in your workflow. Positional sample: Fixed-width customer order file Use this example when the source flat file doesn’t use delimiters. In a positional, or fixed-width, file each field starts and ends at a known character position. The schema generation action needs those field positions so it can split each record correctly. Sample positional file: 10001CONTOSO00120260701000125075NORTH 10002FABRIKAM0120260702000089000WEST· 10003NORTHWIND120260703000240050SOUTH Note: The dot symbol in the second record represents a trailing space used for fixed-width padding. Replace it with an actual space in your real sample payload. Field position map Field Start position Length Justification Example value OrderId 1 5 Right 10001 CustomerCode 6 10 Left CONTOSO001 OrderDate 16 8 Right 20260701 Amount 24 9 Right 000125075 Region 33 5 Left NORTH Configuration values for the positional sample Parameter Example value Record Structure Positional Has Header No Record delimiter newline Field positions Use the field names, lengths, and justification values from the field position map. Root element name (Advanced Parameters) Orders Record name (Advanced Parameters) Order Target namespace (Advanced Parameters) http://schemas.contoso.com/orders/positional Step-by-step walkthrough for positional files In the Azure portal, open your Logic Apps Standard resource and select the workflow where you want to generate the schema. Add a trigger, such as When an HTTP request is received, or use an existing action that provides the fixed-width file content. Add a new action and search for Flat File. Select the Flat File Schema Generation action. Paste the positional sample payload into the sample content input. Make sure every record has the same total length. For the structure type, choose Positional. Enter the schema metadata, including root element name, record name, and target namespace. Configure the record delimiter. For this example, use newline. Add the field positions in order: OrderId length 5, CustomerCode length 10, OrderDate length 8, Amount length 9, and Region length 5. Set justification for each field. Use Right for numeric or date-like fields and Left for text fields that may contain trailing space padding. Save and run the workflow. Open the workflow run history and review the generated XSD schema output. Confirm that the field names, order, lengths, and positional annotations match the source record layout. Use the generated schema with Flat File Decoding to parse incoming fixed-width files into XML, or with Flat File Encoding to generate outbound fixed-width files. Limitations and known issues Limitation Description Type inference uses a single record. The first non-empty data record determines column types. Single record type only The action generates one repeating record structure and doesn't support heterogeneous record layouts. No nested or hierarchical records The generated schema is flat, meaning you have a root element with one repeating child record and fields. Positional boundaries aren't automatically detected. You must provide exact field lengths in field Positions. UTF-8 code page only Generated schema sets codepage="65001" and doesn't expose encoding selection. Escape-character behavior is literal. Escape handling matches literal value and skips only the next single character. recordName default If unspecified, defaults to {RootElementName}_Record. Designer justification input fieldPositions[].justification supports only Left and Right. Looking ahead This preview is another step toward making Azure Logic Apps Standard, a more complete and productive platform for enterprise integration modernization. Whether you are onboarding new partner feeds, modernizing BizTalk-style flat-file processing, or automating recurring operational files, Flat File Schema Generation helps reduce setup friction and get integration workflows moving faster.
