azure-upgrade

Azure 升级

此技能用于评估并自动将现有 Azure 工作负载从一种 Azure 服务、托管计划或 SKU 升级到另一种——整个过程都在 Azure 内完成。这包括计划／层级升级（例如，从 Consumption 升级到 Flex Consumption）、跨服务迁移（例如，从 App Service 迁移到 Container Apps）以及 SKU 变更。它还涵盖 Azure SDK for Java 源代码现代化（例如，将旧版 Java com.microsoft.azure.* 升级到现代版 com.azure.*）。此技能不用于跨云迁移；如需跨云迁移，请使用 azure-cloud-migrate。

触发条件

用户意图	示例提示
升级 Azure Functions 计划	“将我的函数应用从 Consumption 升级到 Flex Consumption”
查找可升级的 Functions 候选项	“我有哪些 Consumption Function Apps 可以升级到 Flex Consumption？”
更改托管层级	“将我的函数应用迁移到更好的计划”
评估升级准备情况	“我的函数应用是否已准备好升级到 Flex Consumption？”
自动执行计划迁移	“自动执行升级我的 Functions 计划的步骤”
现代化旧版 Azure Java SDK	“迁移旧版 Azure SDK for Java”、“升级旧版 Azure Java SDK”、“将我的 Java 项目从 com.microsoft.azure 迁移到 com.azure”
将 Azure Cache for Redis（ACR/OSS）迁移到 Azure Managed Redis（AMR）	“将我的 Redis 缓存迁移到 AMR”、“ACR 到 AMR”、“OSS 到 AMR”、“将我的 Premium P2 缓存升级到 Managed Redis”、“选择 AMR SKU”、“将我的 Redis IaC 模板转换为 AMR”
将 Azure Cache for Redis Enterprise（ACRE）迁移到 Azure Managed Redis（AMR）	“将我的 Enterprise_E10 缓存迁移到 AMR”、“ACRE 到 AMR”、“更新我的 ACRE IaC 模板以适用于 AMR”、“将 EnterpriseFlash 迁移到 AMR”、“迁移我的异地复制 Enterprise Redis”

规则

1. 按顺序执行各阶段。仅在所选场景明确允许时，才跳过或延后工作，并在迁移状态中记录原因。
2. 在执行任何升级操作之前，先生成评估。
3. 加载场景参考并遵循其中的规则。
4. 使用 mcp_azure_mcp_get_azure_bestpractices 和 mcp_azure_mcp_documentation MCP 工具。
5. 破坏性操作需要使用 ask_user — global-rules
6. 继续操作之前，务必与用户确认目标计划／SKU。
7. 为任何新资源提出名称（默认值：<source>-<target-suffix>，例如，Flex Consumption 迁移使用 <source>-flex），并且在创建前告知用户建议的名称，以便用户无需通过阻塞式提示即可更改名称。此规则同样适用于其他新建资源（存储帐户、App Insights 等）；服务专属的默认值请参阅场景参考。
8. Windows Consumption → Flex 的源更改关卡：默认将源应用视为只读。每次执行会更改其设置、触发器、状态、部署、绑定或是否存在的命令之前，立即使用 ask_user 说明具体变更并获取明确批准。批准仅适用于对应操作，不能用于后续的源更改。
9. 未经用户明确确认，绝不删除或停止原始应用。
10. 确保需要批准的工作流持续推进：每完成一步后，立即执行下一项只读预检查。如果下一项操作需要批准，则在同一轮中调用 ask_user；不要仅告知下一步，然后停下来等待用户再次发起对话。
11. 所有自动化脚本都必须具备幂等性且可恢复执行。

升级场景

源	目标	参考
Azure Functions Consumption Plan (Linux)	Azure Functions Flex Consumption Plan	workflow.md
Azure Functions Consumption Plan (Windows)	Azure Functions Flex Consumption Plan	workflow.md
旧版 Azure Java SDK（com.microsoft.azure.*）	新版 Azure Java SDK（com.azure.*）	languages/java/README.md
Azure Cache for Redis (ACR/OSS) Basic/Standard/Premium	Azure Managed Redis (AMR)	services/redis/redis-to-amr.md
Azure Cache for Redis Enterprise (ACRE) / Enterprise Flash	Azure Managed Redis (AMR)	services/redis/redis-to-amr.md

**Functions Consumption-to-Flex 路由：**对于指定的应用，请检查其 Azure 平台，并仅加载匹配的 Linux 或 Windows 工作流。对于订阅范围的发现，请评估两个平台：Linux 使用 az functionapp flex-migration list，Windows 则使用其工作流中的手动发现和兼容性检查。在评估每个应用的代码兼容性之前，请将 Windows 结果标记为候选项。

SDK 升级场景（例如 Java 从旧版升级到新版）采用源代码现代化流程，与 Azure 服务/计划/SKU 升级不同：请遵循场景参考，而非以下步骤。

没有匹配的场景？请使用 mcp_azure_mcp_documentation 和 mcp_azure_mcp_get_azure_bestpractices 工具研究升级路径。

MCP 工具

工具	用途
mcp_azure_mcp_get_azure_bestpractices	获取目标服务的 Azure 最佳实践
mcp_azure_mcp_documentation	查找有关升级场景的 Azure 文档
mcp_azure_mcp_appservice	查询 App Service 和 Functions 计划详细信息
mcp_azure_mcp_applicationinsights	验证监视配置

步骤

1. 识别 — 确定源和目标 Azure 计划/SKU。请用户确认。
2. 评估 — 分析现有应用是否已做好升级准备 → 加载场景参考（例如，workflow.md）
3. 迁移前准备 — 从现有应用收集设置、身份和配置
4. 升级 — 执行自动升级步骤（创建新资源、迁移设置、部署代码）
5. 验证 — 使用所选场景定义的检查项：验证目标资源状态、适用的 HTTP 终结点和非 HTTP 触发器，以及监视。如果访问限制或测试资源不可用导致无法执行验证，请将验证记录为延期；绝不要自动放宽安全措施或报告功能正常。
6. 询问用户 — 提供性能验证和 IaC 更新选项。只有在所选场景确认已切换到生产环境且所有清理前提条件均已满足时，才提供源代码清理选项。
7. 移交 给 azure-validate 进行深入验证，或移交给 azure-deploy 设置 CI/CD

在 <UPGRADE_DIR>/upgrade-status.md 中跟踪进度 — 有关路径解析，请参阅产物输出策略。

参考资料

• 全局规则
• 工作流详情
• Functions
  • Linux
    • Consumption 到 Flex Consumption
    • 评估
    • 自动化脚本
  • Windows
    • Consumption 到 Flex Consumption
    • 评估
    • 自动化脚本
• Redis
  • Redis（ACR 或 ACRE）迁移到 AMR — 指向专用的 amr-migration-skill（ACR/OSS）或 acre-to-amr-migration-skill（Enterprise）
• Java SDK 迁移模板
  • 计划模板
  • 进度模板
  • 总结模板

后续步骤

升级验证通过后，移交给：

• azure-validate — 进行全面的升级后验证
• azure-deploy — 如果用户希望为新应用设置 CI/CD