释放工作负载
在此阶段，将工作负载释放到生产环境中。
已将资源部署到 Azure。 现在需要完成迁移步骤，将即将进行的更改传达给其他团队，进行最终更改审批，清理资源，然后进行回顾。
传达更改
通知组织即将执行哪些更改，以确保每个可能受到迁移影响的人都知道该过程。 传达每个工作负载的更改，因为每个工作负载都有专门的用户和操作员。
应在更改通信中回答以下问题：
迁移的关键日期是哪些？
谁的工作会受到干扰、何时受到干扰、持续多长时间？
为了做好准备，每个角色在更改之前应该完成哪些工作？
更改后，每个角色应完成哪些工作来确认功能？
如果个人有疑问或遇到挑战，应该联系谁？
执行业务测试
工作负载的业务用户应该测试新解决方案。 迁移团队可以推动开展工作负载测试、制定测试计划并实现测试自动化。
要测试工作负载，请确定可能受更改影响最大的用户。 向这些用户告知业务目标、所需结果以及业务流程的预期更改。 获取来自用户的反馈，并确保 IT 人员理解反馈并根据反馈内容的影响确定优先顺序。 如果根据反馈，需要对工作负载进行更改，请向所有必要的团队传达更改。
在反馈阶段，迁移团队会收集反馈并管理由此产生的技术行动。 创建测试计划来追踪反馈和操作步骤。
完成迁移
将资产及其所有依赖项提升到生产状态后，可以重新路由生产流量。 然后，本地资产就过时了，可以将其停用。
必须根据工作负载架构执行各种任务。
发送通信，告知各方你已开始升级。
验证所有暂存资源是否正常运行。
复制最近的数据。
执行复制后水化资源。 暂存任何其他组件，如负载均衡规则。
关闭源服务器，使其不会干扰迁移。
执行隔离测试。
更新网络组件，以便用户可以访问应用程序的新位置。
再次执行升级测试，确认工作负载是否按预期工作。
获取利益干系人的最终批准。
与必要的各方沟通，表明升级成功。
在迁移后优化成本
迁移后，根据实时数据优化工作负载，并解除已停用资产的授权。
关闭和解除资产授权时：
继续监视：监视计划停用的资产，以确保正确路由生产流量。 禁用的资产仍然可以使用存储、网络和其他基础设施资源。 如果将其重新打开，可能会出现意外的问题。 监控活动以确保资产不再被使用。
建立测试和中断时段：确定一个非活动测试时段来执行与用户执行的实际活动相匹配的测试用例。 在此时段期间，还可以禁用标记为已解除授权的资产。 计划维护时段，并向用户告知你的计划。
请考虑规定保留期：保留停用资产至少 30 天，作为数据的临时备份，以防在复制期间丢失任何数据。 组织的数据治理团队可能有其他要求，需要超过 30 天的保留期。
进行回顾
在迁移后回顾，探究哪些方面进展顺利，哪些方面可以改进，以及吸取的经验教训。 从团队的每个成员那里获取见解，以便将学到的经验应用到未来的迁移中。 确定要组织该过程的团队成员。 然后，选择一种方法来追踪和组织收集的想法。