The Data Problem SAP Customers Cannot Outrun

Data has been a challenge for decades. Twenty years ago, it surfaced as multi-year harmonization projects after an acquisition or divestiture revealed the records did not match. The cadence was forgiving. A major data event arrived every few years, providing ample time to grind through the cleanup before the next one. That cadence is gone. Artificial intelligence, agentic systems, accelerating M&A, sanctions-driven divestitures, and the economics of cloud storage have compressed the timeline. The core problems remain the same—provenance, quality, heterogeneity, volume—but the window to resolve them has narrowed from years to weeks. The consequences now propagate through machine learning models, agentic decisions, and regulatory filings rather than a slow quarterly close.

A New Challenge with a Long History

In a recent conversation with SAPinsider, Steele Arbeeny, CTO of SNP, framed the issue in terms any SAP architect or CIO will recognize. Three pressures stand out.

Provenance and relevance. Arbeeny’s first question is not how much data customers have, but where it came from and whether it remains relevant to current operations. The reasoning is operational. If an enterprise trains its AI models on data that does not represent how the business operates today, the model will learn the wrong behavior. It will learn how the business operated a
decade ago or optimize for a divested subsidiary.

For SAP customers carrying a decade of acquisitions, a technical migration that drags forward irrelevant history will produce models that confidently optimize for a business that no longer exists.

Heterogeneity across the landscape. The challenge changes shape for large enterprises. Mature enterprise landscapes suffer from multiple ERP systems from multiple vendors, including different SAP versions and lines of business operating in separate environments. As Arbeeny noted, if data is spread across 20 systems from 20 vendors, building a consistent view is impossible. This explains why a consolidated customer view or an agentic order-to-cash workflow stalls the moment it hits a system boundary.

The volume question. Smaller enterprises face a different version of the same problem regarding how much history to keep. The default answer is often to keep everything, which Arbeeny argues
is usually a mistake. In a cloud-billed world, the volume, value, and velocity of the original big data debate return as tangible line items on the AI and infrastructure bill.

Beneath these three pressures lies a less visible cost that vendor marketing rarely acknowledges. Bad data creates an ongoing drag on operating tempo. Arbeeny ticked through the symptoms. Execution on M&A takes longer because line-of-business data is commingled and requires precise surgery to separate. Closing cycles are extended. Analytics degrade because the hundreds of  attributes SAP exposes on a customer master are mostly blank in practice. Users cannot filter customers based on preferred currency, payment terms, product lines, or region. Each of these symptoms is a business KPI dressed up as a data hygiene issue.

Addressing the Challenge

The instinctive response is to treat data cleanup as a project or a one-time push during the next S/4HANA cutover. Arbeeny argues this framing gets enterprises into trouble because data drift is continuous.

The alternative is to treat business data agility as a continuous operating discipline supported by tooling that spans the full migration lifecycle. Platforms in this category, such as SNP’s Kyano, package the work into repeatable phases. Analysis benchmarks the landscape against peers.

Execution completes migrations and consolidations. An ongoing phase handles decommissioning, archiving, and cloud data integration so unneeded data remains accessible for compliance without polluting the systems feeding AI.

Two design choices matter operationally. First, ensuring that only the historical data the business needs is brought forward while what is left is decommissioned to lower-cost storage. Old data remains accessible for compliance and audits but sits outside mainline storage and does not feed model training. Second, the use of pre-built, business-aware content outperforms generic ETL solutions. Generic pipelines cannot reconcile a vendor master across three SAP systems and a legacy manufacturing execution system.

The less marketable truth is that no platform fixes this independently. The data itself must be ready. Enterprises build that readiness through what Arbeeny called “microtransformations,” which include cleaning up unattributized customers, untangling commingled entities, and retiring redundant non-SAP systems. This work must happen ahead of the next disruption rather than during it.

Planning for the Next Disruption

The projects that once arrived every year or every decade now arrive several times a year, often in parallel and increasingly in response to external forces. An enterprise cannot quickly execute a divestiture unless the underlying data is already separable. Arbeeny recounted a recent call with a US auto-parts manufacturer facing an emergency divestiture. The customer noted they wished they were not dealing with the issue but had no choice. It was not a platform upgrade they could delay.

The multi-year, single-cutover transformation model does not match the cadence of external disruption modern SAP estates must absorb. The work must start before the trigger event occurs. Arbeeny likened the preparation to getting healthy for a marathon, noting that the act of planning matters more than the plan itself.

What This Means for SAPinsiders

Data is not a new challenge for organizations operating in the enterprise space today. However, while these challenges may go back decades, they are just as relevant to the way that organizations operate today. That provides three areas which should be a focus for every SAP architect, CIO, and data leader for the year ahead.

Treat data readiness as a precondition for AI. The most quoted statistic in enterprise AI is that roughly two-thirds of projects fail. This is rarely a model problem. As Arbeeny noted, failures almost always trace back to an incomplete problem statement or bad data. For SAP customers, the AI roadmap and the data roadmap are identical. Before approving the next agentic pilot, SAPinsiders must know which datasets accurately represent current operations and which legacy datasets are quietly feeding model training because they were never decommissioned. If the answers are unclear, the pilot is set up to fail.

Reframe the S/4HANA migration as the first move in a continuous program. The aerospace customer Arbeeny described executed the ECC-to-S/4HANA conversion first to address immediate pain. The second-order goal was always to consolidate non-SAP plant maintenance and bill-of-materials systems into a unified estate. That consolidation delivered measurable downstream benefits in safety, compliance, closing cycles, and the elimination of intercompany reconciliations. SAPinsiders building business cases must explicitly include these second-order moves, such as non-SAP retirement, master data cleanup, and selective decommissioning. Do not let the conversation end at the S/4HANA cutover date. Evaluate toolsets based on whether they can carry the program past the initial migration without requiring re-platforming.

Build agility now for the next disruption. Internally driven projects can be deferred. Externally driven events like sanctions-driven divestitures, emergency M&A, regulatory shifts, or pandemic-class events cannot. Because change will never be as slow as it is today, the practical response is to begin microtransformations immediately. Clean up the unattributized customer master, untangle commingled legal entities, retire redundant non-SAP systems, and stand up the decommissioning discipline that keeps old data out of new models. Use the current planning cycle to inventory which microtransformations are achievable in the next six to 12 months. That inventory separates the organizations that will absorb the next disruption from the ones that will be absorbed by it.

Key Takeaways

The data challenges SAP customers face today are not new in kind, but they are new in cadence and consequence. AI training, agentic decisioning, accelerating M&A, and sanctions-driven divestitures are now propagating the cost of bad data through the business in weeks rather than years, and the Big Bang remediation model that worked for a decade no longer fits the timeline.

• Train models on data that reflects how the company runs today. Don’t optimize for a company that no longer exists. The AI roadmap and the data roadmap have to be the same roadmap, or the next agentic pilot will end up being less than successful.
• Treat the move to SAP S/4HANA as the moment to selectively bring forward only the history the business actually needs, decommission the rest to lower-cost storage, and begin consolidating non-SAP systems that erode close cycles, safety, and analytics selectivity.
• Build agility today because the next disruption is just around the corner. Internally driven projects can be deferred, externally driven ones cannot and they punish enterprises whose data is not separable. Start master data cleanup, legal-entity untangling, non-SAP retirement, and decommissioning discipline in advance of the trigger event rather than during it.

About SNP

SNP is the global technology platform leader and trusted partner for companies seeking unparalleled data-enabled transformation capabilities and business agility. SNP’s Kyano platform integrates all necessary capabilities and partner offerings to provide a comprehensive software-based experience in data migration and management. Combined with the BLUEFIELD® approach, Kyano sets a comprehensive industry standard for restructuring and modernizing SAP-centric IT landscapes faster and more securely while harnessing data-driven innovations.