为什么迁移常常出问题（以及您面临的风险）
传统的迁移方式异常复杂。当采用手动或临时性方式操作时，组织最终往往会面临以下环境问题：
- 缺乏一致性：各工作负载间不一致，导致工作负载启动或扩展时行为难以预测。
- 缺失安全、身份和治理护栏——增加了意外暴露、错误配置或不合规的风险。
- 长期管理困难：因为每个工作负载的配置略有不同，或缺少共享的集中式服务。
其结果通常是：浪费大量时间进行故障排查，与团队和审计人员反复沟通，并且云部署往往无法实现预期的投资回报率。
解决方案：Azure Migrate + 智能平台着陆区部署
这正是Azure Migrate与**“平台着陆区”** 基础相结合，引入秩序与可预测性的地方。正如视频中所解释的：
- Azure Migrate帮助您发现、评估本地服务器、数据库、Web应用和其他工作负载，并将其迁移到Azure。了解更多。
- **Azure 着陆区 (ALZ)**定义了一个遵循最佳实践的云环境，涵盖身份、连接、安全、管理、治理等方面。了解更多。
- **“平台着陆区”**提供了共享服务（如网络、身份、日志记录、策略），所有新旧工作负载都将继承这些服务。
通过将Azure Migrate的自动化与精心设计的着陆区相结合，组织可以跳过容易出错的手动步骤。工作负载不仅能够迁移到云端，而且会落地在一个从一开始就旨在实现安全、合规和可扩展的云环境中。
“智能”方法的优势所在
从该集展示的内容（以及Azure官方文档推荐）来看，这种方法带来了几个引人注目的好处：
- 默认的一致性与治理——由于着陆区是预配置的（包含身份、访问权限、网络拓扑、策略、日志记录等），每个迁移的工作负载都会自动遵循相同的标准。这有助于避免配置漂移和合规性差距。
- 速度与自动化——使用基础设施即代码（IaC）或基于门户的加速器，您可以快速部署平台和着陆区。这样，迁移过程变得可预测、可重复，并且更不易出错。
- 可扩展性与灵活性——该架构支持多个订阅和着陆区：工作负载可以部署在独立的订阅/环境中（例如开发/测试/生产），同时都能继承共享的基线。
- 内置的安全性、合规性与治理——通过共享的身份管理、网络拓扑、监控（例如日志分析）和政策强制执行，该基础帮助您从一开始就满足企业治理要求。
- 简化的迁移规划——由于Azure Migrate支持广泛的工作负载（服务器、数据库、Web应用等），它成为了您评估准备情况、估算成本和编排迁移的一站式中心。
在迁移前您需要了解的事项
当然，即使有了这些工具，迁移也并非完全无需人工干预。有几个重要的考虑因素：
- 工作负载准备情况至关重要：在迁移前，您需要评估工作负载是否具备云就绪条件。这包括了解依赖关系、兼容性以及可能需要的重构或配置更改。
- 可能需要混合连接：如果您拥有本地数据中心或遗留基础设施，则需要在部署着陆区后配置混合连接（VPN、ExpressRoute等），以确保工作负载保持可访问性和合规性。
- 组织协调是关键：平台团队和工作负载/应用团队需要协调：平台团队管理共享服务和治理；应用团队部署和运营其工作负载——通常位于基于订阅的“应用着陆区”之下。
最终思考——自信地进行现代化改造
迁移不一定是高风险或繁琐的过程。通过采用Azure Migrate与精心设计的Azure着陆区相结合的引导式“智能”迁移，您的上云之旅将不仅仅是简单的“直接迁移”，而将成为迈向安全、合规、治理和长期运营规模化的关键一步。
如果您正在为您的组织评估迁移：请将着陆区部署视为基础架构，而不是一次性项目。一旦部署完成，它将支持未来的工作负载，简化增长过程，并为云原生演进奠定基础。