1. 企业云迁移与现代化改造全景
当企业决定把业务系统从自建机房迁往 Azure 时，真正需要回答的并不是“服务器怎么搬过去”，而是“这套系统在云上应该长成什么样子”。迁移解决的是“位置”问题——把工作负载从本地搬到云端；现代化解决的是“形态”问题——让工作负载在云上以更合适的架构运行。二者不是先后割裂的两个项目，而是同一条演进路径上可以并行、可以分阶段推进的两类动作。理解这一点，是整门课程所有技术决策的起点。
一、Azure 在企业 IT 演进中的定位
Azure 在企业 IT 版图中承担三种角色。第一是基础设施承载者：通过虚拟机、虚拟网络、存储账户、负载均衡等 IaaS 能力，让现有应用几乎原样上云，这是迁移阶段最常用的落点。第二是平台服务提供者：通过 Azure SQL Database、App Service、Azure Kubernetes Service、Service Bus 等 PaaS 能力，把操作系统补丁、集群运维、弹性伸缩交给平台，这是现代化阶段的主要落点。第三是企业级治理与连接中枢：通过 Microsoft Entra ID、Azure Policy、Azure Monitor、ExpressRoute 等，把分散的订阅、本地数据中心和混合场景统一纳管。
这三层不是互斥的选项，而是同一企业可以同时使用的组合。一个典型的中型企业可能把核心 ERP 以虚拟机形式迁移（IaaS），把对外门户重构为 App Service（PaaS），同时用 Entra ID 统一身份、用 Policy 约束所有订阅的合规基线。判断某个系统该落在哪一层，取决于它的改造意愿、团队能力、停机窗口和业务连续性要求，而不是技术上的“先进程度”。
二、迁移与现代化的关系
业界常用 6R 来描述迁移策略：Rehost（重新托管）、Replatform（平台调整）、Repurchase（替换采购）、Refactor（重构）、Retire（退役）、Retain（保留）。其中 Rehost 属于纯迁移，Refactor 属于典型现代化，Replatform 介于两者之间。需要强调的是，6R 不是一次性选择，而是可以随时间推移的序列。很多企业先以 Rehost 快速上云、拿到成本与弹性收益，再在后续迭代中把关键模块逐步 Replatform 或 Refactor。
下面这张图展示了从本地环境到 Azure 的演进全景：左侧是本地工作负载，中间是迁移通道，右侧是云上可能的目标形态，底部是贯穿全程的治理与运维平面。
三、课程整体学习路径
本课程按“认知—评估—迁移—现代化—治理—实战”的逻辑展开，共 30 章。前几章建立全景认知与 Azure 基础概念，包括订阅、资源组、区域、可用性区域等；随后进入评估阶段，学习如何用 Azure Migrate 发现本地资产、生成依赖关系图和成本估算；迁移阶段覆盖虚拟机、数据库、文件数据、容器等不同工作负载的具体迁移方法；现代化阶段聚焦 App Service、AKS、无服务器、事件驱动架构与 DevOps 流水线；治理阶段讲解 Entra ID、Policy、Monitor、成本管理与安全基线；最后以综合实战项目收束。
需要提醒的是，学习路径不等于项目路径。真实项目中，评估、迁移、现代化往往交叉进行。例如在迁移一批虚拟机的过程中，团队可能已经同步把其中一个对外门户重构为 App Service。课程按知识模块组织，是为了让每个技术点讲透，而不是要求你按章节顺序执行项目。
四、实战项目介绍
课程贯穿一个虚构但贴近真实的企业案例：“Contoso 制造”。该企业拥有本地数据中心，运行着三类典型工作负载——一套基于 Windows Server 与 SQL Server 的 ERP 系统、一个对外客户门户、以及若干文件共享与内部工具。企业目标是在 9 个月内完成上云，同时把客户门户改造为可弹性伸缩的 PaaS 应用。
实战项目将按以下节奏推进，你可以把它当作一条可复现的主线：
- 第 1 阶段（评估）：用 Azure Migrate 发现约 120 台虚拟机、8 个 SQL Server 实例和 3 个文件共享，生成依赖关系图，识别出 ERP 与域控之间存在强依赖，客户门户相对独立。
- 第 2 阶段（迁移）：ERP 采用 Rehost，通过 Site Recovery 复制到 Azure 虚拟机，停机窗口控制在 4 小时内；SQL Server 用 Azure Database Migration Service 迁移到 Azure SQL 托管实例；文件共享用 Azure File Sync 做混合缓存。
- 第 3 阶段（现代化）：客户门户从 IIS 虚拟机重构为 App Service，接入 Entra ID 做身份认证，用 Azure SQL Database 替换本地数据库，配置自动缩放规则。
- 第 4 阶段（治理）：为所有订阅建立 Policy 基线，启用 Defender for Cloud，配置 Log Analytics 工作区集中收集日志，设置成本预算与告警。
五、如何判断一个系统该迁移还是该现代化
面对一个具体工作负载，可以用四个问题快速判断：第一，它是否还在被业务频繁修改？频繁修改的系统更适合现代化，因为改造收益能快速体现。第二，它的停机窗口有多长？停机窗口极短的系统，Rehost 通常更稳妥。第三，团队是否具备容器、微服务或 PaaS 的运维能力？能力不足时强行 Refactor 会带来长期运维负担。第四，它的合规与数据驻留要求是什么？某些系统必须保留在特定区域或特定形态，这会直接限制可选方案。