SAP Data Intelligence After 2026: Your Options for Pipelines, Replication and ML

SAP Data Intelligence on-premise leaves mainstream maintenance on 31 December 2026 and the Cloud edition on 31 December 2028, according to SAP Notes 3407393 and 3423165. Replication flows have a direct successor in SAP Datasphere. Custom pipelines and machine learning scenarios do not, so each needs its own destination decision.

That split is the whole story. Most estates treat SAP Data Intelligence as one product to be replaced. In practice it hosts three quite different kinds of workload, and only one of them has a like-for-like home.

#Why the SAP Data Intelligence Decision Is Due Now

What this means for you: if you run SAP Data Intelligence on-premise, the maintenance window closes in weeks rather than years, so the decision is already late rather than early.

SAP has published end-of-maintenance dates for both editions. SAP Note 3407393 covers the on-premise product, with mainstream maintenance ending on 31 December 2026. SAP Note 3423165 covers SAP Data Intelligence Cloud, with mainstream maintenance ending on 31 December 2028. Both dates are restated in an SAP Community post on safeguarding the transition to SAP Business Data Cloud and SAP Datasphere, published in 2026.

The commercial signals came earlier. SAP stopped selling new SAP Data Intelligence Cloud subscriptions, while letting existing subscribers renew up to the maintenance end date. From 1 July 2024, SAP removed SAP Data Intelligence from new Cloud Platform Enterprise Agreement (CPEA) contracts, the credit-based agreement many customers use to consume SAP's cloud services.

SAP's stated direction is consistent across these sources: innovation goes into SAP Datasphere and SAP Business Data Cloud, and customers are expected to move workloads there over time. SAP has not, however, promised feature parity for every capability. That gap is where the real planning work sits.

#What SAP Data Intelligence Actually Does

What this means for you: before you choose a destination, you need an honest inventory of what your tenant runs, because the product name hides three different jobs.

SAP Data Intelligence is SAP's container-based platform for data integration, orchestration and machine learning, which grew out of SAP Data Hub. Work is built as graphs in its Modeler: chains of operators that read, transform and write data. Operators can be prebuilt connectors or custom code in Python, Go or JavaScript, and the on-premise edition runs on a Kubernetes cluster the customer operates.

In most estates, the graphs fall into three groups.

The Metadata Explorer adds a fourth, smaller role: profiling, cataloguing and data lineage across connected systems. It rarely drives the decision, but it is easy to forget until a governance team asks where the lineage went.

#The Options at a Glance

What this means for you: match each workload group to an option separately; a single answer for the whole tenant is usually wrong for at least one group.

The table points to the conclusion most estates reach: replication goes to SAP Datasphere, and the rest goes wherever the surrounding architecture already points.

#Replication: The One Workload With a Direct Successor

What this means for you: if replication dominates your tenant, the migration is a rebuild of known flows, which is the most predictable part of this decision.

SAP Datasphere, SAP's cloud data-warehousing and business-data-fabric service, offers replication flows that SAP describes as providing 1:1 coverage for SAP Data Intelligence replication flows, with an expanded scope. That is not a coincidence. Datasphere replication flows are built on the Replication Management Service, the same component SAP Data Intelligence used for replicating from ABAP-based systems.

Replication is the only part of SAP Data Intelligence that SAP has given a like-for-like home.

The practical work is still real. Each flow has to be recreated, connections re-established, initial loads rerun and change data capture behaviour verified against the source. Reconciliation matters most: row counts and key totals between the old target and the new one, for every flow, before the old one is switched off.

Where SAP Datasphere is also becoming the home for your BW estate, the replication decision should be taken alongside the BW one. Our SAP BW to Datasphere decision guide covers that route choice, and the SAP Datasphere definition explains where the service now sits in SAP's portfolio.

#Pipelines: Where Parity Runs Out

What this means for you: custom pipelines are where most of the effort hides, because SAP has said plainly that complex pipeline scenarios do not have direct feature parity.

SAP's own transition guidance acknowledges that complex pipeline scenarios in SAP Data Intelligence have no direct equivalent in SAP Datasphere or SAP Business Data Cloud, and need a scenario-specific approach. That covers the graphs teams are usually proudest of: multi-step orchestration, custom Python operators, file-based integrations, and bespoke retry and alerting logic.

There are three realistic homes for them.

#SAP Datasphere Transformation Flows and Task Chains

Where a pipeline's job is to transform SAP data on its way into Datasphere, transformation flows and task chains can often absorb it. This is the cleanest route when the pipeline is SAP-to-SAP and the transformation logic can be expressed in SQL or the graphical editor.

#SAP Integration Suite

Where a pipeline is really process integration, such as event-driven messages between applications rather than bulk data movement, SAP Integration Suite is the more natural home. Moving those graphs there separates application integration from analytical data movement, which most estates should have done anyway.

#A Non-SAP Orchestrator or Data Platform

Where pipelines span many non-SAP systems, depend heavily on Python, or feed a lakehouse rather than an SAP target, an orchestrator such as Apache Airflow, or the pipeline tooling of a platform such as Databricks, is often the better fit. Our guide to choosing between Snowflake and Databricks covers that platform decision, and our data engineering practice is where the rebuild itself happens.

#Machine Learning: Decide by Where Your Data Scientists Work

What this means for you: the ML Scenario Manager has no named like-for-like successor, so the destination should follow your data science team rather than the SAP roadmap.

SAP's broader direction for AI over SAP data runs through SAP Business Data Cloud, which SAP launched in February 2025, and its partnership with Databricks for data science on SAP data products. For teams already working in that direction, rebuilding ML scenarios close to SAP Business Data Cloud is coherent.

For teams whose data scientists already work in a non-SAP platform, the simpler answer is usually to move model training and serving there and feed it governed SAP data. What matters is not the tool but the controls around the model: versioning, monitoring, approval and rollback. Those are set out in our guide to running predictive models in production, and they apply whichever platform hosts the model.

A model that moves platform without its monitoring and approval trail has not migrated. It has been reset.

#Metadata and Lineage: The Part Teams Forget

What this means for you: if anyone relies on the Metadata Explorer for profiling, cataloguing or lineage, that capability needs its own destination, or it disappears quietly when the tenant is switched off.

The Metadata Explorer is rarely why a team bought SAP Data Intelligence, which is exactly why it is easy to lose. Data stewards use it to profile datasets, publish them to a catalogue and trace lineage from a report back to its source. When the graphs move and the tenant is decommissioned, those records go with it unless someone has planned where they land.

There are two sensible homes. Where SAP Datasphere becomes the SAP data layer, its own catalogue and lineage features are the natural successor for SAP-side metadata. Where the estate already runs an enterprise catalogue across SAP and non-SAP platforms, profiling and lineage should move there, so that governance does not split along vendor lines.

Either way, export what matters before the switch-off: the glossary terms, the published datasets, the profiling rules and any lineage that auditors or data owners have referred to. Lineage is cheap to keep and expensive to reconstruct, and the reconstruction usually falls on the people who had nothing to do with the migration.

#When Staying Put Is the Right Call

What this means for you: moving early is not automatically prudent; for some Cloud tenants, a deliberate, dated stay is the lower-risk option.

Staying on SAP Data Intelligence Cloud until a planned move in 2027 or 2028 is defensible when the graphs are stable, the Cloud subscription is renewable to the maintenance date, and the destination platform is not yet settled. Rebuilding twice, first into an interim platform and then into the long-term one, costs more than waiting a year with a dated plan.

It is the wrong call in three situations. The first is the on-premise edition, where mainstream maintenance ends on 31 December 2026 and the customer also carries the Kubernetes operating burden; check what your support agreement provides after that date before relying on it. The second is any estate where SAP Data Intelligence feeds regulatory or financial reporting, because an unmaintained integration layer under audited numbers is a risk most audit committees will not accept. The third is a tenant whose original builders have left, because the knowledge needed to migrate is already eroding.

The other trap is replicating today's sprawl. A migration that rebuilds every graph exactly as it is will carry a decade of workarounds into a new platform. The deadline is a chance to simplify, not only to relocate.

#Where to Start: A Six-Week Graph Inventory

What this means for you: six weeks of structured inventory turns an anxious deadline into a sequenced backlog with owners.

The three proofs matter more than the inventory spreadsheet. They replace estimates with measured effort for each destination, and they surface the connection, authorisation and network issues that otherwise appear halfway through the migration.

Migrating a backlog of this kind is factory work, with repeatable patterns, parallel running and reconciliation for every flow, which is what our migration factory approach is built for. Our SAP Data Intelligence modernisation service covers the inventory and the destination design, and teams moving an S/4HANA estate at the same time should read our guide to the S/4HANA Migration Cockpit and its limits.

Scope matters here. Six weeks covers the inventory, the destination decisions and three proofs. The migration itself is measured in months for a mid-sized tenant and longer for a large one, and it should be planned that way.

#Frequently Asked Questions

#When does SAP Data Intelligence go out of maintenance?

SAP Note 3407393 sets the end of mainstream maintenance for SAP Data Intelligence on-premise at 31 December 2026. SAP Note 3423165 sets the end of mainstream maintenance for SAP Data Intelligence Cloud at 31 December 2028. Existing Cloud subscribers can renew up to that date, but SAP no longer sells new subscriptions. Check both notes in SAP for Me for the current position before planning.

#What replaces SAP Data Intelligence?

There is no single replacement. SAP Datasphere replication flows provide direct coverage for SAP Data Intelligence replication flows. Complex pipelines have no direct equivalent and move case by case to SAP Datasphere transformation flows, SAP Integration Suite or a non-SAP orchestrator. Machine learning scenarios usually move to SAP Business Data Cloud or to the platform the data science team already uses.

#Can SAP Datasphere run SAP Data Intelligence pipelines?

Partly. SAP Datasphere replication flows are built on the same Replication Management Service as SAP Data Intelligence replication, so replication scenarios move across closely. Custom graphs with Python operators, multi-system orchestration or bespoke error handling do not have direct feature parity, according to SAP's transition guidance, and need to be redesigned rather than copied.

#Should we wait for SAP Business Data Cloud before migrating?

For SAP Data Intelligence Cloud, a dated wait can be sensible if your graphs are stable and your target platform is undecided, because rebuilding twice costs more. For the on-premise edition, waiting is hard to justify, since mainstream maintenance ends on 31 December 2026 and the customer also operates the Kubernetes cluster underneath it.

#How long does a SAP Data Intelligence migration take?

A structured inventory, destination decisions and one proof per destination typically take around six weeks. The full migration of graphs, with parallel running and reconciliation for every flow, usually takes several months for a mid-sized tenant and longer for a large one. Retiring unused graphs first is the quickest way to shorten the programme.

---

Unolabs is a Data and AI first engineering consultancy, headquartered in the United Kingdom with engineering operations in Pune and active engagements across the UK, Australia, and Hong Kong. We help enterprises build the architectural foundation for autonomous AI execution — governed data platforms, semantic intelligence, and agentic systems that enterprises can stand behind.

If you are weighing where your SAP Data Intelligence workloads should go before maintenance ends, book a discovery call and we will work through it with you.