在 SAP HANA Cloud Central 里进入Migrations，创建一个新的迁移任务时，真正需要回答的并不是一个简单的技术问题，能不能把数据库搬到云上，而是另一个更实际的问题，源端到底属于哪一种 SAP HANA，工具允许搬到什么粒度，哪些对象会跟着过去，哪些内容必须留给应用改造，目标端又有哪些基础设施约束。这几个问题如果没有在项目早期弄清楚，很容易出现一种情况，团队已经把目标 SAP HANA Cloud 实例建好了，也配置好了 SAP Cloud Connector，甚至已经准备停机窗口，到了 compatibility check 才发现源系统中的某批对象根本不属于 Self-Service Migration 的自动迁移范围。SAP 当前对这一点划得很清楚。Self-Service Migration for SAP HANA Cloud 并不是一个可以接收任意 SAP HANA 数据库、任意版本、任意开发模型的通用搬家工具。目前官方明确列出的主要源端包括 SAP BTP Cloud Foundry 环境中的 SAP HANA Service、SAP BTP Neo 环境中的 SAP HANA Service，以及本地部署或者托管环境中的 SAP HANA Platform。不同源端能够使用的迁移能力并不完全相同。还有一个现在做项目时很容易忽视的入口差异。SAP 推荐使用 multi-environment SAP HANA Cloud Central 中提供的 migration service，而不是继续把 Cloud Foundry 环境中的旧版迁移入口当作默认选择。官方给出的理由很直接，multi-environment 中的 migration servi