很多 SAP HANA 迁移项目真正进入实施阶段后，团队很快会碰到一个和最初预期完全不同的问题。数据库能够连接，表也能够导出，数据量看起来并没有大到无法处理，可项目依然很难按照传统数据库迁移的方式一路推进。原因并不神秘，真正消耗时间的部分往往不是把若干 TB 的数据从源端复制到目标端，而是原有系统里大量默认成立的设计前提，到了 SAP HANA Cloud 环境中已经不再适合继续沿用。
这种现象在从 SAP HANA Platform On-Premise、SAP HANA Service，尤其是早期 XS Classic 或 XS Advanced 架构迁往 SAP HANA Cloud 时格外明显。
原来的系统里，认证可能直接依赖数据库用户，权限可能长期靠人工GRANT维护，业务对象可能全部堆在几个固定 Schema 中，应用代码直接写死 Schema 名称，XSJS 与数据库运行在非常接近的运行环境里，多个应用共享数据库对象也没有明显的工程边界。这样的系统运行多年以后，很多设计已经从明确的架构决策变成了一种历史惯性。
到了 SAP HANA Cloud，这些惯性必须重新审视。
因此，所谓 Common Areas for Re-design During Migration，更合适的理解并不是迁移时有哪些对象需要修改，而是迁移过程中有哪些原来的系统边界需要重新划定。
这两个理解之间差别很大。
如果我们的目标只是对象搬迁，那么迁移工作看起来像Table A从源数据库复制到目标数据库，View B在新环境重新创建，用户与权限重新赋值，应用连接串改成新的 Host 与 Port。
