1. 迁移与现代化改造总览

Azure 平台迁移与现代化改造，指的是把现有工作负载从本地数据中心、托管机房或其他云平台，迁移到 Microsoft Azure，并在迁移过程中或迁移之后，对应用架构、数据平台、运行方式和运维模式进行升级。它并不是一个单纯的“搬家”动作，而是一条从“能运行”到“运行得更好”的连续路径。理解这条路径，需要先分清两个概念：迁移（Migration）关注的是把现有资产尽可能低风险地搬到 Azure 上，保持业务连续性；现代化改造（Modernization）关注的是借这次搬迁的机会，改变应用的构建、部署、伸缩和运维方式，让它更适合云环境。

两者常常被混为一谈，但目标不同。迁移的核心指标通常是停机时间、数据一致性、回滚能力和成本可控；现代化的核心指标则是交付速度、弹性伸缩、可观测性、自动化程度和单位算力成本。一个常见的误区是“先全部现代化再迁移”，这往往导致项目周期失控。更现实的做法是：先按业务价值和技术风险对工作负载分层，能直接迁移的先迁移，需要改造的分批改造，最后把不适合上云的部分保留或替换。

业务驱动与技术维度

企业启动迁移与现代化改造，通常由几类业务驱动推动：数据中心租约到期或硬件生命周期结束，需要降低机房和运维成本；业务增长要求系统具备弹性伸缩能力，而本地资源扩容周期长；合规与安全要求提高，需要统一身份、加密和审计能力；还有一类是希望借助 Azure 的 PaaS 与 AI 服务快速推出新功能。这些驱动决定了迁移的优先级和节奏，而不是技术本身。

从技术维度看，迁移与现代化改造可以拆成五个层面：计算（虚拟机、容器、App Service、Functions）、数据（SQL 数据库、Cosmos DB、数据湖、Synapse）、网络（虚拟网络、ExpressRoute、VPN、Private Endpoint）、身份与安全（Microsoft Entra ID、RBAC、Key Vault、Defender for Cloud）、运维与治理（Azure Monitor、Policy、Cost Management、Bicep/Terraform）。这五个层面相互依赖，任何一层设计不当，都会在迁移后暴露为性能、安全或成本问题。

典型场景与判断依据

不同工作负载适合不同策略。一个运行多年、业务逻辑稳定、但硬件老化的内部管理系统，通常适合“重新托管”，先搬到 Azure VM 上，利用 Azure 的备份、可用性集和监控能力降低运维压力。一个自建 SQL Server 且数据量在数 TB 以内的业务系统，适合“重新平台化”到 Azure SQL 数据库或托管实例，从而获得自动补丁、高可用和按需伸缩。一个频繁迭代、需要快速发布新功能的互联网应用，则更适合“重构”为容器化微服务，配合 AKS 和 CI/CD 流水线。至于已经停止维护、无法获得安全补丁的老系统，重建或替换往往比继续迁移更划算。

判断时可以用四个问题快速筛选：这个系统未来两年还会继续演进吗？停机窗口能接受多长？团队是否具备容器和 IaC 能力？迁移后的月度成本是否低于当前？如果四个问题都指向“保守”，就优先重新托管；如果多数指向“改造”，就考虑重新平台化或重构。这个判断不需要一次做完，可以在评估阶段用 Azure Migrate 的依赖关系分析、性能数据和成本估算来支撑。

课程路线图

本课程围绕“评估—迁移—现代化—治理”四条主线展开。前几章先建立总览与评估方法，包括业务论证、工作负载发现、依赖分析和迁移就绪度判断；随后进入具体迁移路径，分别讲解虚拟机、数据库、Web 应用和存储数据的迁移方式；再往后进入现代化改造，覆盖容器化、无服务器、数据平台现代化和 DevOps 流水线；最后落到安全、治理、成本优化和运维监控，确保迁移后的平台可持续运行。

学习时建议把每一章都对应到一个真实或假设的工作负载上。例如，假设你有一个本地部署的三层应用：前端 Web、后端 API、SQL Server 数据库。评估阶段先记录它的依赖、峰值并发、数据量和停机容忍度；迁移阶段可以先重新托管到 VM，再逐步把数据库重新平台化到 Azure SQL，最后把 API 重构为容器并接入 CI/CD。这样一条主线贯穿课程，比单独记忆每个服务名称更容易形成整体判断力。