真正开始把一套运行多年的 SAP HANA 数据库迁移到 SAP HANA Cloud 时，最让项目团队头疼的往往不是如何把几百 GB 或几 TB 数据复制到云端，而是另一个更难回答的问题，我们现有数据库里的这些东西，到了 SAP HANA Cloud 以后到底还能不能继续工作。表能不能过去，SQL View 能不能过去，Stored Procedure 是否兼容，现有 SQLScript 是否需要修改，Calculation View 属于哪一种模型，HDI Container 能不能整体迁移，数据库用户和角色如何处理，原来的 Remote Source 会不会继续连接，LDAP、SSO、证书、INI 参数又应该怎么办。这些问题混在一起时，一次 SAP HANA Cloud 迁移很容易被误解成传统意义上的数据库 Copy。实际上它远不只是 Copy。SAP HANA Platform 与 SAP HANA Cloud 虽然拥有相同的技术血统，但两者并不是完全相同的产品形态。部分 SAP HANA 功能在 Cloud 中采用了不同实现，部分能力已经被新的云原生机制替代，也有部分传统功能并不存在于 SAP HANA Cloud。SAP 为这类问题提供了一项很关键的能力，Self-Service Migration for SAP HANA Cloud。它位于 SAP HANA Cloud Central 的迁移体系中，可以在真正执行迁移以前扫描源 SAP HANA 数据库，判断哪些数据库对象、SQL 语句和功能能够直接迁移，哪些存在兼容性问题，哪些需要重新设计。因此，我更愿意把 Self-Service Migration Tool 理解成迁移项目里的三种角色组合。它既是迁