当你准备将 BizTalk Server 解决方案迁移到 Azure 逻辑应用 Standard 时，可以通过使用 Visual Studio Code 的 Migration Agent 扩展，将你的企业集成现代化为标准逻辑应用解决方案。 该代理是一个开源扩展，通过 GitHub Copilot 和 Visual Studio Code 语言模型 API 提供 AI 辅助工作流程，指导你从发现到部署。
迁移不是一个搬运和转移的过程。 保留所需的业务行为，但重构实现以使用适当的 Azure 逻辑应用 工作流、连接器、自定义代码、身份、消息传递、监控和部署实践。 从Azure 逻辑应用 Standard作为目标应用开始，适当使用原生工作流程功能、内置连接器、转换和本地功能，只有在特定架构需求需要时才添加其他Azure服务。 关于现代化原因和能力摘要，请参见《Why migrate from BizTalk Server to Azure 逻辑应用 Standard？》
Important
迁移代理加速分析并生成基线实现工件，但不替代架构审查或测试。 在部署前，检查每个阶段的输出，并验证所有生成的工作流程、连接、配置和代码。
有关简介和演示，请参阅“使用 Azure 逻辑应用 Migration Agent 将任何集成平台现代化并迁移到 Azure 逻辑应用 Standard”。 如需检查实现、报告问题或贡献意见，请参见 Logic Apps 迁移代理仓库。
支持的迁移范围
下表描述了Azure 逻辑应用 Migration Agent 1.12.1版本中的BizTalk Server源码及Azure 逻辑应用目标支持。 在开始迁移前，请查看 迁移代理发布 版本是否有更改。
| Scope | 版本 1.12.1 支持 |
|---|---|
| BizTalk Server 源端 | BizTalk Server 2016和2020。 内置解析器支持项目（.btproj）、编排（.odx）、映射（.btm）、架构（.xsd）、管道（.btp）、绑定（BindingInfo.xml、Binding*.xml，或按名称或内容识别的绑定 XML）、主机数据布局（.hidx）、业务规则（.bre、.brl）和 Web 服务（.asmx）文件。 |
| 转换目标 | Azure 逻辑应用 Standard 项目工件，包括工作流程、连接、配置和支持代码。 你可以将生成的项目适配并部署到支持的标准托管选项中。 |
| 自动化部署目标 | 工作流程服务计划。 迁移代理版本 1.12.1 不支持自动部署到 应用服务环境 v3 托管。 使用生成的 Standard 项目和相应的产品指南，分别对这些托管选项实施部署。 |
解析器支持意味着扩展可以发现并表示列出的源文物。 缺失的依赖、不支持的构造以及应用程序特定代码仍然需要调查，甚至可能需要手动实现。 生成的分析、计划、工作流、连接、配置和代码都需要审查和验证。
迁移代理架构可通过贡献的解析器和平台专属技能扩展到其他集成平台，但该扩展默认并不支持所有平台的完整迁移。 有关当前平台状态和扩展指导，请参阅 Azure 逻辑应用 Migration Agent 概述 和 将 Azure 逻辑应用 Migration Agent 扩展到其他平台。
迁移代理的工作原理
该扩展将迁徙分为五个阶段。 在进入下一阶段前，请完成并复习每个相关阶段。 部署是可选的，需要单独批准。
| 阶段 | 代理结果 | 你的责任 |
|---|---|---|
| 发现 | 扫描源文件，构建库存和依赖图，组织流组，识别模式和空白，并生成架构和消息流视图。 | 确认工件、端点、依赖关系和流边界是完整且准确的。 |
| Planning | 将组件映射到 Azure 逻辑应用 模式，生成目标架构、工作流定义、Azure 组件需求、动作映射、工件判定、缺口分析和集成模式。 | 选择目标架构，解决漏洞，调整边界，定义托管和成本假设，并批准计划。 |
| 转换 | 在批准计划需要时生成标准工作流程、连接、支持项目文件和 .NET 本地功能。 | 检查生成的定义和代码，替换无效配置，并实现未解决的行为。 |
| 验证 | 运行生成的工作流程，并帮助将其行为与源规范和测试进行比较。 | 提供代表性的输入和预期输出，测试边缘案例，验证语义等价性。 |
| 部署 （可选） | 在分别获得批准后，准备好 Azure 资源，并将经审核的 Azure 逻辑应用 Standard 项目部署到工作流服务计划。 | 批准环境、身份、网络、配置、安全性、成本和生产版本计划。 |
BizTalk解决方案中的自定义代码并不会自动要求单独的Azure Functions资源。 转换阶段可以生成针对工作流范围逻辑的 .NET 本地函数，使工作流和代码能够在同一 Azure 逻辑应用 Standard 应用中共同构建、部署、扩展和运行。 当代码需要在不同应用间共享，或需要独立扩展、版本管理、部署、安全性或所有权时，使用单独的 Azure Functions 资源。 欲了解更多信息，请参阅 BizTalk 迁移的自定义代码指南。
三款专用的 Copilot 代理支持该工作流程：
-
@migration-analyser对发现的文物进行分组和分析。 -
@migration-planner创建迁移计划和源到目标映射。 -
@migration-converter根据批准的计划生成工作流程、连接和支持代码。
扩展存储阶段输出，方便你检查和修正生成的库存、架构、计划和实施工件。 将这些检查点视为必要的工程审查，而非自动批准。
BizTalk能力映射提供了常见现代化路径的高层视图。 在规划过程中，迁移代理为每个流程生成 操作级映射 ，识别没有直接对应的组件，并推荐解决方案。
准备迁移
在开始发现之前，收集源实现和验证其行为所需的证据：
- BizTalk解决方案和项目文件
- 绑定与环境特定配置
- 编排、模式、映射、管道和管道组件
- 业务规则、汇编及其他自定义代码
- HIDX 文件
- 端点和适配器信息
- 证书或证书引用，无需暴露私钥或机密
- 现有架构与操作文档
- 代表性输入消息与预期输出
- 单位测试、积分测试、回归测试和黑箱测试
- 吞吐量、延迟、订购、消息大小、恢复和可用性要求
将相关文件和依赖项保存在清晰的目录结构中。 发现质量取决于原始材料的完整性。 在授权规划或转换前，先解决遗漏的依赖和错误的流程分组。
逐步现代化
对于大多数 BizTalk 环境，建议分阶段迁移，而不是采用一次性集中发布。 利用发现结果将相关工件分组到端到端的集成流程，然后根据业务价值、风险、复杂性、预期运营成本、支持时间表和依赖性对流程进行优先级排序。
对于每一波：
- 选择一个或多个具有代表性的流组。
- 完成并检查适用的迁移代理阶段。 只有当你希望代理部署到工作流服务计划时，才运行可选部署阶段。
- 在代表性环境中验证行为和非功能性需求。
- 规划共存安排、与合作伙伴协调、切换实施、回滚以及积压事项核对。
- 发布已迁移的流程，并确认生产监控和支持职责归属。
- 捕捉可复用的映射、架构模式、测试、部署资产以及后续阶段的经验教训。
从一个足够有意义以验证目标架构，同时又足够内涵以暴露漏洞、同时不危及关键迁移路径的流程开始。
从 Azure 逻辑应用 Standard 应用开始，对每个波次进行估算，并且仅在已批准的架构要求时才添加所需的 Azure 支持服务。 每个服务的配置和计费都是独立的。 在估算中包括标准托管、托管连接器调用、存储、网络、监控、支持服务以及临时BizTalk共存。 更多信息请参见 “构建一个具成本效益的目标架构”。
你团队还拥有什么
迁移代理自动化了可重复的工作。 您的团队仍需对生产集成解决方案所需的决策和证据负责。
| 责任 | 需要审核 |
|---|---|
| 目标体系结构 | 从Azure 逻辑应用标准应用边界开始。 定义工作流程、消息传递、网络和部署边界。 只有在需求合理时才添加支持 Azure 服务，而不是复制 BizTalk 的拓扑结构。 |
| 语义等价 | 核实合同、映射、规则、路由、排序、重试、错误行为和边缘情况。 |
| 能力缺口 | 优先使用原生工作流功能和 .NET 本地函数，以实现工作流范围逻辑。 当解决方案需要独立边界时，可以使用消息传递、API 管理、单独的 Azure Functions 资源或其他外部服务。 |
| 安全性与配置 | 实现身份、授权、秘密管理、证书、网络控制以及环境特定设置。 |
| 生产环境加固 | 完整的性能、规模、弹性、灾难恢复、成本、监控和作战准备测试。 |
| 切换与共存 | 协调合作伙伴和依赖系统，梳理并协调处理正在进行中的工作，制定回滚方案，并且仅在验证完成后才停用 BizTalk 组件。 |
仅对业务影响和可用性要求符合该分类的工作负载应用关键任务设计指导。
后续步骤
安装扩展，准备完整的源文件夹，然后从 Discovery 开始。 保持源项目不变，并将生成输出写入独立目的地，这样你可以比较实现并安全地重复迁移。