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