有时，您进行迁移并非出于自愿，而是迫不得已。旧系统终将无法满足现代业务的需求，维护旧系统可能会成为一种风险，而不是一种资产。

以下是您可能需要进行数据库迁移的一些主要原因：

• 硬件服务终止：您的物理服务器已老化，且制造商不再支持该硬件或操作系统
• 性能瓶颈：您当前的数据库架构无法应对您的数据量或流量高峰，导致用户体验变慢
• 安全性和合规性：旧系统可能缺乏满足当今监管标准所需的现代安全功能、补丁或审核功能
• 供应商锁定：您受制于专有、昂贵或不灵活的许可，这限制了您的创新能力，也让您无法根据具体需求选择最佳工具
• 数据孤岛：您的数据被困在孤立的本地系统中，难以输入到现代分析或 AI 模型中，而这些正是您的团队保持竞争力所必需的

当现有架构无法再满足您的运营需求时，迁移是确保业务安全高效运行的必要举措。

在迁移数据库时，您可能会听到同构和异构这两个术语。了解两者的区别有助于您规划技术团队需要完成的工作量。

数据迁移有四种常见策略。如需深入探究并了解推荐的策略，请参阅云迁移策略。

• 重新托管：直接原样迁移。这是迁移数据的最简单方法，即将现有数据库的完整副本（通常与应用栈的其余部分一起）复制到另一个环境中。[同构]
• 更换平台：迁移并优化。此策略会复制数据库、应用和虚拟机，然后根据新的云环境对它们进行优化。这可能是异构迁移，例如从商业数据库迁移到与 PostgreSQL 兼容的数据库（如 AlloyDB）时。 [同构/异构]
• 重构：迁移并改进。重构云迁移策略涉及重新设计应用，使其符合云原生原则，这需要更改应用代码本身。[通常为异构]
• 重新构建。重新构建云迁移策略会完全为云重写架构和应用。根据您的应用，这可能比重构费用低。[通常为异构]

虽然您几乎可以在任何两个位置之间迁移数据库，但大多数迁移都是从本地迁移到云或从一个云迁移到另一个云。

公司迁移到云（或迁移到其他云服务提供商）的原因有很多：

• 加速应用开发
• 提升性能和可伸缩性
• 节约费用
• 安全
• 各种功能，特别是与 AI 相关的功能
• 传统许可数据库常见的本地资本支出 (CapEx) 向云服务常见的运营支出 (OpEx) 的转变

详细了解迁移到云的好处。

出于上述原因，许多组织正在将其本地工作负载迁移到云。与云到云迁移相比，从本地迁移需要注意额外事项。

迁移本地工作负载的常见策略是更换主机，也就是将整个工作负载复制到云。这样做可获享与云迁移相关的安全性、可靠性和成本效益。

不过，需要注意的是，此策略也会将任何现有的低效问题从本地架构转移到云基础设施，这可能会导致您无法享受云原生架构带来的更大成本节省和效率提升。您可能还会错过云在灾难恢复、分析集成、AI/机器学习服务以及合作伙伴产品市场等领域的丰富功能。

请务必在迁移过程中保持数据的安全性，特别是在不同类型的环境之间。确保最佳安全性的方法之一是使用可信的数据库迁移服务。

数据和数据库迁移可能很复杂。确保企业的数据、组织和职能无缝迁移到新架构至关重要。如果操作不当，可能会导致数据丢失、工作负载无法正常运行或安全问题。

一些最佳实践：

• 了解您的数据。请务必了解具体业务场景和应用的需求。
• 评估业务的发展方向。如需选择合适的架构和提供商，请务必考虑扩缩。
• 使用功能标志进行测试。使用功能标志，先向一小部分用户发布新数据库。这样，您就可以在全面发布之前安全地测试系统。
• 选择适合您情况的正确数据迁移策略。
• 严格遵循数据迁移方案，以确保最佳性能。

如需深入了解此过程，请参阅数据迁移的概念和原则以及设置和执行数据迁移过程。

虽然详细内容会因具体业务场景而异，但以下基本步骤有助于您成功完成迁移：

1. 确定您的所有数据当前所在的位置、格式以及迁移后的目标位置。您可能会发现不需要迁移所有数据，可以归档或删除旧数据。这也是标记迁移的任何潜在风险的关键时机。
2. 规划迁移策略。确定哪种迁移策略最适合，决定是否可以在工作时间内停机，并设置预算。
3. 执行迁移。您可能需要使用迁移服务来进行实施。
4. 在割接之前测试新系统。这使您能够识别任何未正常运行的工作负载并解决任何问题。您可能需要同时运行两个数据库，这就需要将数据从一个系统复制到另一个系统。只有在确认所有工作负载都在新数据库上按预期运行后，才能关闭旧系统。

迁移所经历的阶段数量取决于组织的现有设置和时间表。例如，只需一步即可完成从自行管理的本地部署到托管式云服务的迁移。或者，如果您有时间压力，则可以先迁移到自行管理的云端数据库，然后再改用全托管式解决方案。

理想情况下，数据库迁移不是您的公司经常执行的流程。为了充分利用迁移，请考虑以下几个关键问题：