若要从Azure Stack Hub上的Azure 应用服务成功迁移到Azure 应用服务，请先全面评估现有环境。 在选择迁移策略之前，评估应用程序体系结构、平台依赖项、操作要求、合规性约束和业务目标。
评估应用程序适用性
识别Azure Stack Hub上托管Azure 应用服务的所有应用程序，并根据复杂性和关键性对这些应用程序进行分类。
对于每个应用程序，请记录：
- 应用程序所有者和利益干系人
- 业务关键性
- 运行时和框架版本
- 外部服务依赖项
- 身份验证提供程序
- 网络连接要求
- 性能和扩展性要求
- 可用性和灾难恢复要求
具有最小依赖项的应用程序可能适合直接迁移。 依赖于特定于平台的集成或旧基础结构的应用程序可能需要迁移前的现代化活动。
评估应用程序依赖项
许多应用程序依赖于应用服务本身之外的服务。 了解这些依赖项对于迁移规划至关重要。
评估：
- SQL Server 数据库
- 文件共享和存储系统
- 内部 API
- Active Directory 或 Microsoft Entra ID 集成
- 消息队列和事件系统
- SMTP 服务
- 第三方服务
- 监视和日志记录平台
确定是否存在依赖项：
- 保留在本地
- 继续使用 Azure Stack Hub
- 迁移到Azure
- 被替换为 Azure 原生服务
迁移后，具有大量本地依赖项的应用程序可能需要 VPN、ExpressRoute、专用终结点或混合网络配置。
评估托管模型选项
迁移提供了重新评估托管应用程序的方式的机会。
建议的迁移方法取决于应用程序类型和复杂性。
| 应用程序类型 | 建议的目标 |
|---|---|
| ASP.NET Core应用程序 | Azure 应用服务 （Windows 或 Linux） |
| Java应用程序 | 适用于 Linux 的 Azure 应用服务 |
| Node.js 应用程序 | 适用于 Linux 的 Azure 应用服务 |
| Python应用程序 | 适用于 Linux 的 Azure 应用服务 |
| PHP 应用程序 | 适用于 Linux 的 Azure 应用服务 |
| 基于Windows的现有 ASP.NET 框架应用程序 | Azure 应用服务（Windows） |
| 容器化应用程序 | Azure 应用服务容器、Azure 容器应用或Azure Kubernetes 服务 (AKS) |
规划网络变更
Azure中的网络体系结构可能与Azure Stack Hub部署大相径庭。
查看以下要求：
- 专用应用程序访问
- 入站互联网流量
- 混合连接
- 内部 DNS 解析
- 网络隔离
- 法规要求
确定 Azure 网络功能是否例如：
- 虚拟网络集成
- 专用端点
- Azure 应用程序网关
- Azure Front Door
- Azure 防火墙
是目标体系结构的一部分所必需的。
查看身份和安全要求
迁移到Azure 应用服务时，可以访问更多标识和安全功能。 可以简化现有安全体系结构。
请考虑采用：
- Microsoft Entra ID 身份验证
- 管理标识
- Azure 密钥保管库 参考资料
- Azure RBAC
- 专用端点
- 条件性访问策略
在设计目标环境之前，组织还应查看证书管理、机密管理和合规性要求。
选择适当的迁移策略
不同的应用程序可能需要不同的迁移方法。
| Strategy | 说明 | 典型用例 |
|---|---|---|
| Rehost | 只需极少修改即可迁移应用程序 | 新式应用程序已与Azure 应用服务兼容 |
| 平台迁移 | 在迁移期间更新配置或支持服务 | 需要基础结构现代化的应用程序 |
| 重构 | 修改应用程序体系结构以利用Azure服务 | 具有长期投资计划的战略应用程序 |
| 实现现代化 | 使用云原生服务重新生成应用程序部分 | 需要重大转换的应用程序 |
并非每个工作负荷都需要在迁移过程中实现现代化。 某些组织选择先迁移，然后在应用程序在Azure中成功运行后以增量方式实现现代化。
验证区域部署要求
你可以跨各种Azure区域部署Azure 应用服务。 通过使用多个区域，与单个Azure Stack Hub部署相比，组织可以改善延迟、复原能力和合规性结果。
评价：
- 数据驻留要求
- 用户邻近度
- 灾难恢复要求
- 可用性区域支持
- 按区域划分的服务可用性
对于业务关键型工作负荷，请考虑适当的多区域或区域冗余体系结构。
评估规模和容量要求
迁移应包括对当前和未来增长要求的审查。
文档：
- 当前实例数量
- 高峰流量模式
- CPU 和内存利用率
- 季节性需求波动
- 增长预测
此评估有助于确定合适的 Azure 应用服务 计划，以及是否需要高级功能。
建立迁移方法和时间线
为迁移项目定义以下元素：
- 迁移波
- 测试里程碑
- 回滚流程
- 用户验收条件
- 生产直接转换计划
对于大型资产，请使用分阶段迁移方法：
- 试点应用程序
- 非生产环境
- 低风险生产应用程序
- 业务关键型生产工作负荷
此方法可帮助团队在迁移任务关键型应用程序之前通过Azure 应用服务获得运营经验。
定义成功条件
在迁移开始之前，建立可衡量的成功标准。
示例包括：
- 成功部署到 Azure 应用服务
- 没有关键功能回归
- 性能等于或优于源环境
- 安全性和符合性验证已完成
- 已配置监控和告警
- 运维操作手册已更新
明确定义的成功条件有助于确保迁移活动与业务目标保持一致，并降低部署风险。
Tip
将迁移视为平台转换和现代化机会。 虽然通常只需极少更改即可迁移应用，但仍需评估诸如 Linux 托管、专用终结点、托管标识、Azure Front Door 和可用性区域等功能。