你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
执行阶段是迁移过程中的最后阶段。 所有数据移动和迁移任务都在此阶段发生。 通常，可以通过多次执行来采用迭代方法，以确保捕获所有更改和更新。 此过程有助于实现更轻松的切换，并将数据丢失保持在最低水平。
执行阶段包括以下步骤：
- 初始迁移： 从大容量复制开始，使用最合适的推荐工具迁移初始数据集。
- 循环访问：你可能会发现需要修正的错误，并可能重新运行某些任务。 根据需要优化并发设置以提高速度和效率。
- 增量同步： 如果源数据是动态的，那么在初始数据植入或迁移过程中，预期会出现源数据更改。 在这种情况下，请运行增量同步来同步任何更改。 如果发生了许多更改，可以多次重复此步骤。 运行多个同步操作的目标是缩短最终切换所需的时间。 可以排除在此步骤中保持静态的非活动数据、存档数据或备份数据。
- 最终切换到 Azure：最后的切换步骤涉及使用位于目标地点的活动数据并停用源数据。 在计划最终切换窗口之前，请冻结对所有源的更改，安排足够的停机时间以运行最终增量同步，并验证是否在 Azure 中记录了所有最后时刻的更改。同时更新配置，使用户和应用程序现在指向 Azure 目标位置。
- 迁移后任务： 目标处于活动状态后，需要完成全面的数据验证，以确保已准备好所有适当的安全、监视和保护机制。 这些验证活动因目标服务和工作负载而异。
以下示例包括有关使用 Azure Blob 存储进行迁移后验证的最佳做法建议。
最佳做法
以下建议包含应在 Azure 迁移过程中遵循的最佳做法。 这些最佳做法是从我们与小型企业和企业级客户的经验中收集的，旨在成为 IT 专业人员的资源。
- 确保在从源迁移所有数据之前，Azure 中没有对目标数据集的并发或重叠更改。 目标和源内的意外更改可能会导致意外失败和数据丢失。
- 迁移应用程序工作负荷时，请勿单独迁移应用程序的数据和基础结构。 计划将应用程序及其非结构化数据一起移动-或至少在最接近的时间范围内。 使数据和应用程序基础结构在本地和 Azure 之间分离，可能会导致延迟，并导致应用程序故障和意外停机。 尽可能执行必要的概念证明测试来验证应用程序要求。
- 避免直接转换或“一次性直接转换”。 不要突然更换以前的系统而没有过渡期，而应在非高峰使用时段内规划切换，借此减少切换时的停机时间。 提前向利益干系人传达所需的任何只读时间段。
- 尽可能在并行流中迁移，以加速吞吐量。 确保源系统不会过载，并在必要时使用带宽限制以避免性能下降。
- 在开始完整运行之前，使用代表性数据示例执行示例迁移。 本练习可帮助识别潜在问题并验证迁移方法。
- 在整个执行阶段维护迁移日志，监视所有活动。 记录有关每个工作负荷传输的详细信息，包括开始时间、持续时间、遇到的问题及其解决方法。 这些详细信息有助于增强问责制以及未来的审核或事后分析。
- 最终直接转换后，将源数据保留为只读状态，以便作为后备方案。 只有在确信 Azure 副本已完整且正确后，才停用源数据。