Coexist
SAP and adjacent sources coexist
Consumer contracts can draw from approved SAP and non-SAP sources while authority remains explicit.
Solution journey
Modernize SAP without rewriting every consumer
Applications, workflows, and integration teams get stable, versioned business contracts while ECC, S/4HANA, and adjacent non-SAP systems change underneath. SAP stays the system of record; the contracts, adapters, and coexistence routing live in the Apyrn Platform control plane, owned by the teams you name.
Modernization wave explorer
Move the source landscape while protecting consumers
Select a modernization stage to inspect how stable contracts support coexistence, upgrade, and migration.
Select a modernization stage.
Result and contract
- Contract
- Product Availability v1
- Stable
Guided explanation
The customer problem
The customer problem
Applications and integrations tied directly to SAP interfaces inherit migration, upgrade, data-model, and release complexity.
The solution approach
The solution approach
Introduce stable business contracts over approved SAP and non-SAP sources, then change underlying adapters and mappings as the landscape evolves.
Conceptual architecture
- 01
Define consumer-facing contracts around business needs.
- 02
Map current SAP and adjacent sources behind those contracts.
- 03
Evolve source connections without coordinating every consumer release.
What this enables
Protect applications from avoidable source-specific change.
Reuse business logic across modernization waves.
Keep SAP authority explicit while enabling heterogeneous landscapes.
Scope and qualification
Contract, migration, and cutover design must reflect each SAP program's source, process, and coexistence model.
Consumers
Enterprise applicationsIntegration teamsWorkflows and automation
Business API accelerators
The problem
SAP change and consumer change are locked together.
An ECC to S/4HANA program is rarely a single cutover. Most landscapes run both systems for years — module by module, region by region — while upgrades, support packages, and data-model changes such as the business partner model keep arriving underneath. Every consumer wired directly to SAP interfaces inherits that motion. A procurement portal calling BAPIs, a workflow reading IDocs, a custom RFC wrapper, an OData service behind a mobile app: each encodes one source version's schema, authorizations, error behavior, and timing. The visible cost is building those connectors once. The recurring cost is re-testing and re-releasing every one of them each time the interfaces underneath them change, and coordinating those releases across the teams that own the consumers. AI assistants and agents inherit the same dependency in a newer form: where they are approved to reach SAP-held data, they need governed access to stable business meaning, not raw source structures that move mid-migration. The result is a landscape where the migration program and the application roadmap block each other — and both slow down.
The approach
An owned contract layer between consumers and the SAP landscape.
Consumers depend on versioned business contracts. Everything source-specific — schemas, protocols, credentials, routing — lives behind them in the Apyrn Platform control plane, where your platform team owns and operates it.
Contracts shaped for the business need
A vendor, product, inventory, or order contract states the fields, operations, freshness, and failure behavior consumers can rely on — versioned and documented, not a mirror of one SAP schema. Vendor360, Product360, Inventory360, and Order360 give teams a reviewed starting shape, mapped to the sources your enterprise approves.
Adapters absorb source mechanics
BAPI, IDoc, OData, and custom RFC access paths become adapters and mappings in the control plane. When SAP changes, the adapter changes; the contract version consumers hold does not have to move with it.
Coexistence routing stays explicit
While ECC and S/4HANA both serve live data, routing and mapping rules record which system is authoritative for which entity, region, or company code — with provenance visible to consumers.
Access patterns fit the workload
Runtime virtualization, composed operations across systems, or zero-copy access where source capacity, latency, permissions, and residency make it suitable — chosen per contract, not one mandated pattern. Caching, events, and persisted integration stores remain the right answer for many SAP workloads, and the contract says which one it uses.
Worked example
One contract through a migration wave.
Fictional walk-through: the company, waves, and details are invented and shown as examples only; the sequence is the pattern. A manufacturer is moving vendor master data from ECC to S/4HANA in regional waves while a supplier portal, three procurement workflows, and an internal assistant all depend on it.
- 01
Bound one contract
The team scopes vendor data only: the fields, lookups, and operations the portal, workflows, and assistant actually use. A named owner on the customer's platform team accepts the contract; everything else stays out of scope.
- 02
Map current sources behind it
The versioned vendor contract is mapped to today's ECC interfaces. Source authority and provenance are recorded per field, so consumers can see where each value comes from and how fresh it is.
- 03
Move consumers one at a time
The portal switches to the contract first, then the workflows, then the assistant. Each retires its direct SAP calls on its own schedule — no coordinated big-bang release.
- 04
Shift routing as waves cut over
When a region's vendor master moves to S/4HANA, the routing rule behind the contract changes for that region. Both systems serve live traffic during coexistence, and consumers keep the contract version they already hold.
- 05
Operate and retire
The team watches one dependency instead of chasing it across every consumer, separates contract failures from source failures, and records retirement criteria for the ECC path. When the last wave lands, the old adapter is decommissioned. No consumer had to re-release for the cutover mechanics; where a wave changes business meaning rather than plumbing, that surfaces as a contract version decision with a named owner instead of scattered rework.
Boundaries
What Apyrn does here — and what it deliberately does not.
The boundary matters more than the feature list. SAP remains the system of record for everything it owns today.
What the control plane takes on
Contract definition and versioning, adapters and mappings, coexistence routing, access policy, provenance, and one view of which consumers depend on which sources — held in one governed place instead of inside every consumer.
What Apyrn does not do
It is not a substitute for SAP or any system of record, and it does not migrate systems for you: migration decisions, data conversion, and cutover execution stay with your teams and partners. Writes pass through approved SAP operations, so SAP business logic, authorizations, and transaction behavior still apply.
What remains with your team
Source ownership, master data governance, the migration program itself, ownership and approval of each contract, and every consequential architecture decision. Apyrn surfaces dependencies and proposes options; your architects decide.
Decision guidance
Is a contract layer the right move for your landscape?
An honesty check before you invest in an interface layer.
When this fits
A multi-year SAP program with applications and workflows that must keep shipping. More than one system claiming parts of the same business entity. Connector work repeated across teams. An integration team that can publish and operate shared contracts — including for the AI assistants your enterprise approves to reach SAP-held data.
When it does not
A single consumer on one stable SAP interface, with no migration in sight, rarely justifies a contract layer. The same is true when no team can own the contract — an interface without an owner becomes another dependency, not fewer.
What to check first
List the consumers that would have to change if SAP changed tomorrow. For one entity — vendor, product, order — name the authoritative source per field, the freshness each consumer needs, and who would own the contract. If that record is easy to produce, you are ready to scope a first contract; if not, that is the work to start with.
Common questions
Questions teams ask before starting.
Do we need to finish our S/4HANA migration before putting an API layer over SAP?
No — the opposite order is common. A contract layer is most useful during coexistence, when ECC and S/4HANA both serve live data and consumers need one stable interface while routing shifts underneath. Contracts mapped to ECC today can be remapped to S/4HANA sources wave by wave without changing the version consumers depend on. What matters is recording source authority and routing explicitly, and designing the contract around your program's actual coexistence model rather than waiting for the migration to end.
How is Apyrn different from SAP middleware like PI/PO or Integration Suite?
They do different jobs. Middleware moves messages: transport, transformation, and orchestration between systems. Apyrn Platform is where consumer-facing API products are owned — named contracts with versioning, documented ownership, policy, provenance, and an operating record. Many landscapes run both: middleware keeps carrying system-to-system traffic while the contract layer presents the governed business interface that applications, workflows, and approved AI consumers depend on.
Can applications write to SAP through Apyrn, or is it read-only?
Writes are supported — through approved SAP operations, not around them. A contract can expose actions such as creating a vendor or updating an order, and those actions execute through the source's own interfaces, so SAP business logic, authorizations, and transaction behavior still apply. Write design must reflect the transaction and compensation behavior of the participating systems, which is why approved operations are defined per contract rather than assumed.
What happens to our custom SAP connectors during an ECC to S/4HANA migration?
Their connection mechanics move behind the contract. The schemas, authentication, pagination, and error handling that live in each consumer's custom connector today become adapters and mappings owned in the control plane. Consumers that have moved to the contract do not rebuild when the source changes; the adapter is remapped to the new S/4HANA interfaces instead. Each new mapping still has to be designed and tested against the new source — the layer removes repeated consumer rework, not the migration work itself.