基于云的应用Lift and Shift迁移：外部Azure应用迁至内部云咨询

1. 环境调研与目标匹配 #

• 明确内部云目标环境：对比外部Azure的现有资源配置（VM规格、存储类型、网络架构等），在内部Azure或AWS中找到对应等效服务（比如外部用Azure App Service，内部Azure可复用同类型服务，AWS可选Elastic Beanstalk）。
• 核查内部云资源配额与合规要求：确认内部云的资源上限、数据驻留政策、安全管控规则，避免迁移后出现资源不足或合规违规问题。
• 验证网络连通性：确认内部云与外部Azure之间的网络通路（VPN/专线）是否打通，排查防火墙、安全组对资源访问的限制。

2. 应用与依赖全量梳理 #

• 拆解应用组件：记录Angular前端的部署方式（静态文件托管、CDN配置）、.NET后端的托管类型（VM/App Service/容器）、数据库类型与版本（Azure SQL DB/SQL Server）及备份策略。
• 枚举第三方依赖：列出外部Azure依赖的Storage Account、Redis Cache、Service Bus等服务，确认内部云是否有替代方案，或是否需要同步迁移这些依赖资源。
• 归档配置信息：整理应用的环境变量、连接字符串、SSL/客户端证书等敏感配置，提前规划内部云的加密存储方案（比如Azure Key Vault/AWS Secrets Manager）。

3. 权限与访问控制规划 #

• 映射IAM权限：将外部Azure的现有RBAC权限（部署账号、资源访问角色）对应到内部云的权限体系（内部Azure RBAC/AWS IAM策略），确保迁移团队拥有必要的操作权限。
• 适配身份认证系统：确认内部云的身份验证方式（AD/SSO），若与外部Azure AD不一致，提前评估是否需要微调应用认证逻辑（尽量贴合Lift and Shift原则，最小化改动）。
• 管控临时权限：为迁移团队开通外部Azure只读权限、内部云资源创建权限，迁移完成后及时回收权限。

4. 迁移工具与流程选型 #

• 按组件匹配工具：
  • VM迁移：内部Azure用Azure Migrate，AWS用Migration Hub + Server Migration Service，先完成测试迁移验证可行性。
  • App Service迁移：内部Azure用App Service Migration Assistant，AWS用App2Container将.NET应用打包为容器部署，或直接部署至Elastic Beanstalk。
  • 数据库迁移：内部Azure用Database Migration Service，AWS用Database Migration Service，提前做数据同步测试确保一致性。
• 规划迁移顺序：优先迁移依赖服务（数据库、缓存），再迁移后端，最后迁移前端，避免应用启动依赖缺失。

5. 测试与回滚方案预演 #

• 搭建复刻测试环境：完全复制外部Azure的应用配置，部署测试版本，验证前端页面加载、后端接口调用、数据库读写等核心功能。
• 制定回滚策略：保留外部Azure资源至迁移验证完成，提前做好DNS切换预案，确保迁移失败时可快速切回原环境。
• 开展性能测试：在内部云测试应用响应时间、吞吐量，对比外部环境指标，确保迁移后性能不下降。

6. 风险预案制定 #

• 识别潜在风险：梳理网络延迟导致迁移超时、数据同步不一致、内部云资源不足、权限配置错误等风险点。
• 制定应对措施：提前扩容内部云资源、多次开展数据同步测试、准备权限清单逐一核对。
• 确定迁移窗口期：选择业务低峰期执行迁移，提前通知相关团队，降低对用户的影响。

内容的提问来源于stack exchange，提问作者Anilal