执行迁移到云

本文提供用于执行成功迁移到 Azure 的结构化指南。 本指南涵盖近乎零的停机时间和计划内停机时间方法，以满足不同的业务需求。

为迁移准备相关方

利益干系人准备可确保在迁移过程中协调执行和快速解决问题。 清晰的沟通和资源分配可减少业务中断并提高迁移成功率。 在开始迁移活动之前，应建立通信协议并确认支持可用性。

1. 向所有利益干系人分发详细的迁移计划。 全面的计划使整个组织更加清晰和一致。 创建并分发一个文档，该文档指定迁移时间、预期服务影响、责任和应变计划。 包括迁移团队和支持资源的联系信息。 此准备可防止误解，并减少迁移时段内的业务中断。

2. 在整个迁移时段内确认技术支持可用性。 专用技术资源可立即响应迁移期间出现的问题。 安排在整个迁移期间内具有相关专业知识且随时待命的特定技术人员。 建立明确的升级路径，满足关键问题的响应时间预期。 此支持结构可减少可能影响迁移成功或业务运营的问题的解决时间。

3. 对所有支持团队进行迁移前准备情况评审。 就绪情况评审确认所有团队都了解其角色并具有必要的访问权限。 与每个支持团队的代表举行会议，查看迁移计划、验证过程和回滚条件。 验证支持团队是否配置了适当的系统访问和监视工具。 此准备可确保协调响应迁移过程中出现的任何问题。

实施变更冻结

更改冻结可防止可能会中断迁移成功的修改。 系统稳定性可降低迁移风险并确保数据一致性。 应实现控制措施，以防止在迁移时段期间更改源系统。

1. 在部署管道中实现自动更改控制。 自动控制可防止对生产系统进行未经授权的更改。 配置部署管道，在冻结窗口期间阻止发布到源环境。 在 CI/CD 工具中添加审批入口，以强制实施冻结期。 这些控制措施可防止意外部署可能会影响结果。

2. 记录紧急更改过程。 紧急程序允许进行关键修复，同时保持稳定性。 为紧急更改创建特定条件，并定义加速审批过程。 包括审批者的联系信息，并记录所需测试。 这些过程平衡了系统稳定性和业务连续性要求。

3. 监视未经授权的更改。 变更检测机制可确保冻结期内的合规性。 为文件修改、数据库架构更改和应用程序部署配置警报。 使用配置管理工具跟踪系统状态。 此监视可防止未经记录的更改影响成功。

完善生产环境

生产环境准备可确保迁移工作负载的一致性、安全性和作就绪性。 此准备可减少配置偏差，并为工作负荷提供经过验证的基础。 应使用基础结构即代码模板创建生产资源，并应用生产级配置。

1. 使用基础结构即代码模板创建生产资源。 基础结构即代码可确保跨环境进行一致的可重复部署。 此方法可减少配置错误，并为基础结构更改提供版本控制。 使用 Azure 资源管理器模板、Bicep 或 Terraform 部署具有标准化配置的资源。

2. 将生产级配置应用到 Azure 资源。 生产配置建立安全、性能和符合性基线，以保护工作负荷并满足组织要求。 使用限制性规则配置网络安全组，这些规则仅允许服务之间的必要流量。 应用防火墙规则，在启用所需的通信路径时阻止未经授权的访问。 设置遵循最低特权原则的标识和访问控制。 使用正确的版本在 Azure 中预配数据库，并配置复制所需的用户帐户、角色和权限。 配置网络访问控制和防火墙规则来保护数据库连接。 这些配置为迁移的工作负荷创建安全基础。

3. 验证所有服务是否都正常运行。 服务验证可确保 Azure 基础结构能够支持迁移的工作负荷。 此验证在影响迁移过程之前会识别潜在问题。 检查服务运行状况、资源创建完成情况和特定服务的运行状况检查。

4. 确认已建立网络连接。 网络连接验证可确保所有必需的通信路径都正常运行。 此验证可防止中断迁移或应用程序功能的连接问题。 测试所有必需服务之间的网络连接，并验证关键终结点的 DNS 解析。

执行直接转换

迁移执行会将工作负荷数据和作从源环境传输到 Azure。 以下步骤提供了一种标准化方法，优先接近零的停机时间，同时满足可以容忍计划内停机时间的情况。 应根据具体的停机时间要求和工作负荷特征来调整这些步骤。 请参阅 数据迁移工具。

执行近零宕机迁移

1. 建立数据库复制机制。 配置数据库平台的本机复制功能，以在源系统和 Azure 目标系统之间建立连续数据复制。 验证初始数据同步是否成功完成，并且复制是否正常。

2. 监视复制滞后时间。 使用数据库平台的监视工具监视复制中的滞后时间。 更高的延迟会增加系统切换的风险和时间长度。 在复制滞后时间为零之前，不要继续执行下一步。

3. 在稳定复制期间迁移非结构化数据和文件。 在最终直接转换之前，将非结构化数据和文件复制到 Azure。 使用 工具进行对象和文件迁移 ，通过功能将文件传输到相应的 Azure 存储服务。 此准备减少了在最终切换期间需要复制的数据量。

4. 在最终同步窗口中暂停写入作。 与应用程序团队协调，在预先确定的维护时段内停止写入作或启用只读模式。 此步骤可防止在最终切换阶段出现数据不一致。 在低流量期间计划此暂停，并将时间线传达给所有利益干系人。 如果不暂停写入作，会增加数据丢失的风险。

5. 完成最终数据同步。 使用 AzCopy 或类似工具暂停写入后，完成修改的任何数据的最终同步。 确认源系统无待处理事务，且数据库复制完全完成。

6. 验证数据完整性和工作负荷功能。 可以通过比较数据库行数快速检查，但更深入的验证建议使用校验和和哈希函数。 对于文件系统，请使用 MD5 哈希函数并验证文件计数、大小和时间戳。 验证关键工作负荷功能，包括身份验证和核心事务。

7. 将流量定向到新的 Azure 工作负荷。 更新 DNS 记录和负载均衡器配置，以将用户流量定向到 Azure 环境。 监视工作负荷运行状况和性能。

8. 进行全面的割接后验证和监控。 使用自动化测试套件对所有关键业务流程执行端到端功能测试。 使用校验和和哈希函数比较源与目标系统的数据准确性。 让应用程序所有者确认所有主要功能都正常运行。 监视直接转换后的前 24-48 小时内的系统性能、错误率和用户访问模式，以确定性能下降或功能问题。

在停机的情况下执行迁移

1. 停止向源系统的所有写操作。 此步骤可确保迁移期间不会发生任何新事务。 确认所有事务都已完成，并且在继续之前确保用户已被禁止访问。

2. 将所有数据迁移到 Azure。 将数据库、文件和对象存储复制到 Azure。 根据数据类型和卷使用 Azure Migrate、AzCopy 或 Azure 数据库迁移服务（DMS）等工具。 请参阅 数据迁移工具。

3. 在迁移后验证数据完整性。 执行校验和、行计数以及元数据比较，以确保数据的准确性。 使用可用于减少手动工作量并提高可靠性的自动化工具。

4. 在 Azure 环境中测试应用程序。 运行端到端测试，确认应用程序使用迁移的数据正常运行。 包括报告、集成和备份验证。

5. 将流量定向到新的 Azure 工作负荷。 将 DNS、负载均衡器和应用程序配置更新为指向 Azure。 监视连接问题并确认成功重定向。

6. 切换后验证工作负载功能是否正常。 执行最终检查以确保应用程序稳定且数据准确。 让应用程序所有者验证业务关键功能。

保留回退选项

将源环境保留为回退选项。 如果发生无法在可接受时间范围内解决的关键问题，源环境保留机制可以实现快速恢复。 此回退选项在稳定期间提供业务连续性保险。 使源环境保持可用状态，并根据需要还原 DNS 记录并还原以前的配置。

验证迁移成功

迁移后验证可确保工作负荷正常运行并满足所有要求。 此验证确认数据完整性得到维护，并且迁移成功。 在声明迁移完成之前，应进行全面的验证。

1. 确认用户成功访问和系统性能正常。 用户访问验证可确保过渡到 Azure 是透明的，并且性能符合预期。 此确认会验证用户是否可以在不中断的情况下访问系统。 在迁移后的初始期间监视用户访问模式、系统性能指标和错误率。

2. 仅在彻底验证后才宣布迁移成功。 完整验证可确保所有利益干系人确认工作负荷稳定且功能正常。 此确认可防止过早地声明成功，这可能会导致以后出现问题。 获取应用程序所有者、测试人员和业务利益干系人确认工作负载满足所有要求并正常运行。

在稳定期间支持工作负荷

增强的支持覆盖范围可确保在关键稳定期快速响应迁移后问题。 此支持可更快地解决迁移后常见的问题。 应建立专用支持模型并更新作文档。

1. 在稳定期间建立增强的支持覆盖率。 专用支持模型可确保在关键稳定期快速响应迁移后问题。 此支持可更快地解决迁移后常见的问题。 分配经验丰富的 IT 人员或迁移合作伙伴以密切监视工作负荷，并提供比正常作更短的 SLA。

2. 更新配置管理和清单系统。 配置管理更新可确保作工具和流程反映新的 Azure 环境。 此维护使作文档保持最新状态，并支持正在进行的管理活动。 为新的托管环境更新配置管理数据库（CMDB），假设现有清单工具会自动更新 IP 地址、CPU、内存和其他基础结构详细信息。

Azure 工具和资源

后续步骤