（2019年1月更新）

是时候继续我们的故事了。欢迎回来！在本系列的第1部分和第2部分中，我们描述了访问sapbw/4HANA的不同路径，并提供了关于哪种路径对给定客户环境最有意义的一般性建议。在sapbw/4HANA的早期，我们不得不忽略"如何实际完成任务"的细节。我们投入了大量的脑力、设计会议和开发日，相信我们已经想出了一些非常酷的解决方案，帮助我们所有的SAP BW客户实现SAP BW/4HANA。这包括"追随者"谁没有接触他们的sapbw系统多年来运行在旧的磁盘和行为基础的数据库。

在这个博客中，我们将集中在"系统转换"的路径为单一sapbw系统。Net新的实现和几个sapbw系统的环境转换将在未来的博客中讨论。让我们深入了解如何将系统转换为sapbw/4HANA的细节。

构建sapbw/4HANA的主要重点是简化。在sapbw/4HANA中，前10种用于用sapbw建模数据仓库的对象类型中只有4种可用。如果你使用了6种过时的对象类型，比如InfoCubes，你会怎么做？作为第一个解决方案，我们提供了一个"数据流复制工具"，允许您设置第二个数据流，但只使用与sapbw/4HANA兼容的对象类型。换句话说，它将只使用高级数据存储对象来实现持久性，而使用CompositeProviders来实现要查询的虚拟层。但是，云上，这个工具有一些缺点：所有对象都有新名称，只创建了空shell。你还是得自己重新加载数据。显然，这只是一个暂时的解决办法。

我们已经把过渡进程提升到一个全新的水平。如果您参加过openSAP课程"使用sapbw/4HANA的现代数据仓库"，那么您已经听说了针对sapbw客户的两个新选项。如果没有，我强烈建议花几个小时来完成这门内容丰富的课程。第一种选择是所谓的"就地转换"，它主要面向拥有由SAP HANA系统支持的现有SAP BW的客户。第二种选择是"远程转换"，它对运行SAP-HANA以外的旧版本或数据库的sapbw客户最有吸引力。最近，我们添加了第三个选项，即所谓的"Shell转换"。下图提供了这些选项的概述和比较：

我们了解这些场景的复杂性，并正在采取全面的方法来覆盖端到端的过渡过程。为了使它尽可能简单明了，就地转换、远程转换和Shell转换都是基于任务列表框架的。这个框架允许我们定义和发布技术任务的序列，然后可以在客户系统中执行这些任务。例如，我们过去曾成功地将任务列表用于sapbw内务管理或复制后自动化。通用性、强大的监控功能以及定制和客户特定扩展的选项使其成为系统转换过程的最佳选择。

为了更好地理解转换过程，我们定义了一个高级计划和活动，我们建议按此顺序执行。这些步骤与SAP主动方法一致。在发现和准备阶段，检查一般系统需求，完成维护计划（以获得所需的堆栈.xml归档并下载软件包），检查原始sapbw系统，并执行自定义代码分析。在准备阶段结束时，您必须决定是采用就地、远程还是Shell转换路径。

就地转换从SAP HANA系统支持的SAP BW开始。最低版本是7.5支持包5.

如果您的系统没有在SAP HANA或更低版本或支持包上运行，并且您决定进行就地转换，那么就地转换的先决条件是迁移到SAP HANA和升级版本或支持包（通常两者可以结合使用）。有关SAP Business Warehouse到SAP HANA数据库的迁移，请参阅SAP HANA支持的SAP BW端到端实施路线图。

就地转换过程的第一步是安装SAP BW/4HANA Starter附加组件。作为第二步，您将在系统上实现sapbw/4HANA传输驾驶舱。安装完成后，SAP BW系统中提供了几种模式，这些模式定义了通往SAP BW/4HANA的道路：

系统的工作方式与常规SAP BW系统一样，没有任何限制

现有场景可以像以前一样继续运行，但SAP BW/4HANA中不可用的对象类型无法传输（即移动到生产环境），除非您明确说明白名单

系统中只有SAP BW/4HANA兼容对象可用

系统转换的最终准备

为了帮助您将SAP BW系统从一种模式转换到下一种模式，我们提供了一个预检查程序，欧洲云服务器，扫描整个系统的不兼容性，并为您创建一个待办事项列表。如果待办事项已完成且"全部为绿色"，则可以切换到下一个模式。这取决于你的系统配置，你得到什么样的待办事项和有多少。有一点是肯定的：你的系统越旧，待办事项列表就越长，需要的活动也就越多。但是不要害怕，即使成千上万的项目被突出显示。这就是转移驾驶舱和它的范围转移工具来救援的地方。作用域转移工具基于一个任务列表，该任务列表允许您选择对象并将其自动转换为HANA优化的计数器部件。该过程保持对象名称不变（尽可能地），并将所有数据带到（*）。这不是很好吗？