在云部署之前，大多数情况下，这种方法对 SAP 和客户而言都是非常直接的。在某些方面，它与合同类似。SAP 提供了某些内容以及客户遵循的某些步骤和程序。想象一个简单的场景，其中 SAP 应用程序中的屏幕包含两个字段：收入和成本。猜测最终用户请求将附加字段添加到显示中，不会太推测。假设他们通过请求新字段显示利润来执行此操作。假设利润不仅使用收入和成本计算，还会使用客户使用的特殊数字因子进行计算。由于此因子是客户特定的，因此没有字段可将其保存在应用程序正在使用的任何基础数据库表中。
要实施此类场景，SAP 将向客户提供所谓的出口。这些出口将位于整个"堆栈"的多个层。我们来逐一看看这些层，从最低层（数据层）开始。在我们的简单场景中，开发人员将使用"表附加"将新字段添加到表示之前提到的数值因子的数据库表中。激活后，此字段将可供读取和存储。表附加有效地为客户提供了通用出口概念，用于调整任何提供的 SAP 表的定义，以满足其独特的业务需求。
需要由 SAP 提供出口的下一堆栈层将是最高层 - 可视层。此时，将会显示新字段（简单场景中的利润）。可视层出口主要由两种类型组成：屏幕出口和菜单出口。在我们的简单场景中，开发人员将使用屏幕出口将新字段添加到屏幕，并可能使用菜单出口添加新命令，当最终用户选择该命令时，该命令将执行利润计算。
以某种方式需要出口的最终堆栈层是最重要的。这是因为在堆栈的数据层添加并在堆栈的可视层看到的新字段将包含可能需要读取、使用、更新甚至可能不时删除的值。需要使用 ABAP 代码实施这些操作。因此，在数据和 UI 之间的中间（即代码）层实施的代码出口由 SAP 创建。同样，在我们的简单场景中，开发人员将首先确认是否存在代码出口以对字段执行任何所需操作，然后使用必要的客户特定代码实施出口。
因此，客户将具有应用程序提供的标准功能，并通过所需的附加功能进行增强。此方法的一个重要方面是，使用出口的整个流程由定义的系统流程管理。必须激活出口。出口的具体实施必须通过所有相关语法和一致性测试。出口开发发生在专用开发系统中，并在发布到生产系统中的最终用户之前在测试系统中进行测试。这种方法的另一个重要方面是，一般来说，出口的开发可以不受限制地利用系统中的任何 SAP 对象。例如：
- 任何 SAP 表均可用于读取和写入记录
- 可调用任何 SAP 功能模块
- 可以使用任何 SAP 类（及其方法）
最终（和重要）要点。如果客户确定没有出口（或不可用），则可以执行以下两个选择：
- 以某种方式对 SAP 对象执行修改以实现所需的功能。
- 复制 SAP 对象。新对象将是客户自有对象，因此可以相应更改。
如前所述，交付的系统具有客户调整的优势，作为其设计的一部分，必须平衡某些优势和特定成本。换句话说，应用补丁或升级系统时，实施的任何扩展在理论上都可能会成为一个问题，因为软件供应商的新代码或更新代码可能会使扩展不稳定甚至不需要。为确保情况并非如此，需要进行测试。然而，即使考虑到这一点，管理测试过程的费用还是合理的，而不是扩展的好处和灵活性。一般来说，由于 SAP 知道出口的存在性，因此实施出口时客户调整对升级的问题较小，并且可以加以说明。SAP 对象的修改和/或 SAP 对象的副本可能会产生更多问题，并且必须在应用补丁或进行升级后进行彻底测试。
几十年来，这种方法持续了 SAP 和客户。从 SAP R/3 的所有版本开始，一直到通过 SAP Business Suite、服务包和增强包。但是，此方法成功的一个原因是，系统几乎始终位于客户数据中心，因此客户自己维护了 100%。在他们的系统中，一位客户所做的事情与其他客户在其系统中的操作完全不同。然而，发生了一个"游戏变革者"。这种变化是 SAP ERP 到 SAP S/4HANA 的演变。
