To address this critical vulnerability gap, SAPSOL Technologies LLC has published a comprehensive 22-page executive playbook: Zero Trust in the Autonomous Enterprise: Safeguarding SAP S/4HANA Against Behavioral Anomalies & Insider Threat, featuring TraceSecure.

In this article, we examine why traditional Governance, Risk, and Compliance (GRC) frameworks fail against behavioral deviations, how in-memory telemetry operates at line-rate speed, and how autonomous micro-revocation prevents catastrophic capital flight before payment runs execute.

The Architectural Paradox: The Perimeter Fallacy in SAP S/4HANA

For two decades, enterprise SAP security relied on two foundational assumptions:

1. The Network Perimeter Barrier: Everything inside the corporate virtual private network (VPN) or enterprise Demilitarized Zone (DMZ) is trusted.
2. Static Role-Based Access Control (RBAC): If a user possesses the requisite authorization objects in transaction SU53 and passes Segregation of Duties (SoD) audits, their business execution is inherently legitimate.

In the modern autonomous enterprise, both assumptions collapse under operational reality.

As organizations migrate from legacy ECC systems to SAP S/4HANA (whether Cloud Private Edition, Cloud Public Edition, or on-premise RISE deployments), the enterprise perimeter dissolves. Core business logic is exposed through SAP Business Technology Platform (BTP), OData application programming interfaces (APIs), third-party logistics integrations, and remote hybrid workforces.

When a trusted user’s session token is intercepted, when an administrator’s emergency Firefighter ID is misappropriated, or when a disgruntled internal controller alters supplier banking details minutes before an automated payment run, standard SAP authorization logs simply record a valid transaction. Traditional GRC audits only discover the discrepancy weeks or months later during post-mortem financial reconciliations.

The Three Pillars of Behavioral Zero Trust for SAP

True Zero Trust architecture for enterprise SAP requires abandoning implicit trust inside authenticated sessions. Every single transaction, Remote Function Call (RFC), and database commit must be continuously verified against dynamic baseline behavior.

Our whitepaper establishes an operational engineering framework built upon three foundational capabilities:

1. Passive In-Memory Kernel Telemetry

Traditional application monitoring solutions rely on batch log scraping, database table polling, or heavy host agents that degrade production throughput. In high-volume SAP S/4HANA environments processing millions of lines per hour, latency overhead is unacceptable.

The TraceSecure behavioral intelligence engine utilizes passive, non-intrusive ABAP kernel surveillance. Operating directly within the SAP HANA in-memory architecture, it captures 100 percent of dialog, RFC, and batch commits with an execution latency under 15 milliseconds, introducing zero measurable overhead to business end-users.

2. Dynamic Anomaly Scoring (DAS)

Instead of rigid boolean rule sets that generate overwhelming false-positive alert fatigue, behavioral Zero Trust employs unsupervised machine learning baselines. Every transaction is dynamically scored across multiple vectors:

• Velocity and Timing: Did the transaction occur outside normal operating hours, or at an unnatural speed suggesting automated robotic manipulation?
• Monetary Threshold Variations: Does the line item deviate significantly from historical moving averages for that specific vendor or material group?
• Session Geolocation and Fingerprint: Is the transaction originating from an unexpected IP address, device profile, or concurrent geographic location?
• Workflow Sequencing: Did the user modify sensitive master data immediately preceding an outbound payment proposal without customary review intervals?

3. Autonomous Surgical Micro-Revocation

When an anomaly score exceeds verified risk thresholds, legacy security systems face an impossible dilemma: either freeze the entire user account (shutting down essential plant operations) or merely email an alert that sits unread in an inbox while funds transfer.

Autonomous Zero Trust enforces surgical micro-isolation. The platform can isolate and cancel only the specific high-risk transaction commit, require out-of-band biometric Multi-Factor Authentication (MFA), or require secondary supervisor dual-control authorization, all without disrupting the remainder of the user’s legitimate daily workload.

Real-World Threat Scenario: The 8-Minute Vendor Bank Hijack

Consider a common, highly destructive insider threat scenario mitigated by behavioral Zero Trust:

Regulatory and Compliance Governance Mapping

Beyond operational loss prevention, continuous behavioral Zero Trust satisfies the most demanding international compliance standards:

Regulatory Standard	Governance Requirement	TraceSecure Architecture Alignment
SOX Section 404	Internal controls over financial reporting and material misstatement prevention	Cryptographically sealed audit trail proving continuous verification across AP, AR, and GL postings
NIST CSF 2.0	Continuous monitoring, behavioral anomaly detection, and automated mitigation	Sub-15ms threat detection and automated micro-revocation without human latency delays
GDPR Article 32	Security of personal data processing and prevention of unauthorized exfiltration	Instant identification of mass query dumps and anomalous customer/employee table downloads

Executive Summary: Preparing Your SAP Landscape for 2027 and Beyond

As global enterprises accelerate their transitions to SAP S/4HANA and clean core architectures, cybersecurity strategies must evolve from perimeter gatekeeping to continuous in-session intelligence. Relying exclusively on static access controls leaves enterprise ERP systems vulnerable to the fastest-growing attack vector in global business: authorized insider credentials executing unauthorized operations.

By implementing passive in-memory telemetry, machine-learned behavioral baselines, and surgical micro-revocation, organizations can safeguard their digital core while empowering employees with friction-free productivity.

About SAPSOL Technologies LLC: Headquartered in Santa Clara, California with Canadian delivery operations in Mississauga, Ontario, SAPSOL Technologies LLC provides enterprise SAP consulting, S/4HANA migration frameworks, and proprietary behavioral intelligence solutions through TraceSecure. Contact us at info@sapsol.com or call +1 (343) 800-0733.

The difficult question is not only whether to move to SAP Integration Suite. It is which integrations to assess, redesign and migrate first without disrupting orders, suppliers, inventory, finance or customers. A responsible program needs a verified inventory, business ownership, technical assessment and repeatable regression testing before it needs an aggressive migration date.

At a glance: begin with a landscape inventory and a bounded pilot. Prioritize high-risk dependencies and interfaces with a clear path to modernization, but do not move mission-critical, heavily customized flows without proper testing, cutover and rollback plans.

What happens to SAP PI/PO after 2027?

SAP’s maintenance strategy applies to SAP Process Integration and SAP Process Orchestration 7.5 in alignment with SAP NetWeaver 7.5. Mainstream maintenance runs through the end of 2027, while optional extended maintenance can extend to the end of 2030. This does not mean every existing interface automatically stops processing messages on January 1, 2028. Organizations must confirm their own release, commercial terms and support entitlements.

The long-term picture requires equal attention. SAP clarified in October 2026 that its existing support arrangements for Java used with NetWeaver AS Java 7.5 are scheduled to end after 2030, limiting what customer-specific maintenance can replace. For a company that expects PI/PO to remain critical indefinitely, this is a reason to create a funded transition plan now—not an invitation to make unsupported promises about future support.

Sources: SAP NetWeaver maintenance strategy and SAP’s October 2026 support clarification.

The five integration groups to assess first

1. Stable, well-understood interfaces for a controlled pilot

A good first migration candidate is not necessarily your most important interface. Begin by identifying several flows with known endpoints, representative payloads, business owners and manageable dependency chains. These can be used to validate connectivity, deployment, mapping, operations, alerting and the test process in SAP Integration Suite.

The aim is to learn what changes when a message passes through the new runtime. Can the team detect failure and retry safely? Are the output fields equivalent? Do certificates and credentials rotate properly? Can support engineers find and replay failed messages? A pilot that answers those questions provides evidence for later waves.

2. Business-critical integrations with many dependencies

Order-to-Cash, Procure-to-Pay, warehouse, manufacturing and finance integrations often cross several applications and partners. They should be assessed early because their dependency and testing requirements influence the roadmap, even if they are migrated later. An end-to-end business-service map is more useful than a long list of technical interface IDs.

For example, a sales-order flow may depend on pricing, inventory availability, warehouse execution, carrier status and invoicing. Migrating one leg without examining the others could create reconciliation or exception-handling issues. Assign a business owner who can validate the complete process.

3. Custom mappings, Java code and adapter modules

Identify these early because they can consume disproportionate redesign and testing effort. SAP documents limitations in its Migration Tooling around custom adapter modules, specific mapping patterns, lookups and message-processing behavior. A technically “successful” conversion might not preserve every business rule or operational control.

These scenarios need a design review that asks what the old logic really does, whether a supported capability now replaces it, whether the connected application must change, and what regression evidence is required. Treat unexamined custom code as a risk to be resolved, not a small line item to be migrated last.

4. Partner-facing B2B and EDI integrations

External partner connections introduce coordination beyond the SAP team. B2B and EDI scenarios may require partner-specific mappings, acknowledgments, testing windows, certificate exchanges and formal sign-off. SAP’s automated Migration Assessment has limitations for B2B scenarios and related business-process logic, so these require deliberate manual review.

Assess them early enough to reserve partner testing time. Their cutovers may be scheduled later around agreed windows, commercial commitments and operational calendars.

5. Low-value, dormant or duplicate interfaces that can be retired

One of the quickest ways to reduce migration effort is to avoid rebuilding something the business no longer needs. An inactive application, decommissioned reporting feed or duplicate master-data integration should be examined for retirement. But do not confuse low traffic with low value: a quarterly finance or regulatory interface might execute rarely and still be essential.

Require business-owner approval, usage evidence and an agreed monitoring period before retirement. Every retired interface should reduce cost and complexity without creating an unseen operational gap.

How SAP Migration Assessment can guide the plan

SAP Integration Suite includes a Migration Assessment capability that evaluates existing PI/PO integration scenarios and assigns classifications including Ready to migrate, Adjustment required and Evaluation required. These classifications help prioritize review. They do not guarantee automated conversion or successful production operation.

• Ready to migrate: the scenario aligns with available capabilities, but may still need manual or semi-automated migration and configuration changes.
• Adjustment required: the scenario partly aligns and needs changes to the integration design or connected systems.
• Evaluation required: more investigation is needed, often because of unsupported behavior, custom code or unclear dependencies.

SAP explicitly distinguishes an assessment category from the migration tool’s automation coverage. It also lists limits for custom adapters, B2B and BPM scenarios and dependencies inside custom mappings. Teams should record both the classification and the effort to achieve functional equivalence.

See SAP’s Migration Assessment concepts, assessment limitations, and Migration Tooling limitations.

Should every interface run in the cloud?

Not necessarily. SAP Integration Suite’s Cloud Integration capability is an important target for many scenarios, but the architecture should reflect network, latency, compliance, data-residency and operational requirements. SAP’s Edge Integration Cell provides an option for processing certain integration workloads inside a private landscape with a customer-managed Kubernetes runtime while retaining cloud-based design and governance.

That private runtime is not a free shortcut: it adds infrastructure, storage, networking, monitoring and lifecycle responsibilities. Compare the full operating model before selecting it. The goal is an integration landscape that is easier to govern and support, not one that replicates every legacy dependency in a different location.

For background, see SAPSOL’s article on SAP Integration Suite and SAP BTP and modernization around the SAP core.

A practical 30-day plan for IT leaders

If your organization is starting now, the first month should produce decisions and evidence rather than a premature promise to replace the entire platform.

1. Week 1 — Confirm the baseline. Verify SAP PI/PO versions, entitlements, support contracts, installed add-ons and accountable business and technical owners.
2. Week 2 — Inventory the integration estate. Capture interfaces, adapters, mappings, custom components, connected systems, throughput, error handling, service levels and sample payloads. Flag dormant, critical and externally governed flows.
3. Week 3 — Assess and classify. Use SAP Migration Assessment where applicable. Review custom code and known assessment blind spots manually. Classify candidates as retire, reuse, migrate, redesign or defer.
4. Week 4 — Plan a pilot and operating model. Select representative flows, define expected outputs, ownership, monitoring and rollback, and assign exit criteria. Obtain approval for the first controlled wave.

From there, plan a 60–90-day sequence to validate architecture, execute the pilot, establish regression coverage and build a business-aligned migration roadmap. This is a planning method, not a claim that the entire PI/PO landscape can be migrated in 90 days.

What to ask before approving your first migration wave

• Do we know which transactions and applications each integration supports?
• Do we have current technical and business owners for each scenario?
• Have custom modules, mappings and B2B or BPM dependencies been reviewed?
• Can we prove that retries, duplicates, sequencing and error recovery behave correctly?
• Is the target connectivity and security design approved?
• Do business owners have representative test cases and approval criteria?
• Are coexistence, rollback and legacy decommissioning requirements documented?

Next step: build a defensible SAP PI/PO migration roadmap

The safest migration plan is not the slowest or the fastest. It is the one that clearly identifies what must change, what can be retired, what needs redesign and what business evidence is required to go live. SAP Integration Suite can be the foundation, but inventory quality, design decisions and accountable testing determine whether the transition is operationally sound.

SAPSOL Technologies can help structure readiness discovery, integration analysis, target-design discussions and migration-wave planning. For a detailed framework, see The 2027 SAP PI/PO Migration Playbook. You can also request a consultation with SAPSOL or review its SAP consulting services.

The latest SAP and Databricks announcements give enterprise leaders a reason to revisit that connection. The practical question is where the new capabilities could support a measurable business use case, and what must be verified before committing budget.

What changed in the SAP and Databricks partnership?

In its October 30, 2026 announcement, Databricks described an expanded SAP partnership covering access to SAP application data and plans to bring additional capabilities into SAP Databricks.

SAP Business Data Cloud provides the broader data offering, while SAP Databricks brings Databricks capabilities into that environment. The announcement also describes a path for customers with an existing Databricks estate. These relationships matter when evaluating an architecture: an enterprise should begin with its existing platforms, contracts and operating responsibilities.

SAP Databricks or your existing Databricks platform?

Compare using SAP Databricks within SAP Business Data Cloud with connecting suitable SAP data to an existing Databricks environment. Start by documenting what your organization already operates. Evaluate the required datasets, supported access methods, governance responsibilities and applicable contracts before selecting an approach.

Ask who will manage permissions, monitor usage, resolve data quality issues and support business users. Include the effort of operating another environment in the comparison. The preferred route should fit the pilot’s requirements and the team’s capacity to support it. A familiar platform alone does not establish that every required SAP dataset or capability is available.

What is available, and what still needs checking?

Sources: Databricks partnership announcement, October 30, 2026 and SAP TechEd 2026 Innovation News Guide. Status reviewed November 4, 2026.

Before designing a production dependency, ask the relevant account team to confirm the exact service, region, release stage, prerequisites and commercial terms. Record those answers in the project plan. A roadmap item can inform planning without becoming an assumption in a delivery commitment.

Start with a business decision that needs better evidence

A useful evaluation begins with a named decision and an accountable owner. “Use AI on SAP data” leaves too much undefined. “Help inventory planners identify replenishment exceptions before the weekly review” gives the team something it can test.

Other candidate questions include whether finance can investigate unusual balances more consistently, or whether procurement can identify supplier exceptions earlier. These are proposed evaluation scenarios, rather than promised product outcomes. Each requires a baseline and a clear explanation of how the result will change someone’s work.

Choose a narrow initial scope. Specify who receives the output, how often they need it and what action they are allowed to take. Begin with recommendations that people review before considering automated execution.

A hypothetical inventory planning pilot

Consider a hypothetical manufacturer whose planners reconcile order history, stock records and supplier information before deciding which materials need attention.

The pilot could focus on one material group and produce an exception list for a planner to review. The team would agree how to interpret available stock, open orders and expected receipts. It would then compare the proposed output with the current planning process using the same evaluation period.

Acceptance criteria might include reconciliation accuracy, the usefulness of flagged exceptions, investigation time and the number of recommendations the planner rejects. Set the targets before testing. Retain the existing process as a fallback until the business owner accepts the results.

This example illustrates a pilot design. It does not represent a SAPSOL customer deployment or a guaranteed capability of any particular service.

Check the data before choosing the model

For each required dataset, identify the owner, source, business meaning and permitted use. Ask whether the proposed access method supplies the required fields, history and refresh frequency.

• Definitions: Agree which measures and statuses the business will use.
• Quality: Investigate missing values, inconsistent identifiers and unusual records.
• Freshness: Define the maximum acceptable delay for the decision.
• Traceability: Ensure reviewers can connect an output to its supporting records.

For organizations establishing these foundations, SAPSOL’s data management services provide a relevant starting point for a discussion about the current landscape and its requirements.

Evaluate sharing, integration and operating cost together

Treat data sharing and integration claims as items to validate against the actual workload. Ask which data must be transferred, retained, transformed or queried, and where those activities occur. A diagram should show these responsibilities explicitly.

Build a pilot cost worksheet covering applicable service entitlements, processing, storage, network charges, monitoring and support. Include the people who will maintain permissions, investigate failed jobs and respond when source definitions change.

Compare the proposed approach with the existing process under the same assumptions. Do not count a potential saving until the pilot demonstrates it. SAPSOL’s SAP BTP solutions and analytics services offer related areas for exploring integration and reporting requirements.

Keep access and business approval explicit

Separate the permission to read data from the permission to act on a recommendation. Document which identities can access each dataset, which outputs they can view and who can approve a business action.

Test those boundaries with representative user roles. Check logging, retention and incident ownership before extending the pilot. If a recommendation influences procurement or financial processing, define when human approval is required and how a disputed result will be investigated.

Common questions about SAP Databricks and enterprise AI

What is SAP Databricks?

SAP Databricks brings Databricks data and AI capabilities into SAP Business Data Cloud. Evaluate its specific services and access options against the business use case, rather than assuming every Databricks capability is included.

Do businesses need to move all SAP data before starting?

Start by identifying the data required for one pilot. Verify the supported access method, permitted use and refresh frequency. Decide whether a wider data move is necessary only after those requirements have been established.

Which new capabilities are available now?

Availability varies by capability. Use the status table above as a starting point, then confirm the required service, region, release stage and contractual prerequisites with the relevant account team before planning production use.

A short checklist before the next investment decision

• Choose one business question and name its owner.
• Confirm the required data and suitable access method.
• Verify capability availability and contractual prerequisites.
• Agree evaluation measures and a comparable baseline.
• Test permissions, operational support and fallback procedures.
• Review evidence before expanding the scope.

The value of the announcement will depend on the decisions an organization can improve with its own data. A focused evaluation provides a stronger basis for investment than a broad platform commitment made before the requirements are understood.

Plan your next enterprise data and AI discussion

SAPSOL Technologies LLC can help you explore data management, integration and analytics requirements as part of your enterprise technology roadmap. Contact SAPSOL to discuss your current environment and a practical starting scope.

info@sapsol.com | +1 343 800 0733

© 2026 SAPSOL Technologies LLC | All Rights Reserved | www.sapsol.com

Key takeaways for enterprise buyers and leaders

• Confirm product access and applicability before building AI capabilities into the migration schedule.
• Define acceptance criteria before asking an assistant to recommend or execute a change.
• Measure accepted outcomes, including reconciliation and test results, rather than the volume of generated outputs.
• Keep accountable business owners involved in decisions affecting financial results, access and operational continuity.

What has changed in SAP migration tooling?

In its October 28, 2026 announcement, SAP described four migration assistants operating with early adopter customers. They cover data management, testing, custom code and business configuration. SAP also outlined additional planned assistants.

This is an early adopter milestone, not confirmation of general availability for every customer. Organizations should verify eligibility, target system requirements, commercial terms and permitted usage with SAP before committing project dependencies.

The controls below are practical editorial recommendations for evaluating AI assisted SAP migration. They are not a description of features included in a particular SAP product.

Start with an acceptance decision, then choose automation

A useful starting point is a task your team can explain and verify. “Prepare a migration assessment” is too broad. “Identify supplier records that fail an agreed completeness rule and provide the supporting evidence” gives reviewers a bounded result to evaluate.

For each candidate task, document the input, permitted action, expected output and acceptance owner. State whether the assistant may only suggest a change, prepare it for review or execute an approved action. These permissions should follow the sensitivity of the task.

A generated recommendation should enter a review process with a named owner. It should not become an approved requirement simply because it appears in a polished report.

Data: automate preparation, validate business meaning

Begin with a defined population and rules approved by the relevant data owners. Supplier master data, customer balances and material records require different checks. A technical field validation can succeed while the business interpretation remains wrong.

For a proposed correction, retain the original value, suggested value, reason and approval. Separate obvious formatting corrections from changes affecting payment instructions, tax treatment or organizational ownership. The latter require review by someone authorized to make that business decision.

Evidence to request before acceptance

• Source and target record counts with explained exclusions.
• Reconciliation of relevant financial balances and business control totals.
• A reviewable list of rejected records, unresolved exceptions and assigned owners.
• Repeatable validation rules that can be rerun after the final migration load.

Do not close a data workstream because a dashboard reports a high completion rate. Close it when the accountable owner accepts the reconciled population and understands the remaining exceptions.

Custom code: validate the process behind the program

A code finding is a starting point for investigation. Before accepting remediation, identify the process the code supports, the users who depend on it and the interfaces it touches. Ask whether the requirement remains necessary in the target landscape.

Consider whether standard functionality can meet the requirement, whether an extension remains justified and where that extension should operate. An automated correction can preserve a technically valid solution that the business no longer needs.

Review proposed changes through the existing development and transport controls. Require understandable change records, appropriate access and a tested recovery approach. For critical logic, include a functional reviewer alongside the developer.

Organizations planning SAP S/4HANA migration and implementation should connect code decisions to the target operating model rather than treating remediation as an isolated technical backlog.

Testing: generated cases still need meaningful coverage

A large collection of test cases can create confidence without demonstrating readiness. Start with the business processes that must continue operating, then map tests to requirements, integrations, roles and expected outcomes.

Review whether the proposed scenarios include exceptions. A successful sales order is useful, but so are blocked credit, partial delivery, a rejected interface message and an unsuccessful authorization attempt. Select scenarios according to the organization’s actual risks and process design.

Questions for the test owner

• Does each critical requirement have an agreed expected result?
• Does the test data represent the conditions the business needs to validate?
• Are integration failures and recovery procedures included where relevant?
• Can a reviewer trace a reported pass to execution evidence?
• Are unresolved defects assessed for business impact before acceptance?

Keep business acceptance separate from automated execution status. A tool can report that a script completed. The responsible business owner must decide whether the evidence demonstrates an acceptable outcome.

Configuration: review the consequences across functions

Configuration choices often affect teams beyond the person reviewing the change. A recommendation involving organizational structures, approval limits or account determination should be evaluated with the functions that own those outcomes.

Keep an approved design record explaining the requirement and the reason for the selected configuration. Record dependencies and distinguish reusable template decisions from local exceptions. This helps reviewers understand whether an apparent inconsistency is a defect or a deliberate business choice.

Before promoting a change, demonstrate its effect in an appropriate test environment. Review both the intended outcome and relevant boundaries, including who can perform the action and what happens when a condition is not met.

A hypothetical example: preparing supplier data

Consider a fictional manufacturer preparing supplier records for migration. Its team uses an assistant to identify missing fields and suggest records that may represent the same supplier.

The team does not approve automatic merging based only on similar names. Procurement reviews the business relationship, finance checks the relevant accounting implications and an authorized owner reviews any proposed changes to payment information.

Approved corrections are applied through the organization’s controlled process. The team then repeats its validation and reconciles the migration population. Unresolved records remain visible with owners and a documented decision about their treatment.

The value of this approach is a clearer review process and traceable decisions. It does not assume a particular product feature, a guaranteed reduction in effort or a result achieved by SAPSOL Technologies LLC.

Plan the skills required to review AI outputs

AI assistance changes the work reviewers perform. Teams need people who understand the business requirement, can examine the supporting evidence and know when to reject or escalate a recommendation.

Build review responsibilities into the project plan. Data owners need decision time. Functional leads need access to realistic scenarios. Developers need clear extension principles. Test leads need acceptance criteria that business owners understand.

SAP corporate training and workforce development can support these responsibilities by addressing specific skills gaps before critical project checkpoints. Where capacity is missing, define the required expertise before requesting additional resources.

A practical approval checklist

Before accepting an AI assisted work package, ask:

1. Is the tool available and appropriate for this system and task?
2. Are the inputs authorized, representative and sufficiently complete?
3. Is the proposed action within the agreed permission boundary?
4. Can reviewers reproduce the relevant validation?
5. Are exceptions, dependencies and unresolved risks documented?
6. Has the accountable owner accepted the evidence?
7. Is there a tested recovery procedure if the change produces an unexpected result?

Use the answers to make a release decision. If the evidence is incomplete, narrow the scope or return the work for correction rather than lowering the acceptance standard.

Make AI assistance part of a controlled migration

The strongest migration plan connects automation to specific business outcomes and clear responsibilities. It explains what may be automated, what requires review and what evidence is needed before a change moves forward.

Begin with a bounded workstream, establish a baseline and evaluate the complete effort, including review and rework. Expand only when the accepted results justify doing so.

© 2026 SAPSOL Technologies LLC | All Rights Reserved | www.sapsol.com

On October 19, SAP published “The Gap That No LLM Can Close”, explaining why large language models (LLMs) and predictive models for structured business data address different problems. SAP had previously announced TabPFN-3.5 Plus availability in SAP AI Core on September 15, 2026. For SAP-driven enterprises, these developments present an opportunity to revisit where AI can create measurable value—and where preparation is still required.

Key takeaways for SAP and ERP leaders

• Different tools solve different problems. LLMs work well with language and knowledge. Tabular foundation models address predictions from structured data.
• High-value applications are operational. Examples include payment-delay prediction, supplier-risk scoring, customer churn and potential upsell identification.
• TabPFN-3.5 Plus is a real SAP AI Core offering. SAP documents classification and regression workflows, deployments and prerequisites.
• Prediction is not autonomous decision-making. A model’s output still needs validation, ownership, access controls and, when appropriate, human review.
• Start with a business KPI, not a model demo. Choose one measurable decision, establish a baseline and test whether predictions lead to better outcomes.

What is tabular AI, and why should SAP teams care?

Enterprise applications hold large amounts of structured data: invoice dates, purchase orders, payment histories, inventory movements, maintenance records, materials, transaction statuses and more. Such data is often organized into rows and columns connected by business identifiers and relationships.

Tabular AI is a broad category of machine learning focused on learning from this structured information. A tabular foundation model is a general-purpose model designed to support multiple prediction tasks without requiring a wholly separate, bespoke model-building effort for each use case.

Consider a finance team that wants to understand which receivables are likely to become overdue. An LLM might summarize a customer’s correspondence or explain credit policy. A tabular prediction model can instead evaluate patterns from labeled historical transactions and associated features to estimate future outcomes. These functions complement one another; neither automatically replaces sound business rules.

What did SAP announce in September and October 2026?

TabPFN-3.5 Plus in SAP AI Core

In its September 15 announcement, SAP said TabPFN-3.5 Plus from Prior Labs became available to SAP customers through SAP AI Core. SAP described the model as supporting predictions on structured business data with reduced traditional training and preprocessing effort, including mixed data types and missing values.

The SAP Help Portal documents classification and regression use cases, deployment requirements, supported input limits and example requests. It states that teams need an SAP AI Core instance and the extended service plan to use the generative AI hub. Model availability and contractual conditions should be verified for the customer’s environment.

A wider strategy for structured business predictions

In its October 19 article, SAP highlighted the role of tabular foundation models alongside LLMs and referenced its SAP-RPT model family, SAP Knowledge Graph and Prior Labs. The strategic idea is straightforward: businesses need models that understand their structured operational context, not only assistants that generate text.

This does not mean that every company can immediately connect a model to any ERP table and obtain reliable forecasts. The choice of target, quality of historical labels, time ordering, data access, privacy rules and business validation remain critical.

Five potential SAP and ERP use cases

1. Predict late customer payments

Accounts receivable teams could investigate whether payment history, invoice characteristics, customer segments and order patterns help flag invoices that deserve earlier review. The goal would be to prioritize collectors’ work, not to automatically penalize customers.

Useful measures: precision of high-risk alerts, time spent building worklists, collection effort per account and change in overdue balances.

2. Identify supplier and procurement risks

Procurement teams may be able to examine delivery history, order variability, lead times and quality outcomes to spot suppliers requiring investigation. Any system-generated risk label should be checked against current contract terms and real-world conditions before a sourcing decision is made.

Useful measures: missed delivery alerts, false positives, days of disruption prevented and buyer response time.

3. Improve inventory and demand decisions

Manufacturers and distributors can evaluate whether historical transactions, product patterns and operational features support better early-warning signals for stockouts or excess inventory. Tabular predictions can complement existing planning methods rather than displace enterprise planning controls.

Useful measures: forecast error, stockout frequency, inventory carrying costs and planner intervention rates.

4. Detect customer churn and upsell opportunities

Sales operations teams may combine transactional and account-level information to assess where proactive account engagement is warranted. Such models should be evaluated carefully for bias, stale records and misleading proxies.

Useful measures: alert accuracy, account-retention impact, opportunity conversion and whether recommendations help rather than overwhelm sales teams.

5. Support maintenance and operational triage

In asset-intensive operations, historical service patterns and transaction data may support supervised prioritization of cases for engineering review. Safety-critical recommendations should never bypass engineering controls or authorized human judgment.

Useful measures: triage time, precision of risk categorization, avoidable work orders and verified decision quality.

Tabular AI versus traditional machine learning and LLMs

No method is universally superior. SAP’s release positions tabular foundation models as a promising way to reduce some model-development overhead, but procurement decisions should be based on workload-specific tests and current documentation rather than marketing superlatives.

What should a company check before its first pilot?

1. Define a decision. Pick a question such as “Which invoices are likely to be late?” and identify the person accountable for acting on predictions.
2. Identify approved data sources. Map relevant SAP and non-SAP fields, ownership, permission boundaries and sensitive data.
3. Build a credible historical evaluation. Separate past and future periods to avoid data leakage. Compare performance with simple business rules and existing models.
4. Verify SAP AI Core prerequisites. Confirm region, availability, licensing, quotas, technical integration and information-security requirements.
5. Measure business outcomes. Track precision, recall or prediction error alongside operational measures such as avoided rework or faster review.
6. Begin with human-reviewed recommendations. Add write-back or automatic intervention only after approvals, audit trails, exception handling and rollback procedures are proven.

Why data and process readiness matter more than model selection

A sophisticated model does not compensate for incorrect master data or a poorly defined decision process. Many AI pilots fail to deliver operating value because no one owns the outcome, historical records contain inconsistent meanings, or the organization has no clear route from prediction to action.

A practical assessment should therefore look at data quality, integration architecture, process ownership, access controls and measurable business KPIs. These preparations also benefit SAP modernization programs that may later adopt more advanced automation and analytics.

How SAPSOL can support an enterprise AI readiness discussion

SAPSOL Technologies provides SAP and enterprise technology consulting, data management, cloud and integration capabilities. Depending on the client’s environment and confirmed scope, those disciplines can support a readiness assessment, integration planning, data preparation and design of a controlled AI proof of concept.

For organizations evaluating SAP-based AI initiatives, a useful starting point is a limited pilot: define the business problem, validate data suitability, test model performance against existing approaches and present a clear management decision before expanding.

Learn more about SAPSOL’s solutions or explore the Agentic AI Implementation Cost Estimator for adjacent automation-planning considerations. The estimator is not a quotation for TabPFN model usage.

Frequently asked questions

Is TabPFN-3.5 Plus available through SAP?

Yes. SAP announced its availability to SAP AI Core customers in September 2026. Deployment depends on the documented prerequisites and model availability in the relevant environment.

Does tabular AI replace SAP Joule or generative AI?

No. Models that predict from business tables and models that work with language serve different needs and can be combined within governed enterprise processes.

Can tabular AI guarantee a better forecast?

No. Performance depends on data quality, representativeness, changing business conditions, task definition and validation. Compare candidates against real baselines before making ROI claims.

Should predictions directly update ERP records?

For an initial pilot, human-reviewed decision support is usually safer. Any automated action requires explicit authorization, robust testing, monitoring and exception controls.

Conclusion: enterprise AI must become decision-ready

The most useful question for SAP leaders is not “Which AI model is newest?” It is “Which decision could we improve, with evidence, using data we already control?” Tabular AI broadens the options for answering that question. Organizations that combine structured predictions with reliable processes, governance and human judgment will be better positioned to turn AI experiments into operational value.

Official references: SAP News, October 19, 2026; SAP News, September 15, 2026; SAP Help Portal: TabPFN-3.5 Plus.

At SAPSOL Technologies, we see these questions as part of a broader SAP modernization discussion. An AI agent cannot compensate for poorly governed master data, fragile integrations or unclear process ownership. This guide explains the October 2026 SAP announcements and turns them into a realistic evaluation framework for CIOs, SAP teams, finance leaders, operations managers and HR executives.

Key takeaways for enterprise buyers

• SAP Connect 2026: SAP highlighted Joule Work, Joule Assistants, Joule Agents and the SAP Business AI Platform as components of its autonomous-enterprise strategy. Source: SAP, October 6, 2026.
• Use cases are specific: SAP has described scenarios in supply chain, procurement, finance, HR and asset operations; capabilities and rollout dates vary.
• Pricing requires action-level estimates: SAP lists 0.02 AI Units per agent action for SAP-delivered autonomous enterprise agents in 2026. AI Units are not a quoted US-dollar amount, and a workflow can involve multiple actions. Source: SAP Business AI pricing.
• Governance remains essential: Human approvals, least-privilege access, data quality, testing and audit logs should be designed before execution rights are granted.
• Plan together with SAP modernization: For covered SAP Business Suite 7 core applications, mainstream maintenance continues through December 31, 2027; optional extended maintenance is available through 2030 under SAP’s terms.

What changed at SAP Connect in October 2026?

On October 6, SAP introduced its latest vision of the Autonomous Enterprise and demonstrated how Joule Work and Joule Assistants can support business outcomes across functions. SAP described an architecture in which assistants and agents draw on business context, established authorizations and audit trails rather than operating as unrestricted general-purpose chatbots.

That distinction matters. Asking an AI tool to summarize a supplier contract is different from authorizing software to create a purchase order, update a maintenance request or recommend a collections action against an ERP record. The second category requires reliable system context, access controls, approval rules and a way to investigate errors.

On October 8, SAP detailed expanded supply chain assistants and agents. The announced examples include planning exception analysis, logistics issue resolution, manufacturing responses and maintenance-request support. SAP said general availability for those new capabilities is planned for Q4 2026, so organizations should confirm their own entitlement, product edition and rollout status rather than assume every demonstration is already available. Read SAP’s supply chain announcement.

Joule Work vs. Joule Assistants vs. Joule Agents: What’s the difference?

Important: These components are related, not interchangeable, and their capabilities do not all carry the same licensing or availability terms. SAP’s October overview of Joule Work and SAP Business AI Platform is a useful starting point; validate the product documentation and contract for your landscape.

Five SAP Joule agent use cases worth examining

1. Supply chain: resolve exceptions faster

SAP’s October supply chain announcement describes a Supply Chain Planning Assistant that can help teams examine exceptions and their downstream effects. It also discusses logistics issue resolution and coordination among planning, manufacturing and fulfillment. A sensible pilot is a recommendation-only workflow: detect an exception, retrieve the authoritative planning data, present options and log the planner’s decision. Only then consider controlled automation of lower-risk steps.

Measure: mean time to identify an exception, planner handling time, rework rate and percentage of recommendations accepted. Availability note: new announced capabilities had planned Q4 2026 general availability.

2. Finance: prioritize collections and support review

At SAP Connect, SAP presented a case in which an Accounts Receivable Assistant can help finance teams prioritize collections based on risk and business context. Separately, SAP’s October finance update described expanded AI assistance for consolidation, disclosures and governance. These are promising decision-support areas, but they should not bypass credit policies, posting controls or approval matrices. Official finance announcement.

Measure: time to prioritize worklists, exceptions requiring manual research, escalation accuracy and days-sales-outstanding changes where attributable. Control: keep payment release and sensitive journal approvals with authorized personnel.

3. Procurement: reduce manual preparation, not oversight

In SAP’s October 6 announcement, Novartis described a pilot of a Joule Sourcing Assistant. That is an example of a customer pilot, not evidence that every procurement workflow is generally available or fully automated. A credible starting use case is to summarize sourcing information and assemble supplier comparison packs while buyers retain final award authority. SAP Connect announcement.

Measure: sourcing analysis cycle time, completeness of evidence and reduction in repetitive document handling. Control: no autonomous supplier selection, contractual commitments or purchasing approvals without explicit policies.

4. HR and staffing: support skills decisions

SAP’s October 12 SuccessFactors release describes a direction toward agentic AI and better use of workforce data. Organizations could evaluate AI assistance for skills matching, routine HR navigation and preparation of workforce-planning analysis. But employment decisions demand heightened care around data privacy, fairness, explanation and human oversight.

Measure: administrative time per request, data completeness and recruiter or HR-partner satisfaction. Control: do not allow an agent to make unsupervised hiring, firing, compensation or sensitive employee decisions.

5. Oil and gas, utilities and asset-intensive operations: prepare maintenance action

For energy and asset-intensive companies, the relevant opportunity is not a generic chatbot. It is an agent that can interpret an approved equipment signal, check maintenance history and propose a service request for a qualified engineer’s review. SAP’s October supply chain announcement discusses new Asset Operations Assistant capabilities for initiating, screening and simulating maintenance requests.

A possible SAPSOL-supported architecture would combine sound SAP asset data, governed integration and clearly defined human authorization. This is an illustrative implementation pattern, not a claim that SAPSOL or its customers have already deployed it. Read more about SAPSOL’s oil and gas solutions.

Measure: triage time, duplicate work requests, time to maintenance decision and the number of unsafe recommendations caught during testing.

How much do SAP Joule agents cost in 2026?

SAP describes a commercial model with Base AI, Premium AI and custom-built AI. Base AI covers foundational capabilities included with applicable standard SAP cloud subscriptions, while Premium AI is governed by AI Units; custom solutions can also involve separate development and runtime consumption. The exact commercial terms should be checked with SAP because product scope and contracts differ.

For SAP-delivered autonomous enterprise agents in 2026, SAP’s current published rate is 0.02 AI Units per agent action. An action is a step in the agent’s work, not necessarily an entire user request. If a business task requires five agent actions, the metered consumption would be 0.10 AI Units per task at that rate, before considering other services.

Illustrative planning example: 3,000 tasks per month × 5 actions per task × 0.02 AI Units per action = 300 AI Units per month for the agent actions in this simplified scenario. This is not a dollar quote. Actual cost depends on contracted AI Unit pricing, workloads, additional AI services, SAP editions, data consumption and applicable infrastructure or integration costs. SAP says AI Units are purchased in annual pools and unused units expire after 12 months. Review SAP’s official pricing and its October 2026 commercial model guide.

Before funding a pilot, ask for: (1) a list of agent actions per workflow; (2) expected task volume; (3) the percentage of tasks needing human review; (4) integration and implementation costs; and (5) the owner of monthly usage monitoring. For broader project scoping, SAPSOL also offers an Agentic AI Implementation Cost Estimator.

What are the risks of deploying SAP AI agents?

An agent that can take actions in an enterprise system creates a different risk profile from a read-only assistant. These are the controls we would prioritize:

• Excessive permissions: limit every agent identity to the smallest set of approved actions. Separate read-only analysis from writes, approvals and payments.
• Incorrect or stale business context: verify master data ownership, document freshness, API semantics and record-level access before relying on a recommendation.
• Prompt injection and untrusted content: treat external documents, emails and tool outputs as data rather than instructions. Restrict tools, validate parameters and isolate sensitive operations.
• Weak auditability: capture who initiated the task, the data sources used, the proposed action, approvals, execution result and exception route.
• Runaway consumption or automation: set action and spending limits, escalation thresholds, pause/kill-switch behavior and periodic entitlement review.
• Regulated decisions: require appropriate human oversight and legal review for personal, employment, financial or safety-critical actions.

NIST’s AI Risk Management Framework resources provide a useful independent reference for governance, evaluation and monitoring. SAP also describes AI Agent Hub enhancements as part of its governance direction; individual features should be verified for the actual deployment.

A practical 90-day SAP Joule pilot roadmap

1. Days 1–15 — Choose one bounded process. Select a high-volume, measurable task with a clear owner. Record baseline handling time, exception rate and current approval steps.
2. Days 16–30 — Inspect the data and integrations. Identify the authoritative SAP and non-SAP systems, required APIs, roles, sensitive fields and change-approval boundaries.
3. Days 31–45 — Validate availability and costs. Check the exact Joule capability, edition, geography, service entitlements and expected AI Unit consumption before configuring the workflow.
4. Days 46–60 — Run in recommendation mode. Test with realistic cases, misleading inputs, missing data, policy conflicts and unauthorized-action attempts. Log outcomes.
5. Days 61–75 — Pilot supervised execution. Allow only approved low-risk actions with human review, strong logging, a rollback procedure and an owner responsible for stopping the pilot.
6. Days 76–90 — Evaluate and decide. Compare against baseline, investigate failures, review full implementation costs and decide whether to expand, redesign or stop.

Useful pilot KPIs include: minutes saved per case, verified recommendation quality, number of policy exceptions, action success rate, manual overrides and total agent actions consumed. Avoid treating a vendor demo as a proven ROI forecast.

How does SAP’s 2027 maintenance deadline affect AI plans?

Organizations still using covered SAP Business Suite 7 core applications should connect their agent roadmap with ERP transformation decisions. SAP’s published commitment is mainstream maintenance through December 31, 2027, followed by optional extended maintenance through December 31, 2030 under its terms. It is not correct to say every SAP ECC system simply stops working in January 2028. See SAP’s maintenance strategy.

The practical question is where AI integrations should live as applications change. Prefer documented APIs and upgrade-stable extension patterns where applicable, inventory dependencies before migration, and avoid designing a new agent around a soon-to-be-retired custom interface. For related architecture guidance, read How SAP BTP Helps Enterprises Modernize Without Rewriting the Core.

Frequently asked questions about SAP Joule agents

Are SAP Joule agents generally available in October 2026?

Some Joule and business AI capabilities are already available, while others are undergoing rollout, early adoption or planned release. SAP indicated Q4 2026 general availability for the newly described supply chain capabilities. Always check the specific product, edition, region and current release documentation.

Are Joule Work, Joule Assistants and Joule Agents the same product?

No. They refer to different parts of SAP’s AI experience and execution architecture. Joule Work is the user-facing work and orchestration layer, assistants organize role or process support, and agents perform specialized bounded tasks.

Does SAP Joule come free with SAP?

Some foundational Base AI features are included with applicable SAP cloud subscriptions. Premium AI features and agents can require AI Units and separate entitlements. Do not assume access or zero cost without checking the agreement.

Can Joule agents interact with non-SAP applications?

SAP has described cross-application and agent-to-agent integration approaches, but actual connectivity depends on supported interfaces, authorization design, product configuration and commercial terms. Evaluate each integration at the transaction boundary.

Can Joule agents replace business users or SAP consultants?

They can assist with selected analysis and process tasks, but accountability for business decisions, system changes, compliance and exception handling still needs named human owners. Outcomes depend on process design and actual performance in the customer’s environment.

Where SAPSOL can help

The biggest early wins usually come from linking business problems with ERP architecture, trusted integrations, data quality and governed implementation. SAPSOL’s relevant services include SAP consulting, SAP BTP and integrations, cloud and data modernization, security and SAP staffing for delivery teams. A responsible first step is to select a narrow use case, establish the controls and calculate the expected operational benefit before committing to a broad rollout.

Next steps: Assess your organization’s AI and agentic AI readiness, estimate the implementation scope with the SAPSOL cost estimator, or contact SAPSOL Technologies to discuss an evidence-led SAP AI pilot.

Sources and further reading

• SAP News Center — SAP Puts the Autonomous Enterprise to Work (October 6, 2026)
• SAP News Center — Joule Assistants and Agents for Supply Chain (October 8, 2026)
• SAP News Center — Joule Work and SAP Business AI Platform (October 8, 2026)
• SAP News Center — SAP SuccessFactors 2H 2026 (October 12, 2026)
• SAP — Business AI Pricing and AI Units
• SAP Support — SAP Business Suite 7 Maintenance Strategy
• NIST — AI Risk Management Framework Resource Center

Editorial note: SAP trademarks belong to their respective owners. SAPSOL’s planning frameworks and suggested pilot metrics are editorial recommendations, not representations that every described feature is generally available or that any specific result is guaranteed. Product and pricing details should be checked at implementation time.

This is where SAP Business Technology Platform (SAP BTP) has played an important role. In 2026, SAP positions SAP BTP capabilities as core components of the broader SAP Business AI Platform. The architectural principle remains highly relevant: extend and connect enterprise systems without turning every new requirement into a modification of the ERP core.

For organizations running SAP S/4HANA or other SAP applications, that approach can reduce technical debt, simplify upgrades, and create a more flexible foundation for future innovation.

Why Core Customization Becomes a Modernization Problem

Traditional SAP landscapes often accumulate years of custom code, point-to-point integrations, enhancements, and business-specific logic. Many of these changes solve genuine requirements, but over time they can make the environment harder to maintain.

The challenge is not customization itself. The challenge is tightly coupling every customization to the core system.

When custom logic is embedded directly into the ERP core, organizations may face more regression testing, more complicated upgrades, greater dependency on legacy objects, and slower adoption of new capabilities. SAP’s clean-core strategy addresses this by encouraging lifecycle-stable extensions and the use of released interfaces wherever possible.

What “Clean Core” Means in Practice

A clean core does not mean eliminating every extension or forcing every organization to use a completely standard process. It means making deliberate architectural choices about where custom capabilities should live.

SAP supports both on-stack and side-by-side extensibility. Side-by-side extensions run outside the SAP S/4HANA core and communicate through released APIs and business events. This separation allows the extension and the ERP system to evolve more independently.

For many transformation programs, this creates a practical middle ground: preserve the stability of the system of record while still giving the business room to innovate.

How SAP BTP Supports Modernization Around the Core

1. Connect SAP and Non-SAP Systems Without More Point-to-Point Complexity

Modern enterprises rarely operate a single application landscape. SAP systems often need to exchange data with CRM platforms, supplier networks, data platforms, industry applications, cloud services, and custom software.

SAP Integration Suite provides integration capabilities for connecting applications, data, APIs, events, and processes across SAP and third-party environments. A governed integration layer reduces the need to create another tightly coupled connection every time a new system is introduced.

This is especially useful when an organization wants to modernize its surrounding architecture while keeping the core ERP stable.

2. Build Side-by-Side Extensions Instead of Modifying the Core

Some business requirements are genuinely differentiating and cannot be solved through standard configuration alone. The question is where that custom logic should run.

With side-by-side extensibility, custom applications can run on the platform and access SAP business data through supported remote APIs and events. The custom application has its own lifecycle and can be scaled or changed without embedding all of its code inside SAP S/4HANA.

This model is useful for scenarios such as custom user experiences, supplier or customer portals, specialized approval processes, industry-specific workflows, and applications that combine SAP data with external data sources.

SAPSOL’s broader SAP solutions and services can be structured around this principle: keep system-of-record processes stable while placing differentiated capabilities in the right architectural layer.

3. Modernize Processes Without Rebuilding the ERP

Not every transformation requirement needs a new ERP implementation. Many organizations first need to improve how work moves across existing systems.

Integration, application development, workflow automation, and event-driven processes can be used to modernize selected business journeys without rewriting the underlying transaction system. This allows teams to address high-value process gaps incrementally instead of tying every improvement to a large core transformation program.

The result is a modernization roadmap that can be delivered in smaller, governed increments.

4. Create a Better Foundation for Data and AI

AI initiatives depend on access to reliable business context, governed data, and connected processes. A fragmented landscape makes that difficult.

SAP’s current platform direction brings together application development, integration, data, AI, process context, and governance through SAP Business AI Platform. For enterprises with existing SAP investments, this means modernization decisions made around integration and extensibility can also improve the foundation for future AI-enabled applications and workflows.

The important architectural point is that AI should not become another isolated layer. It should be connected to governed business processes and data with clear security and lifecycle controls.

Modernization Without a Full Rip-and-Replace: A Practical Example

Consider an organization running a stable SAP ERP environment with several custom integrations and a manual supplier onboarding process.

A traditional response might be to modify the core application again or wait until the next major ERP transformation. A cleaner approach could be to keep the existing core transaction process intact, create a side-by-side onboarding experience, integrate it with SAP through supported interfaces, automate selected approvals, and expose only the business data required by the new process.

The business gets a modern experience while the ERP core remains more stable and easier to manage.

This does not eliminate the need for future S/4HANA upgrades or core transformation where they are justified. It separates business innovation from the assumption that every innovation requires a core modification.

When SAP BTP Is the Right Fit

SAP BTP-oriented modernization is particularly relevant when an organization wants to:

• Reduce custom code and technical debt in the SAP core.
• Connect SAP and non-SAP applications through a governed integration layer.
• Create new applications or user experiences around existing SAP processes.
• Modernize selected workflows before a larger ERP transformation.
• Adopt a clean-core strategy while preserving necessary business differentiation.
• Build a stronger foundation for data, automation, and AI initiatives.

When the Core Still Needs to Change

Clean-core architecture should not be confused with avoiding necessary ERP work.

If the current system is unsupported, heavily constrained, unable to meet regulatory requirements, or structurally incapable of supporting the target operating model, a core upgrade or transformation may still be required. SAP BTP is not a substitute for fixing an unsuitable system of record.

The correct decision depends on architecture, business process requirements, data dependencies, integration patterns, and the lifecycle of the existing SAP environment.

A Practical Starting Point for SAP Leaders

Before choosing tools, organizations should map the current landscape and separate requirements into three groups:

1. Core processes that should remain stable and standardized.
2. Extensions that create differentiated business value but should be decoupled where practical.
3. Integrations and automations that connect processes across SAP and non-SAP systems.

From there, teams can identify which customizations should remain, which should be redesigned, and which can move to a side-by-side or integration-led architecture.

This assessment is often more valuable than starting with a product checklist because it connects the platform decision to business outcomes and long-term maintainability.

How SAPSOL Can Support the Modernization Journey

SAPSOL Technologies works with organizations across SAP implementation, integration, cloud, application support, data, and modernization initiatives. A practical SAP BTP modernization engagement can begin with an architecture and customization assessment, followed by a prioritized roadmap for clean-core extensions, integrations, and process improvements.

For organizations already operating complex SAP landscapes, the goal should be controlled modernization: reduce unnecessary coupling, preserve critical business processes, and create an architecture that can evolve without repeatedly adding risk to the core.

Organizations evaluating their next step can also review SAPSOL’s SAP application maintenance and support services and cloud services as part of a broader modernization strategy.

Conclusion

SAP modernization does not need to be defined as a choice between leaving the existing landscape untouched and replacing everything at once.

By using clean-core principles, governed integration, and side-by-side extensibility, enterprises can modernize around the core while protecting the stability of mission-critical SAP processes. SAP BTP capabilities—now positioned within SAP Business AI Platform—provide an architectural foundation for that approach.

The strongest modernization programs start with the business process and architecture, not the technology label. The objective is a landscape that is easier to extend, easier to integrate, and better prepared for future change.

Further Reading from SAP

• SAP: Core platform capabilities and SAP BTP
• SAP Integration Suite
• SAP Developer: Clean Core Extensibility Principles
• SAP Developer: Side-by-Side Extension on SAP BTP