真正开始做 SAP HANA Cloud 迁移评估时一个很容易踩进去的坑是拿着现有 SAP HANA 2.0 系统的功能清单逐项确认看到SQL 可以执行、Calculation View 还能打开、表数据能够复制便认为整个应用可以原样搬进云端。事情没有这么简单。一个运行多年的本地 SAP HANA 系统往往不只是一个数据库。数据库下面可能依赖操作系统文件目录数据库上面可能运行 XS Classic 或 XS Advanced应用又可能通过 XSJS、XSODATA、Repository、HANA CDS 访问数据运维团队可能依赖 SAP HANA Studio、Host Agent、特定ALTER SYSTEM命令、SYSTEM 用户以及一些系统监控视图。单独看其中任何一项都不算复杂但它们组合在一起就形成了一套带有明显 SAP HANA Platform 时代特征的技术栈。SAP 官方的High Level Feature Compatibility正是用来帮助识别这种迁移风险。官方明确说明这个页面列出的并不是完整的兼容性参考而是一份高层筛查清单。如果现有解决方案使用了其中的功能那么迁移到 SAP HANA Cloud 时需要修改或者增强解决方案使它只依赖 SAP HANA Cloud 支持的能力。很多差异还会进一步影响 SQL、SQLScript、系统视图以及监控视图。这里有一个非常重要的阅读方法。所谓 Feature Compatibility不应该简单理解成某个名词今天存在还是不存在。真正需要判断的是原有的实现方式、API、SQL 语法、设计期对象、运行时组件以及运维权限能不能按照原来的方式继续工作。这个区别到了 2026 年尤其重要。SAP 官方高层兼容性页面至今仍保留诸如Scale-out最初不可用、NSE Advisor不可用、Text Analysis不可用之类的迁移时代描述但当前 SAP HANA Cloud QRC 2/2026 管理文档已经明确讨论 SAP HANA scale-out 环境中的 Table PlacementQRC 1/2026 文档也已经提供 SAP HANA Cloud Central 中的 NSE Advisor。当前 PAL 文档甚至已经提供新的 NLP 能力包括 Text Analysis、NER、Sentiment Analysis、POS、Text Embedding 和 ANN Search。所以这份清单真正传达的不是一句静态判断而是一种迁移原则。我们不能因为现在 SAP HANA Cloud 出现了一个同名能力就认为旧系统中的相关对象可以直接迁移。也不能因为高层兼容性页面列出了某项旧功能就断言今天的 SAP HANA Cloud 完全没有任何能够解决相同业务问题的能力。迁移工程真正关心的是兼容路径。从系统管理开始SAP HANA Cloud 已经不是一台交给数据库团队管理的 HANA 主机本地 SAP HANA 很容易形成一种思维习惯我们拥有数据库也在相当程度上拥有数据库下面的主机。于是数据库管理员会接触 Linux会检查文件系统会观察磁盘会查看主机目录会操作安装和升级工具会关注 SAP Host Agent还可能通过操作系统层面的脚本完成备份辅助、文件交换、监控和定时任务。到了 SAP HANA Cloud这条边界被重新划定了。SAP 官方当前管理文档把 SAP HANA Cloud 描述为 cloud-native relational database service同时明确说明底层基础设施、数据库软件更新以及自动备份由 SAP 管理。客户侧工作的重点转向数据库配置、数据建模以及用户管理。这就是为什么高层兼容性清单把 Direct access at the OS level 和 Direct access to the local file system 放在非常靠前的位置。如果本地应用曾经写过一个存储过程通过文件系统导出数据再由操作系统脚本把文件移动到另一个目录这种设计进入 SAP HANA Cloud 后就不能继续建立在直接访问数据库服务器文件系统的前提上。类似的问题还会出现在 SAP Host Agent、Volume IO statistics、Embedded Statistics Server 的 Email notification、Life Cycle Management、Ability to disable logging 以及一部分ALTER SYSTEM操作上。这些东西乍看属于运维细节迁移时却经常会向上影响应用。例如应用团队可能有一个自建运维平台后台执行若干ALTER SYSTEM命令控制 HANA 行为同时读取特定系统监控视图获得磁盘或者 Volume 层指标。在本地系统里这套方案已经运行多年大家甚至不会把它当成应用的一部分。迁移 SAP HANA Cloud 时一旦底层管理权限发生变化这套运维程序实际上也属于必须纳入兼容性分析的代码资产。SAP 对这种变化给出的解释很直接SAP HANA Cloud 是 managed service因此很多系统和数据库配置参数不再开放给客户修改相应的一部分ALTER SYSTEM命令也不再提供。这并不是 SAP HANA 数据库能力简单减少了而是责任边界发生了变化。在本地部署模式中我们维护操作系统、数据库软件、主机拓扑以及大量生命周期操作。在 SAP HANA Cloud 中SAP 接管其中相当一部分职责我们管理的是一个数据库服务而不是一组可以任意登录和修改的 HANA 主机。MDC 也属于同样的问题。本地 SAP HANA 熟悉的是 Multitenant Database Containers可以有 System Database再管理多个 Tenant Database。SAP HANA Cloud 采用不同的服务模型官方开发文档明确说明一个 SAP HANA Cloud database instance 对应一个单独的 SAP HANA database。如果需要多个数据库需要创建多个 SAP HANA Cloud database instances。所以迁移时不能简单把原来的 MDC topology 搬过来。真正应该迁移的是数据库边界背后的业务隔离关系。原系统为什么存在多个 Tenant是为了开发测试隔离是为了不同业务部门是为了不同应用生命周期还是因为历史部署结构。到了 SAP HANA Cloud这些需求可能会映射成不同 instance、不同 HDI container、不同 schema、不同 BTP space甚至不同 subaccount。这类变化体现了 SAP HANA Cloud 迁移中非常重要的一条规律保留需求重新选择云端实现而不是保留旧实现本身。SYSTEM、DBADMIN 和权限模型的变化比用户名变化深得多从安全角度看高层兼容性清单中最醒目的变化之一是不能再按照本地 SAP HANA 的习惯登录 SYSTEM。SAP HANA Cloud 中仍然存在 SYSTEM 这个内部数据库用户但它保留给 SAP 使用。客户侧的初始管理用户变成 DBADMIN。SAP 当前文档明确指出SYSTEM 是 SAP 保留用户相应的客户管理用户是 DBADMIN。如果只看到这里很容易认为迁移操作就是把连接字符串里的 SYSTEM 改成 DBADMIN。实际远远不够。SAP 官方迁移文档明确说明迁移过程中 SYSTEM 用户拥有的数据库对象以及位于 SYSTEM schema 中的对象可能被删除因此迁移之前必须把这些对象移动到其他 schema并修改对象 ownership。由 SYSTEM 创建的数据库对象也需要把所有者改成既不是 SYSTEM 也不是 DBADMIN 的适当用户。这是一条非常现实的迁移检查项。很多运行十年以上的 HANA 环境都可能存在历史管理习惯早期项目实施人员直接使用 SYSTEM 创建 schema、table、procedure 或 view系统能运行业务也没有立即受到影响于是这种历史债务一直存在。到了 SAP HANA Cloud migration这些对象的 owner suddenly 变成真正需要处理的问题。更深的一层变化来自权限治理。SAP HANA Cloud 不鼓励把 DBADMIN 当成日常管理员使用。官方安全指南推荐使用 DBADMIN 创建专门的数据库管理用户按照职责授予最小权限随后在生产环境停用 DBADMIN。QRC 2/2026 的安全指南甚至把停用 DBADMIN 放进 Essential Security Tasks。因此迁移并不是 SYSTEM 变 DBADMIN而是从一个传统 superuser 思维逐渐转向 delegated administration、user group、role group 和 least privilege。类似变化也会落到USER ADMIN之类的系统权限。SAP HANA Cloud Migration Guide 明确说明传统USER ADMINprivilege 默认不可用用户管理更多转向USERGROUP OPERATOR等机制。迁移已有用户时没有 user group 的用户会进入 DEFAULT user group由相应 operator 管理。如果现有程序中存在自动创建用户、授权角色、回收权限的 SQL这部分代码就不能只验证语法是否还能执行而要重新审查整个权限模型。高层兼容性清单中同时列出了 Client-side encryption 不可直接沿用也提醒我们安全迁移不能采用逐个 feature 打勾的方式。身份认证、授权、加密、网络访问以及审计应当作为一套新的 cloud security architecture 重新审视。数据处理差异里最危险的误区是看到同类能力就认为兼容数据处理部分列出的内容很多包括 SAP HANA Dynamic Tiering、External Machine Learning Library、Smart Data Quality、Hive integration、Text Analysis、Text Mining、Result Views、Metamodel Optimization、R Integration、Calculation View anonymization 和 Capture and Replay。如果直接读名单很容易产生一种印象SAP HANA Cloud 在这些领域能力不足。实际情况更细。拿 Dynamic Tiering 来看本地 SAP HANA 曾经可以通过 extended storage 把冷数据放到扩展存储中SQL Reference 的迁移兼容文档明确说明ALTER EXTENDED STORAGE和与 Dynamic Tiering 有关的一部分 SQL 在 SAP HANA Cloud 中不再支持。但今天解决冷热数据问题并不一定继续采用 Dynamic Tiering。SAP HANA Cloud 本身已经围绕内存、Native Storage Extension、Data Lake 等形成新的分层存储架构。迁移设计关注的应当是哪些数据必须保持热数据状态哪些数据可以 page-loadable哪些历史数据适合放到更低成本的数据层而不是怎样重新创建旧系统的 Extended Table。NSE Advisor 正好体现了兼容性名单不能机械阅读。高层页面仍然把 NSE Advisor 放在早期不兼容列表里而当前 SAP HANA Cloud Central 已经能够启用 Native Storage Extension Advisor根据访问频率分析 table、partition 和 column并给出 page-loadable 或 column-loadable 建议。所以迁移时真正应该问的是原系统有没有依赖旧版本 NSE Advisor 的 procedure、system view 或自动化脚本。即使今天存在新的 NSE Advisor旧程序也不会因为名字相同就自动获得兼容性。Text Analysis 的情况更有代表性。迁移兼容文档明确列出传统 TEXT、BINTEXT、SHORTTEXT 类型以及旧式 FULLTEXT index、TA_ANALYZE 和一批 Text Mining procedure 的变化。旧 HANA 应用如果直接调用这些 SQL 或 procedure需要改造。与此同时2026 年的 SAP HANA Cloud PAL 已经出现新的 NLP 能力Text Analysis 可以进行 Named Entity Recognition、Sentiment Analysis 和 Part Of SpeechText Embedding 可以把文档转换成向量并结合 Approximate Nearest Neighbor Search 完成语义检索。从迁移工程角度看这里不是简单的支持或者不支持而是技术代际变化。旧系统可能通过 Full Text Index 加 Text Mining Procedure 做文档分类新系统可能采用 PAL NLP、Embedding Vector 和 ANN Search。业务需求依旧是理解文本但数据库对象、API、数据结构和算法路径已经变化。Capture and Replay 则更加直接。SAP 当前 Migration Guide 明确说明该功能在 SAP HANA Cloud 中不可用与 capture and replay 相关的 built-in procedures 被禁用M_WORKLOAD_CAPTURES、M_WORKLOAD_REPLAYS等相关信息只能用于迁移检查。如果原来的性能验证流程依靠 Capture and Replay 把生产 workload 捕获后放到测试系统重放那么迁移项目必须重新设计性能基准测试方式不能期待把原流程原封不动搬过去。表和数据库对象看起来最接近实际也存在大量设计期差异Data Definition 部分列出的差异包括 Full Text Indexing、Data Type Creation、Geocode Indexes、Flexible Tables、History Tables、BO Explorer SQL Extensions、Non-unique Inverted Hash Index 和 Time Series Tables。这部分很容易被忽略因为迁移团队通常先关心数据能不能搬过去。实际上表数据能够迁移与表定义能够按照原语义长期维护是两个层面。SAP Self-Service Migration 工具当前已经支持从本地 SAP HANA 迁移数据库也允许按照 schema 或 XS Advanced service instance 进行选择性迁移。官方文档同时指出Dynamic Tiering Table、Flexible Table、Full Text Index Table、Geocode Index Table、History Table 等特殊表类型只能在 offline phase 迁移。看到这里不能得出这些旧对象在目标端全部保持原样的结论。迁移工具能够处理某种源对象只能说明迁移流程认识这种源对象。目标端真正生成什么结构、哪些语义需要转换仍然需要结合 Compatibility Guide 和迁移结果验证。Time Series Tables 是很典型的例子。High Level Feature Compatibility 明确说明传统 Time Series Tables 不可用但相关 SQL functions 仍然存在。也就是说时间序列计算能力与一种专用表类型被拆开了。对于应用架构而言这种改变反而提醒我们不要把业务模型和物理存储类型锁得过紧。订单趋势、设备遥测、库存变化、价格曲线仍然属于时间序列业务但没有必要因为原系统使用 SERIES TABLE就要求目标系统必须继续存在完全相同的 table type。Calculation View anonymization 也体现出类似思路。旧实现中基于 CalcViews 的匿名化方式不再作为迁移目标而官方高层清单指出可以使用 native SQL views 支持对应能力。兼容性分析因此要从 object name 上升到 intent。原对象为什么存在它承担的是性能优化、业务语义、权限隔离、隐私保护还是数据生命周期管理。确定目的后再选择 SAP HANA Cloud 中能够长期维护的实现。应用开发层才是很多 HANA 原生应用迁移成本最大的地方如果现有系统只是通过 JDBC 或 ODBC 把 SAP HANA 当数据库使用迁移难度通常相对可控。一旦系统大量使用 SAP HANA XS情况完全不同。High Level Feature Compatibility 明确把 SAP HANA XS Advanced 和 SAP HANA XS Classic 列入不直接提供的能力范围其中牵涉 native OData services、built-in Job Scheduler、Message Service 以及 XS 自己的 identity、authentication 和 authorization services。这说明 SAP HANA Cloud 不再沿用数据库内部同时承载完整应用服务器的老路线。SAP 当前官方迁移方向已经非常清晰XS Advanced 应用向 SAP Cloud Application Programming Model也就是 CAP 迁移数据库继续使用 SAP HANA Cloud而应用 runtime 放在 SAP BTP Cloud Foundry 等运行环境中。SAP 官方已经提供专门的 XS Advanced to CAP migration guide并在 SAP Business Application Studio 中提供 SAP HANA Application Migration Assistant。这是整份兼容性文档里对架构影响最大的一组变化。一个传统 XS Classic 项目可能同时包含.xsjs、.xsodata、.xsjob、.xsaccess、Repository Calculation View 和数据库 procedure。在原来的世界里数据库与应用 runtime 紧密地绑在一起。迁移到 SAP HANA Cloud 后这些职责会重新分层。数据库层负责 table、view、procedure、Calculation View、HDI artifact 等数据库能力。服务层可以使用 CAP 暴露 OData 或其他 API。定时执行任务不再依赖数据库内建 XS Job Scheduler而应进入云端相应调度体系。Authentication 与 Authorization 也会进入 SAP BTP 的身份和安全体系。SAP 官方针对 XS Advanced migration 明确说明XSODATA 和 XSJS service 必须转换为 SAP CAP 支持的形式原来的 UI 如果采用 SAP Fiori 或 SAPUI5则很多情况下可以继续复用。这个细节很有实际价值。迁移不是推倒所有代码重写。一个现实的迁移项目完全可能保留 SAPUI5 前端保留相当一部分 SQLScript procedure 和 Calculation View把数据库 artifact 转换到 HDI把 XSJS service 改写成 CAP service再重新处理认证、授权、destination 和 service binding。改变最大的是应用平台边界而不是每一行业务逻辑。SAP HANA Repository 和传统 SAP HANA CDS 也属于这一代际变化。SAP HANA Cloud 当前仍然有强大的 HDI但传统.hdbcdsartifact 已经被列入 SAP HANA Cloud 不支持的 HDI content type。当前 HDI 的定位是把数据库设计期 artifact 部署进受隔离的 container。这与早期_SYS_REPO、Repository package 和激活式开发模型已经不是一套东西。如果一个老项目大量使用 HANA Repository、Attribute View、Analytic View 以及旧 Calculation View那么真正合理的迁移方向通常是把分析模型收敛到现代 Calculation View 和 HDI而不是设法在 SAP HANA Cloud 中重新建立旧 Repository 世界。MDX 也被列入高层不兼容项。对于依赖 multidimensional consumer 的旧应用迁移评估必须追到 BI 工具和消费协议这一层不能只检查数据库 artifact。SAP HANA Studio 的退出背后是完整工具链的迁移Tooling 部分只有几个名字却很容易低估影响。SAP HANA Studio 和 Enterprise Architect Designer 不属于 SAP HANA Cloud 的目标工具链。过去很多 HANA 开发和管理人员一天的大部分工作都发生在 HANA Studio 中建 schema、看 catalog、写 SQL、创建用户、查看 trace、分析性能、编辑 Repository 内容全塞在一个 Eclipse 客户端里。SAP HANA Cloud 把这些工作拆到了不同工具。SAP HANA Cloud Central 负责 instance 层面的生命周期和配置管理SAP HANA cockpit 负责数据库管理和监控SAP HANA Database Explorer 用于 SQL、catalog object 和数据浏览SAP Business Application Studio 负责现代应用和数据库开发。SAP 官方当前开发文档明确指出可以使用 SAP HANA cockpit 管理 SAP HANA Cloud database使用 Database Explorer 查询数据库和浏览 catalog同时 SAP Business Application Studio 提供 SAP HANA Cloud 应用开发所需的 Dev Space、Git、terminal、build tools 和 runtime。因此迁移工具链时不能只是培训团队去找 HANA Studio 某个菜单在新工具里的位置。开发方式已经发生变化。Repository package 时代习惯在服务器里直接维护设计期对象HDI 时代更加接近 source code、Git、build、deploy 的工程流程。数据库 artifact 成为项目文件应用通过 HDI container 获得隔离后的数据库资源跨 container 或访问 container 外对象时通常通过 synonym 和 grant configuration 明确建立依赖。这正是 Cloud Native 数据库开发比传统 HANA native development 更强调 DevOps 和可重复部署的地方。最后那几项平台扩展更适合从业务能力重新映射High Level Feature Compatibility 最后一组还列出了 SAP HANA Accelerator for ASE、SAP HANA Data Warehousing Foundation 和 SAP HANA Streaming Analytics。迁移这里时很容易继续沿用产品名映射产品名的思路。实际更合理的做法是把原平台 extension 拆成能力需求。使用 Streaming Analytics 的原因究竟是实时事件接入、流式计算、CEP、IoT processing还是只是希望快速摄取数据。使用 Data Warehousing Foundation 的原因是数据分层、生命周期管理、数据分布优化还是 warehouse orchestration。只有先回答这些问题才能正确判断 SAP HANA Cloud、SAP Datasphere、SAP BTP integration services、event infrastructure 或其他 SAP 服务如何重新组合。这一思路和前面的 Dynamic Tiering、XS、Repository 完全一致。SAP HANA Cloud 迁移不是产品名称替换工程而是 architecture capability mapping。一份真正有用的兼容性评估应该追到代码和对象层实际迁移项目中我更倾向于把High Level Feature Compatibility当成第一次扫描。扫描结束以后需要继续追踪 feature 对应的 SQL statement、procedure、system view、privilege、design-time artifact 和 runtime dependency。例如发现项目使用 SYSTEM就继续查 SYSTEM owner 和 SYSTEM schema。发现使用 XSJS就继续查.xsjs、XSODATA、xsengine API、session API、authentication 和 scheduler。发现使用 Dynamic Tiering就继续查 extended table、ALTER EXTENDED STORAGE以及数据温度设计。发现使用 Text Analysis就不能只搜索 Text Analysis 这两个词还应该检查 FULLTEXT INDEX、TEXT datatype、TA_ANALYZE、Text Mining procedure 以及 application code 中对旧结果结构的依赖。发现 HANA Studio只看客户端是否安装没有意义还要确认项目是否依赖 Repository、Attribute View、Analytic View、老 Calculation View editor 和 Eclipse plugin。SAP 自己的 Migration Guide 也是按照这个思路设计的。高层 Feature Compatibility 后面还专门提供 SQL 与 SQLScript compatibility、Design-time Content Compatibility、SYSTEM 与 DBADMIN、权限差异以及各项迁移说明。官方还提供 Self-Service Migration Tool 和 SAP HANA Application Migration Assistant用于数据库以及 XS application migration。这也是为什么一次可靠的 SAP HANA Cloud migration assessment 不应该只生成一张 supported 和 unsupported 表。更有价值的结果应当是一张 dependency map。某个业务功能依赖哪个 application componentcomponent 又依赖哪些 database objectsdatabase objects 使用哪些 SQL feature部署使用什么 design-time artifact运行时依赖哪种 service运维依赖哪些 privilege 和 monitoring view。有了这张图High Level Feature Compatibility 才真正发挥作用。High Level Feature Compatibility 真正划出的是 SAP HANA 两个时代之间的边界回到整份兼容性说明可以看到一个非常清晰的方向。SAP HANA Platform 更像一个功能极其丰富的数据库平台数据库、操作系统管理、应用 runtime、Repository、开发工具、监控和多种 platform extension 都紧密地聚集在 HANA 周围。SAP HANA Cloud 则把 SAP HANA 的核心数据库能力保留下来同时把基础设施管理交给云服务把应用 runtime 推向 SAP BTP把设计期对象推向 HDI把开发环境推向 SAP Business Application Studio把管理和监控推向 SAP HANA Cloud Central、SAP HANA cockpit 和 Database Explorer。官方当前文档已经明确SAP 负责 underlying infrastructure、database software updates 和 automated backups而开发人员通过 HDI、SAP Business Application Studio 以及 Cloud Foundry 等环境构建现代应用。因此那些 unavailable feature 并不是一堆互不相关的缺失功能。Direct OS Access、Host Agent、LCM 和 logging control 指向 managed service。SYSTEM privilege 和一部分 system privilege 的变化指向更严格的 cloud security boundary。Dynamic Tiering、旧 Text Analysis、R Integration 和 EML 的变化指向新的数据处理架构。History Table、Flexible Table、传统 Fulltext artifact 和 Time Series Table 的变化指向数据库对象模型的演进。XS Classic、XS Advanced、XSODATA、XSJS、Repository 和 HANA CDS 的变化指向应用运行时从 database-centric architecture 转向 SAP BTP application architecture。HANA Studio 的退出则把这种变化延伸到了开发和运维工作方式。从这个角度再读High Level Feature Compatibility它就不再是一份让人焦虑的功能删减名单而是一张迁移架构地图。真正成熟的迁移策略不是追求旧系统百分之百原样复制而是确认哪些业务能力必须保留哪些技术依赖已经过时哪些能力在 SAP HANA Cloud 中存在新的实现路径哪些对象需要转换哪些代码需要重构哪些运维责任已经由 SAP 接管。尤其是在 2026 年阅读这份文档时还需要额外保持一个版本意识。高层兼容性页面中仍然存在一些产品早期阶段的表述而当前 SAP HANA Cloud 已经具备 Scale-out 相关能力、NSE Advisor、新一代 NLP、Text Embedding、ANN Search、Active/Active read-enabled replicas 等持续演进的功能。因此最稳妥的判断标准始终是High Level Feature Compatibility 用来发现风险具体 Migration Guide 用来定位受影响的 artifact 和 SQL当前季度 SAP HANA Cloud Reference 与 Administration Guide 用来确认目标版本真正支持的能力。做到这一层所谓 HANA 到 HANA Cloud 的迁移才不再只是 database migration。它实际上是一场围绕运行边界、开发模型、权限治理、数据架构以及应用平台进行的现代化改造而High Level Feature Compatibility正是这场改造最适合拿来做第一轮技术体检的那张清单。