Microsoft BizTalk Server Product Lifecycle Update
For more than 25 years, Microsoft BizTalk Server has supported mission-critical integration workloads for organizations around the world. From business process automation and B2B messaging to connectivity across industries such as financial services, healthcare, manufacturing, and government, BizTalk Server has played a foundational role in enterprise integration strategies. To help customers plan confidently for the future, Microsoft is sharing an update to the BizTalk Server product lifecycle and long-term support timelines. BizTalk Server 2020 will be the final version of BizTalk Server. Guidance to support long-term planning for mission-critical workloads This announcement does not change existing support commitments. Customers can continue to rely on BizTalk Server for many years ahead, with a clear and predictable runway to plan modernization at a pace that aligns with their business and regulatory needs. Lifecycle Phase End Date What’s Included Mainstream Support April 11, 2028 Security + non-security updates and Customer Service & Support (CSS) support Extended Support April 9, 2030 CSS support, Security updates, and paid support for fixes (*) End of Support April 10, 2030 No further updates or support (*) Paid Extended Support will be available for BizTalk Server 2020 between April 2028 and April 2030 for customers requiring hotfixes for non-security updates. CSS will continue providing their typical support. BizTalk Server 2016 is already out of mainstream support, and we recommend those customers evaluate a direct modernization path to Azure Logic Apps. Continued Commitment to Enterprise Integration Microsoft remains fully committed to supporting mission-critical integration, including hybrid connectivity, future-ready orchestration, and B2B/EDI modernization. Azure Logic Apps, part of Azure Integration Services — which includes API Management, Service Bus, and Event Grid — delivers the comprehensive integration platform for the next decade of enterprise connectivity. Host Integration Server: Continued Support for Mainframe Workloads Host Integration Server (HIS) has long provided essential connectivity for organizations with mainframe and midrange systems. To ensure continued support for those workloads, Host Integration Server 2028 will ship as a standalone product with its own lifecycle, decoupled from BizTalk Server. This provides customers with more flexibility and a longer planning horizon. Recognizing Mainframe modernization customers might be looking to integrate with their mainframes from Azure, Microsoft provides Logic Apps connectors for mainframe and midrange systems, and we are keen on adding more connectors in this space. Let us know about your HIS plans, and if you require specific features for Mainframe and midranges integration from Logic Apps at: https://aka.ms/lamainframe Azure Logic Apps: The Successor to BizTalk Server Azure Logic Apps, part of Azure Integration Services, is the modern integration platform that carries forward what customers value in BizTalk while unlocking new innovation, scale, and intelligence. With 1,400+ out-of-box connectors supporting enterprise, SaaS, legacy, and mainframe systems, organizations can reuse existing BizTalk maps, schemas, rules, and custom code to accelerate modernization while preserving prior investments including B2B/EDI and healthcare transactions. Logic Apps delivers elastic scalability, enterprise-grade security and compliance, and built-in cost efficiency without the overhead of managing infrastructure. Modern DevOps tooling, Visual Studio Code support, and infrastructure-as-code (ARM/Bicep) ensure consistent, governed deployments with end-to-end observability using Azure Monitor and OpenTelemetry. Modernizing Logic Apps also unlocks agentic business processes, enabling AI-driven routing, predictive insights, and context-aware automation without redesigning existing integrations. Logic Apps adapts to business and regulatory needs, running fully managed in Azure, hybrid via Arc-enabled Kubernetes, or evaluated for air-gapped environments. Throughout this lifecycle transition, customers can continue to rely on the BizTalk investments they have made while moving toward a platform ready for the next decade of integration and AI-driven business. Charting Your Modernization Path Microsoft remains fully committed to supporting customers through this transition. We recognize that BizTalk systems support highly customized and mission-critical business operations. Modernization requires time, planning, and precision. We hope to provide: Proven guidance and recommended design patterns A growing ecosystem of tooling supporting artifact reuse Unified Support engagements for deep migration assistance A strong partner ecosystem specializing in BizTalk modernization Potential incentive programs to help facilitate migration for eligible customers (details forthcoming) Customers can take a phased approach — starting with new workloads while incrementally modernizing existing BizTalk deployments. We’re Here to Help Migration resources are available today: Overview: https://aka.ms/btmig Best practices: https://aka.ms/BizTalkServerMigrationResources Video series: https://aka.ms/btmigvideo Feature request survey: https://aka.ms/logicappsneeds Reactor session: Modernizing BizTalk: Accelerate Migration with Logic Apps - YouTube 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 CorporationBringing all your Integration workloads to Logic Apps Standard
We recently announced the end of life of BizTalk Server and provided a path forward for our customers. As part of that commitment, we’re investing in tooling and guidance that reduces migration complexity and helps teams modernize confidently to Azure Logic Apps Standard. Because enterprise integration programs are rarely “lift and shift,” we’re pairing automation with best practices, reference architectures, and field-proven guidance to support you from assessment through cutover. In our December 2025 announcement, we outlined a long-term direction for enterprise integration: Azure Logic Apps is the successor to BizTalk Server. Customers can modernize at a pace that balances continuity with innovation—while moving to a cloud platform designed for scale, hybrid operations, DevOps, and AI-assisted automation. The strategy centers on three principles: a predictable BizTalk lifecycle runway, preservation of existing investments, and a practical, guided migration path to Logic Apps. What makes this strategy credible is not just the vision—but the concrete tooling and guidance that back it up. Announcing the Logic Apps Migration Agent: An Open-source project to provide an AI End-to-End Modernization Experience Today we’re announcing the Logic Apps Migration Agent—an open-source Microsoft project that delivers an AI-assisted, end-to-end modernization experience with a structured, stage-gated workflow. Built by the product group and shaped by direct field feedback, the agent operationalizes how migrations should be executed: discover what you have, plan what you’ll modernize, convert incrementally, and validate continuously. The result is a repeatable approach that helps customers (and partners) migrate from BizTalk and other integration platforms to Azure Logic Apps with greater speed and confidence—without compromising governance or correctness. The agent reinforces the modernization strategy through: Discovery → Planning → Conversion: Aligns to Microsoft modernization guidance so teams understand scope, dependencies, and gaps before committing to conversion. Human-in-the-loop checkpoints: Uses AI to accelerate analysis and baseline conversions while enforcing review and approval steps for mission-critical correctness and governance. VS Code + GitHub Copilot integration: Brings migrations into a code-first workflow—enabling developer-centric refactoring, DevOps practices, and consistent implementation patterns for Logic Apps. Incremental, flow-group migration: Modernize one logical unit at a time to reduce risk, support phased cutovers, and avoid big-bang rewrites. Bring-your-own black-box testing: Import existing files, test cases, and specifications to validate behavior and reduce custom test harness work. In short, the Migration Agent turns high-level modernization guidance into a repeatable, auditable process teams can trust. This alignment is critical for customers running mission‑critical integrations. It replaces uncertainty with a clear path: modernize incrementally, reuse what works, validate every step, and emerge on Azure Logic Apps with a platform ready for the next decade of integration and AI-driven automation. What you should focus on? Target architecture decisions: the agent will propose integration patterns, but will not choose partitioning strategy, reliability approach, or network topology—you will decide what “great” looks like. Semantic equivalence: The Agent will generate baseline artifacts, but domain-specific mapping, transformation nuances, error handling semantics, and edge cases still require human validation. Connector and parity gaps must be addressed: if a source platform capability has no 1:1 equivalent, the migration may require redesign (custom code, Local Functions, API Management, Service Bus patterns, or alternative connectors). Performance, security, and operations hardening remain essential: identity, secrets, policies, monitoring, cost controls, and SRE practices are not “one-click.” Cutover planning is outside the scope of automation: data/backlog reconciliation, dual-run strategies, and rollback plans remain project workstreams. 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. Support for local container registry (Hybrid deployment model). 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. For companies providing professional services: this agent is meant to augment your delivery—not replace it. By automating repeatable groundwork (inventory, baseline conversion, and validation scaffolding), it frees your teams to focus on the higher‑value work customers rely on you for: defining target architecture, refining mappings and patterns, hardening security and governance, implementing CI/CD, performance tuning, and driving cutover and operating model changes. Because the project is open source and extensible, partners can also package reusable accelerators (templates, connectors, mapping packs, test harnesses) and build differentiated migration offerings on top of the same trusted process. Review our public documentation here: https://learn.microsoft.com/en-us/azure/logic-apps/migration/migration-agent-overview Check the following video for a demonstration on how the Agent works:
Orchestrator Scheduling Challenge
Hi. I've been using SC orchestrator for almost a decade now. However, not until today have I needed to run something hourly and on the hour. Presently, when I configure this, in the "Monitor Date/Time activity I specify 0 days, 1 hour, and 0 minutes. Then I check the "Starting" checkbox and enter 0 for "minutes after the hour". Press finish, and come back in and it's unchecked. How can I schedule my hourly job to run at the hour mark? I have a workaround to run at the 1 minute after the hour mark, but that's ... not what we really want.
Unable to update Service request via SCO runbook
Good afternoon, Everyone, I’ve started developing a series of runbooks for our new service desk implementation, and one of the key requirements is the ability to automatically update Service Requests and other work items during the workflow. However, I’m running into an issue when attempting to pass the GUID of the Service Request into the “Update Object” activity. Even though the GUID is successfully retrieved from the Service Request and passed into the runbook as an input parameter, the activity reports that the value is an invalid GUID. This suggests that either the GUID is being transformed somewhere in the process, isn’t being interpreted correctly by the activity, or the wrong property is being supplied even though the value appears correct when inspected within the runbook. At this stage, I’m trying to determine whether the issue is caused by the way SCSM exposes the GUID, how the runbook passes the parameter, or a limitation quirk within the Update Object activity itself. Any guidance or examples of correctly updating Service Requests via runbooks especially when using GUID values dynamically would be greatly appreciated.
Orchestrator 2025 Security Credentials Problem
Hi, I’m experiencing an issue in SCO 2025 that has occurred across three different installations. In the Text File Management and File Management IPs, I’m unable to save the security credentials information for the activities. In other activities, such as Get Service Status, it works as expected. If I enter the account information, click Finish, and then reopen the properties, the fields are empty. As a result, the activity runs using the service account specified for the Orchestrator Runbook Service. Has anyone else experienced the same issue, or could there be something wrong with my installations? Get file status: Get service status:
果博东方开户+威a3322148
DPM 2019, using SQL 2019 on a 2019 server. The server was doing a consistency check on a file server. The check lasted about 33 hours and the items scanned showed over 4 million. There is no way a server could have 1 million files and folders, let alone 4 million. Does anyone know why the number of items scanned would be so high?System Center Orchestrator - OS Upgrade
Hello community, I am asking for your help to see how we can do an OS upgrade of our System Center Orchestrator infrastructure. We have our System Center Orchestrator 2019 infrastructure on Windows Server 2016. I would like to upgrade to Windows Server 2022. What is the best way to do this? I would like to use new servers and not do an in-place upgrade. What would be the procedure? Is SCORCH 2019 supported on 2022? I don't see it in the documentation. Thank you very much!!
Issue map prompts to properties
Hi, I am trying to create a new user account runbook so it can be used in the Self Service Portal. I start my runbook with an initialization of data and the following details: I have created my Service Request template and my Runbook automation activity template. In my Request Offering, I can map LastName, FirstName, etc., but I am not able to map Branch. What could be the issue? I need to know in which branch they work and I want it to be a simple list so they can choose from it. Please let me know if more information is required. Thanks for the help 🙂System Center Orchestrator 2022 Web Console Issues
This is more for information for others that have experienced the issues I have with System Center Orchestrator 2022 and the Web Console. Issues Discussed: Runbooks not visible in the Web Console Cannot remove stale runbook server entries Runbooks checked out in Web Console Issue 1: Runbooks not visible in the Web Console. In this issue the left hand pane where the runbook structure should be populated is blank. Solution 1: Ran this query on the Orchestrator DB GRANT CONTROL ON ASYMMETRIC KEY::[ORCHESTRATOR_ASYM_KEY] TO [Microsoft.SystemCenter.Orchestrator.Admins] GRANT CONTROL ON SYMMETRIC KEY::[ORCHESTRATOR_SYM_KEY] TO [Microsoft.SystemCenter.Orchestrator.Admins] GRANT EXECUTE ON object::[Microsoft.SystemCenter.Orchestrator].[GetSecurityToken] TO [Microsoft.SystemCenter.Orchestrator.Operators] GRANT SELECT ON object::[Microsoft.SystemCenter.Orchestrator.Internal].[Settings] TO [Microsoft.SystemCenter.Orchestrator.Operators] GRANT SELECT ON object::[Microsoft.SystemCenter.Orchestrator.Internal].[AuthorizationCache] TO [Microsoft.SystemCenter.Orchestrator.Admins] Issue 2: Unable to delete stale or orphaned runbook server instances I decommissioned some older runbook servers but was unable to delete them from any of the orchestrator consoles. Solution: Run these sql queries against the orchestartor database DELETE FROM [Orchestrator].[dbo].[CLIENTCONNECTIONS] WHERE [ClientMachine] = 'SCORCHRB' -- Here SCORCHRB is my Runbook Server Name. DELETE FROM [Orchestrator].[dbo].[ACTIONSERVERS] WHERE [Computer] = 'SCORCHRBServer' -- Here SCORCHRBServer is my Runbook Server Name. DELETE FROM dbo.OBJECTS where Name = ‘SCORCHRBServer’ -- Here SCORCHRBServer is my Runbook Server Name. Issue 3: Runbooks remain in the checked out state in the web console I have run into an issue where no matter how many times i check in a runbook, the runbook in the web console remains checked out. Solution 3: Run this sql query against the orchestrator database use Orchestrator GO Truncate table [Microsoft.SystemCenter.Orchestrator.Internal].AuthorizationCache DECLARE @secToken INT DECLARE tokenCursor CURSOR FOR SELECT Id FROM [Microsoft.SystemCenter.Orchestrator.Internal].SecurityTokens where ExpirationTime >= GETUTCDATE() OPEN tokenCursor FETCH NEXT FROM tokenCursor INTO @secToken WHILE @@FETCH_STATUS = 0 BEGIN PRINT 'Computing Authorization Cache for Security Token: ' + Convert(Nvarchar, @secToken) exec [Microsoft.SystemCenter.Orchestrator].ComputeAuthorizationCache @TokenId = @secToken FETCH NEXT FROM tokenCursor INTO @secToken END CLOSE tokenCursor DEALLOCATE tokenCursor
