SAP Market Intelligence 2026: Cloud ERP Buyer Signals

Executive summary

SAP opportunity discovery is not a search for companies with an SAP logo in their technology stack. Enterprise landscapes can include multiple SAP and non-SAP systems, heavily adapted processes, country-specific requirements, complex interfaces, long-lived custom code, and several partners. The relevant unit of intelligence is the transformation decision: which process, entity, system, or technical constraint is under review, why now, who owns the consequences, and what proof is required?

SAP's 2025 Integrated Report lists €36.8 billion in total revenue, €21.023 billion in cloud revenue, and €18.119 billion in Cloud ERP Suite revenue. It also reports that more predictable revenue represented 86% of total revenue. (SAP Integrated Report 2025) These vendor-reported financial measures demonstrate the scale and direction of SAP's business; they do not reveal a particular customer's architecture, readiness, budget, or intent.

This playbook turns public and first-party evidence into a governed account model for SAP partners: transformation triggers, landscape facts, process pain, clean-core readiness, buying-group roles, commercial gates, and outcome measurement.

Define the serviceable transformation market

Start with what your team can deliver repeatedly. “SAP consulting” is too broad. A serviceable segment might specify product generation, deployment model, industry process, geography, language, data sensitivity, integration stack, project size, and required on-site coverage.

Then define the transformation job:

• assess and rationalize custom code;
• prepare a selective process or system migration;
• modernize interfaces and monitoring;
• improve master-data governance;
• redesign an order-to-cash, procure-to-pay, record-to-report, or service workflow;
• create a governed extension;
• establish release, test, or adoption controls;
• coordinate a post-merger or multi-entity landscape.

Each job has different evidence, risks, stakeholders, and economics. A reliable market model records the job before attaching a solution.

Build an evidence-based SAP account graph

A parent-company record cannot represent an enterprise transformation. Model the account as connected entities:

1. Legal and operating entities: countries, subsidiaries, shared-service centers, plants, warehouses, and acquired businesses.
2. Business processes: owners, variants, volumes, critical dates, controls, exceptions, and pain.
3. Application landscape: SAP systems, non-SAP systems, deployment models, environments, versions where verified, and system-of-record responsibilities.
4. Data domains: customer, vendor, material, finance, workforce, asset, product, and governance ownership.
5. Interfaces and extensions: purpose, technology, dependency, owner, monitoring, failure path, and lifecycle state.
6. People and partners: business sponsors, process owners, enterprise architecture, platform teams, security, data, finance, procurement, integrators, and support providers.
7. Decision events: renewal, end-of-maintenance concern, acquisition, carve-out, new regulation, control finding, plant rollout, cloud program, or executive mandate.

Record source, capture date, and confidence for every fact. Do not infer a version from a job posting, a migration from a conference quote, or dissatisfaction from a support vacancy.

Use clean core as a discovery lens

SAP describes clean core through five principles: business processes, extensibility, data, integration, and operations. Its guidance connects the approach to standardization, decoupled extensions, governed data, modern APIs, and effective system management. (SAP clean-core guidance)

That framework can organize discovery without turning every account into the same prescription.

Business processes

Identify where differentiation is genuinely valuable and where local variation exists only because no owner resolved it. Capture process variants, volume, cycle time, manual work, exception rate, financial or operational control, and customer impact.

Extensibility

Inventory modifications, enhancements, side-by-side extensions, workflows, forms, reports, and custom applications. Record business owner, technical owner, users, value, dependencies, test coverage, change frequency, and retirement feasibility. “Custom” does not automatically mean bad; undocumented and unowned custom behavior is the risk.

Data

Map data ownership, identifiers, quality rules, migration scope, retention, privacy, reconciliation, and correction. A migration plan that counts records without testing business fitness can move existing problems faster.

Integration

Document producer, consumer, data object, trigger, timing, volume, authentication, failure handling, monitoring, and mastership. Separate an interface count from an integration-risk assessment.

Operations

Review release governance, transports, testing, observability, incident response, job monitoring, capacity, backup, recovery, vendor coordination, and skill coverage. The target state must be operable after the project team leaves.

Recognize signals without overstating intent

Useful signals are specific, current, and connected to a business consequence.

A signal is an invitation to research and ask better questions. It is not permission to claim that a company is “actively buying.”

Map the buying group by decision rights

An SAP transformation often crosses executive, business, technical, risk, and commercial authority. The executive sponsor owns the outcome and tradeoffs. Process owners define acceptable future work. The CIO or transformation office coordinates roadmap and funding. Enterprise architecture governs target-state coherence. SAP platform and operations teams protect maintainability. Data owners control definitions and migration acceptance. Security and privacy leaders define access and handling. Finance, procurement, and legal govern economics and commitments. Frontline users expose whether the designed process works.

For each stakeholder, capture desired outcome, feared failure, approval right, required evidence, current position, relationship owner, and next action. Do not collapse all roles into “IT decision maker.”

Prepare proof matched to the role:

• a process-value hypothesis for business leaders;
• a dependency and transition map for architecture;
• data lineage and reconciliation for data owners;
• access, logging, and supplier evidence for security;
• scenario economics and change control for finance;
• a role-based adoption and support plan for users.

Frame extensions as governed product decisions

SAP states that SAP BTP can extend standard SAP solutions without disrupting their performance and core processes. (SAP BTP developer guidance) That is an architectural option, not a blanket business case.

For any proposed extension, document the unmet need, affected users, measurable outcome, alternatives considered, system and data boundaries, APIs, identity, support owner, service levels, security review, test strategy, deployment path, upgrade dependency, and retirement plan. Include the total lifecycle cost, not only build effort.

Use a decision record with four possible outcomes: adopt standard capability, configure, extend through an approved pattern, or postpone or retire. Preserve the reason and approvers. This turns “clean core” from a slogan into traceable portfolio governance.

Qualify readiness before estimating a program

Score eight dimensions from 0 to 4: executive mandate, process ownership, landscape evidence, data readiness, integration visibility, clean-core governance, delivery capacity, and commercial path. Require a linked artifact or interview note for each score.

Use mandatory gates. Do not advance to a confident estimate when the scope boundary is undefined, business process owners are absent, the landscape inventory is untrusted, data acceptance has no owner, critical dependencies are hidden, or the target operating model is unfunded.

Estimate in ranges tied to assumptions. Separate discovery, remediation, migration, testing, change, hypercare, and ongoing operations. State customer responsibilities and third-party dependencies. Update the range when evidence changes.

Run a proof that informs the roadmap

A useful proof targets one uncertainty: custom-code disposition, data migration quality, interface throughput, process standardization, test automation, or role adoption. Use representative—not merely easy—processes and data. Define success, failure, access, controls, effort, rollback, and decision date before starting.

At close, report observed results, exceptions, limitations, dependencies, residual risk, and production implications. Avoid extrapolating a clean demonstration environment to a complex global landscape without evidence.

Actionable checklist

• Define a narrow, profitable SAP transformation service line.
• Model entities, processes, systems, data, interfaces, extensions, and people.
• Attach sources, dates, and confidence to landscape facts.
• Connect every signal to a business consequence that still needs verification.
• Assess all five clean-core principles.
• Separate valuable differentiation from unowned variation.
• Identify decision rights across the complete buying group.
• Create a lifecycle decision record for each material extension.
• Establish data acceptance and reconciliation ownership.
• Use readiness gates before producing confident estimates.
• Test the riskiest assumption with representative scope.
• Feed proof results and delivery economics back into targeting.

Coordinate SAP transformation pursuits in Arches CRM

Arches CRM can connect entity-level account records, transformation triggers, stakeholder roles, evidence requests, readiness gates, proof results, partner tasks, and commercial next actions. It is a coordination layer, not a substitute for SAP landscape, architecture, implementation, or operations tools.

Next step: Pick one transformation job, define its mandatory evidence and disqualifiers, and assess 15 accounts against the five clean-core dimensions before launching outreach.