SAP S/4HANA Migration Raises a New Question: Where Should Process Logic Live?

Panasonic Europe wanted to move workflows from SAP R/3 to S/4HANA without rebuilding the process layer every time the underlying ERP changed.

Its answer was to separate the two. The company now runs Camunda as a centralized orchestration layer across multiple SAP environments, using OData APIs to abstract the connection to different SAP versions. Panasonic says that when an ERP system changes, the process itself can remain largely untouched.

That approach points to a broader decision facing SAP customers as they modernize: how much process logic should move with the ERP at all?

Camunda designed its SAP integration around the idea that selected workflows can be standardized outside SAP ECC or SAP S/4HANA while SAP continues to handle the transactions and data underneath them. Its migration model explicitly puts process orchestration before the technical move to SAP S/4HANA.

Decouple the Process Before Changing the ERP

Camunda’s migration model separates two changes SAP customers often treat as one: redesigning a business process and replacing the ERP beneath it.

A workflow can be standardized and executed in Camunda while SAP ECC continues to handle the underlying transactions, allowing process redesign to move ahead of the ERP conversion itself. When the relevant backend moves to SAP S/4HANA, the workflow can be redirected to the new environment. Camunda supports that handoff through OData and RFC connectors alongside SAP BTP and SAP Cloud Connector.

Panasonic applied the model as it moved workflows off legacy systems. While preparing its SAP R/3-to-S/4HANA migration, it used OData as an abstraction layer between Camunda and multiple SAP versions. When the SAP backend changes, Panasonic can adapt parts of the integration rather than rebuild the workflow itself.

Panasonic began shifting workflows into Camunda with simpler approval and non-SAP processes before expanding into more SAP-connected workflows. That gave the team time to establish the platform and build experience with Business Process Model and Notation (BPMN) and Decision Model and Notation (DMN). It also allowed Panasonic to create reusable process components before connecting SAP environments.

Keep SAP as the System of Record Without Making It the Process Boundary

Camunda’s model leaves SAP responsible for the records and transactions it already owns while the orchestration layer coordinates the work around them, including steps that cross other applications, users, and decision rules. Camunda describes SAP as the system of record, even when a process extends into other enterprise systems.

Panasonic uses that split in its SAP S/4HANA business-partner process. The company replaced email, spreadsheets, and manual validation with a Camunda workflow that guides users through forms, validates information against SAP, and records the approval path. SAP S/4HANA remains the source of truth for the business-partner data, while Camunda manages the process leading to its creation.

The distinction also helps define where Camunda sees a role alongside SAP’s own automation tools. In its CamundaCon material, the company places Camunda Process Orchestration alongside SAP Build Process Automation and associates Camunda with long-running processes, scalability, resilience, and alignment across systems.

A Separate Process Layer Changes How SAP Teams Work

Moving process logic outside SAP also changes who can work on it. Camunda uses BPMN to model executable processes and DMN to model decision logic, giving business process specialists and developers a common representation of the workflow. Camunda argues that this model-driven approach can keep business and IT aligned as processes change.

Panasonic has divided responsibilities along those lines. Its process specialists can work on workflows without needing to manage the technical details inside SAP, while SAP developers can focus on the ERP without owning the entire end-to-end process model.

The model is operating at scale: Panasonic reports more than 220,000 workflow instances annually across more than 600 process-request types, with a four-person team supporting the enterprise workflow environment and new process definitions deployed weekly.

Camunda is now extending its SAP orchestration model to include AI agents, placing them alongside human approvals and existing automated steps. According to the Panasonic case study, the company plans to make workflow data available through OpenSearch so agents can answer questions about processes.

As the orchestration layer takes on responsibility for agent activity as well as systems and people, governance becomes part of the architecture rather than an adjacent control.

What This Means for SAPinsiders

• Future SAP changes may require less process rework. Decoupled workflows can remain stable as the underlying ERP changes, shifting effort toward narrower integration updates. That could reduce how much business-process work accompanies future SAP upgrades and migrations.
• Reusable process components can speed later automation. Panasonic built reusable components before connecting more SAP environments, allowing later workflows to start from established process patterns. That can reduce duplicated design work as orchestration expands across teams and systems.
• Agents can enter already governed workflows. Camunda is placing agents alongside human approvals and existing automated steps rather than treating them as a separate process layer. That gives SAP teams an existing structure for deciding where agent activity belongs and where oversight remains necessary.