分析适用于工具选择和迁移模型的决策标准
我们已经探讨了迁移方法选项和工具选项，接下来可以了解执行迁移到 Azure Database for PostgreSQL 灵活服务器时需要考虑的决策条件。 帮助我们做出选择的三个主要条件是：停机时间、源数据库位置和可自定义性。
停机时间
停机时间是迁移活动的一个关键方面，利益干系人可接受的停机时间有助于我们决定是执行脱机迁移活动还是联机迁移活动。
通常情况下，迁移活动都是提前规划好的，以确保为活动完成适当的变更控制和相关治理。 通过这种规划，可以与主要利益干系人进行沟通，了解系统可以脱机多长时间。 在这种情况下，建议了解不同选项所需的时间，以便确定估计的最短和最长停机时间。
确定执行应用程序切换所需的最短停机时间是关键。 归根结底，即使是联机（或最短停机时间）迁移活动，在这段时间里，系统也必须脱机。 应用程序的复杂性将决定这一时间范围。 对于一个相对简单的应用程序来说，这个过程可能是停止服务、更新配置文件，然后再重新启动。 在更复杂的环境中，如果存在多个服务器和应用程序层，这一过程可能需要更长的时间。
了解联机或脱机迁移活动所需的时间是与停机时间有关的下一个重要因素。 如果是脱机迁移，从源将数据提取、传输和加载到目标，以及随后进行验证和确认所需的时间就是停机时间。 此停机时间夹在关闭应用/工作负载所需时间和重新启动应用/工作负载所需时间之间。
如果是联机（最短停机时间）迁移，停机时间是应用程序关闭后，将最终更改从源同步到目标所需的时间。 在此停机时间之上，还需加上重新配置和启用应用程序/工作负载之前的验证和确认活动所需的时间。
获得这些信息后，我们可以研究迁移的技术要素，以帮助确定可行方式。
源数据库位置
要迁移的数据库的源位置也起着一定的作用，因为任何给定的配置都有可能受到约束。
本地或非 Azure 源
对于本地或非 Azure 位置的数据库，关键约束通常是源和目标之间的网络连接。 此处要考虑的三点是带宽、延迟和数据量。 了解这些要点后，我们可以做出合理的决定，确定哪种迁移类型是可行的。
如果我们需要迁移的数据量很大，而带宽相对较小，那么简单的转储和还原可能是行不通的。 如果我们有大量的数据和较大的带宽，那么问题就不大了。
同样，如果是要进行数据同步的联机迁移，那么延迟也是关键因素之一。 如果延迟很高，可能会对系统性能产生不利影响，因为同步过程需要很长时间才能完成。
如果是从其他云服务提供商迁移，还需考虑一个重要因素，即他们是否对数据流出量收费。 如果是这样，那么最大程度地减少传输数据的物理占用可能是一个需要考虑的因素。 在这种情况下，压缩技术对用于同步的转储或数据流非常重要。
其他基于 Azure 的服务
在某些情况下，你希望从其他基于 Azure 的服务迁移到 Azure Database for PostgreSQL 灵活服务器。 这些源数据库可以位于 Azure VM、容器或 Azure Database for PostgreSQL 单一服务器中。 如果是这样，那么就有一系列不同的考虑因素需要探索，但与此同时，也有一些机会可以从针对这些场景的 Azure 服务优化中获益。
可定制性
最后一个需要考虑的方面是需要或希望进行多少自定义。 这种考虑可能表现为需要修改源数据库结构以支持数据复制，或者这可能意味着通过脚本实现自动化的难易程度。
一个很好的例子是通过 pg_dump 和 pg_restore 自动完成数据库的脱机迁移，但同时包括转储文件的压缩和解压缩。
决策
我们已经经历了收集所有这些信息的过程，接下来可以与利益干系人合作，确定特定情况下的最佳方式。 在决定使用哪种方法和技术集时，不仅要与业务利益干系人合作，还要与技术利益干系人合作。 这种协作有助于避免出现以下情况：业务部门要求尽量缩短迁移停机时间，而技术团队却因人员配置、资源或技术约束而无法实现这一点。
关键的是要管理期望值，进行开诚布公的对话。 同样重要的是，要确保业务部门能够承担那些不属于数据库迁移技术团队职责范围的验证任务。 这种验证可能涉及数据一致性和验证检查以及用户体验测试。