Executive Clarity · AI & Autonomous Enterprise

SAP BW Modernization in SAP Business Data Cloud: The Lift-Shift-Innovate Roadmap

SAP Business Data Cloud creates a more gradual path for BW customers: stabilize the runtime, expose selected BW data as governed products, and modernize use cases at the pace of business value.

Diagram showing the three-stage SAP BW modernization path: Lift, Shift and Innovate.

SAP BW modernization has changed from a replacement project to a portfolio transition

For years, many SAP Business Warehouse discussions were reduced to a binary choice: convert to SAP BW/4HANA or rebuild elsewhere. SAP Business Data Cloud introduces a more gradual path. The central idea is to protect useful BW investments, expose selected BW data as governed data products and move individual use cases toward SAP Datasphere, SAP Databricks and SAP-managed content at different speeds.

The source deck describes this as Lift, Shift and Innovate. That sequence is useful because it separates three decisions that are often mixed together:

  • Where should the existing BW runtime operate?
  • How should valuable BW data and semantics become accessible to modern workloads?
  • Which legacy use cases should be replaced, redesigned or retired?

Treating those as separate decisions makes the program more manageable. It also prevents a technical migration from being mistaken for business-data modernization.

What SAP Business Data Cloud adds to the BW conversation

SAP BW has accumulated years of business logic, InfoProviders, transformations, authorizations and reporting semantics. That is both its value and its burden. A modern architecture must preserve what is useful without carrying every historical object forward indefinitely.

SAP Business Data Cloud positions BW data inside a broader business data fabric. The official modernization path allows eligible SAP BW or SAP BW/4HANA systems to be lifted into the private-cloud component of SAP Business Data Cloud. Selected InfoProvider data can then be exposed through the Data Product Generator into the object store of SAP Datasphere. From there, teams can model and consume the data in SAP Datasphere, share it to SAP Databricks for AI and machine-learning scenarios, and progressively replace selected BW flows with data products and intelligent applications.

The architectural shift is important: the BW system no longer has to be the only place where the data creates value.

The three stages: Lift, Shift and Innovate

1. Lift: stabilize the existing BW investment in an SAP-managed environment

The lift stage moves an eligible BW landscape into the private-cloud component associated with SAP Business Data Cloud. The aim is operational continuity with lower infrastructure responsibility and access to the BDC modernization path.

A lift is not the same as modernization. The models, custom code, process complexity and report portfolio still exist. What changes is the operating environment and the ability to connect the landscape to new services.

For SAP BW NetWeaver customers, the source deck highlights an important option: a customer may be able to lift BW 7.5 without first completing a full BW/4HANA conversion, subject to eligibility and commercial terms. That can reduce the pressure to execute an intermediate conversion purely to access newer data-product capabilities. It does not remove the need for a long-term target architecture.

2. Shift: expose selected BW assets as data products

The shift stage uses the Data Product Generator. SAP documentation describes it as a toolset that extracts data from BW InfoProviders into local tables in the SAP Datasphere object store. A data subscription controls the replication. The resulting table can be shared to another Datasphere space for modeling and can be turned into a custom data product for catalog-based consumption.

This changes the sequencing of value. A customer does not have to wait until the entire BW modernization program is finished before using selected historical data in a new analytics or AI scenario.

The shift stage should be selective. Not every InfoProvider deserves to become a data product. The best candidates have clear ownership, active business use, understood semantics, acceptable data quality and a defined consumer.

3. Innovate: replace selected legacy use cases with a modern data and AI architecture

The innovate stage is where the business case is created. Teams can combine BW data with SAP and non-SAP sources, create new models in SAP Datasphere, use SAP Databricks for data science and machine learning, and adopt SAP-managed data products or intelligent applications where they fit.

The long-term direction is not to keep every BW workflow forever. It is to reduce dependence on the legacy runtime as specific use cases move to the target architecture. Some may be replaced by standard SAP-managed content. Some may be redesigned as customer-managed data products. Some may be retired because usage analysis shows that they no longer justify their cost.

What the Data Product Generator does—and what it does not do

The Data Product Generator is strategically important, but executives should avoid treating it as an automatic migration factory.

It can:

  • create subscriptions from supported BW InfoProviders;
  • replicate selected data into local tables in the SAP Datasphere object store;
  • support delta-based updates for eligible objects and configurations;
  • enable data-product creation and governed discovery;
  • make BW data available for new modeling, analytics and AI/ML scenarios.

It does not automatically redesign the business model, rationalize the report portfolio, resolve poor data quality or translate every custom transformation into a target-state service. Those remain program decisions.

Current SAP documentation lists minimum supported versions including SAP BW 7.5 SP24 or higher, SAP BW/4HANA 2021 SP04 or higher and SAP BW/4HANA 2023. The BW system must be in the supported private-cloud component and the relevant SAP Business Data Cloud services must be provisioned. Embedded BW in SAP S/4HANA is not supported by the Data Product Generator. These details are release-sensitive and must be checked during planning.

The modernization decision tree

A practical program begins by classifying the landscape.

Path A: SAP BW 7.5 on HANA with a viable runway

The organization can assess a lift to the private-cloud component, prepare the required support-package level, expose selected data products and modernize use cases gradually. A BW/4HANA conversion may remain an option, but it is no longer automatically the first step for every customer.

Path B: SAP BW/4HANA with significant active investment

The priority is usually to preserve the active model portfolio while adding data-product and open-ecosystem capabilities. The lift can create an SAP-managed operating model, while shift and innovate reduce future dependence on the BW runtime.

Path C: Older BW versions or non-HANA databases

Additional database and application upgrades may be required before the Data Product Generator path is available. The sequence should be designed as one program rather than a chain of disconnected technical projects.

Path D: Embedded BW

Embedded BW requires a different decision because the Data Product Generator is not available for that deployment. The organization must distinguish embedded operational analytics from stand-alone enterprise data-warehouse use cases.

Path E: A report portfolio with low usage and high duplication

The first move should be rationalization, not migration. Usage, business criticality, data volume, ownership and regulatory retention should determine what is carried forward.

The business case: do not confuse potential savings with guaranteed savings

The internal source deck contains directional TCO categories and potential reduction ranges. Because the material is marked draft and internal, this article does not publish those ranges as market benchmarks. They should be treated as hypotheses to validate in each customer landscape.

A defensible business case should quantify:

  1. Current infrastructure, database and operations cost.
  2. Basis administration, patching, monitoring and upgrade effort.
  3. ETL and data-model maintenance effort.
  4. Report and object usage, including redundant or dormant content.
  5. Cost of the target BDC capacity services and transition overlap.
  6. Migration, testing, remediation and change-management effort.
  7. Value from faster access to data, new AI/ML scenarios and reduced time to change.

The overlap period is especially important. Modernization often increases cost temporarily because the legacy and target environments coexist. A credible plan shows when those costs begin to fall and which legacy components can actually be decommissioned.

A twelve-month modernization roadmap

Quarter 1: Assess and classify

Run a technical and usage assessment. Identify active InfoProviders, reports, data volumes, interfaces, custom code, planning dependencies and retention obligations. Segment use cases into retain, expose, redesign, replace and retire.

Quarter 2: Establish the platform and first data products

Prepare the eligible BW environment, provision the required BDC services and implement the first controlled subscriptions. Select a small number of high-value data products with clear owners and consumers.

Quarter 3: Deliver two new use cases

Use the exposed BW data in at least two scenarios: one analytics or planning use case in SAP Datasphere and one advanced analytics or AI/ML use case where appropriate. Measure time-to-data, model reuse, operating cost and user adoption.

Quarter 4: Commit the decommissioning sequence

Decide which legacy data flows, queries, models or infrastructure components can be replaced and on what schedule. The roadmap should show not only what is being added, but what will be removed.

The executive principle

Modernize BW at the speed of business value, not at the speed of a technical deadline.

The strongest programs use the private-cloud lift to create room, the data-product shift to release value early and the innovation stage to reduce legacy dependence. The weakest programs stop after the lift and call the hosting change a transformation.

Executive takeaway

The decision is not whether to adopt another technology label. The decision is whether the operating model, architecture, governance and value case are strong enough to turn the technology into repeatable business outcomes. That is the standard sapperment applies: separate the vendor promise from the management decision, and make the path to execution explicit.

Frequently asked questions

Does SAP Business Data Cloud require every BW customer to convert to BW/4HANA first?

Not in every case. Current SAP material describes a path for eligible SAP BW 7.5 systems to be lifted and connected to the Data Product Generator without an immediate BW/4HANA conversion. Version, support-package and commercial prerequisites must be validated.

What is the Data Product Generator?

It is an SAP toolset that creates subscriptions from supported BW InfoProviders and places the data in local tables in the SAP Datasphere object store, enabling governed data-product and downstream analytics or AI use cases.

Can embedded BW use the Data Product Generator?

No. Current SAP Help documentation states that the Data Product Generator is not available for embedded BW systems such as embedded BW in SAP S/4HANA.

Does zero-copy mean that no data is ever replicated?

No. The BW Data Product Generator can replicate BW data into the Datasphere object store. Zero-copy sharing applies to selected downstream sharing patterns, such as Delta Sharing, and should not be confused with the initial BW-to-object-store provisioning step.

What should be modernized first?

Start with actively used, high-value BW assets that have clear semantics and owners, and with use cases that benefit from being combined with new data or AI capabilities. Retire low-value content before moving it.

Call to action

Use this article as an executive briefing before your next architecture, transformation or investment decision. For board-level framing, transformation challenge sessions and independent decision support, visit Executive Clarity.

Sources and evidence

  1. SAP source deck: “BW Modernization in SAP Business Data Cloud,” October 2025, especially the Lift–Shift–Innovate model, Data Product Generator prerequisites, decision tree and target architecture diagrams.
  2. SAP, “Modernize SAP BW with SAP Business Data Cloud.” https://www.sap.com/products/data-cloud/sap-bw-migration.html
  3. SAP Help Portal, “Data Product Generator for SAP Business Data Cloud.” https://help.sap.com/docs/SAP_BW4HANA/ed919380760a44388ab90e6bb3e7480a/4efcb40d03334381a6111fd9d270b7f0.html
  4. SAP Help Portal, “Configuring the Data Product Generator.” https://help.sap.com/docs/SAP_BW4HANA/ed919380760a44388ab90e6bb3e7480a/8586340e2bf647d783e4cf506559c25a.html
  5. SAP, “SAP Business Warehouse in Business Data Cloud.” https://www.sap.com/products/data-cloud/business-warehouse.html

Source integrity note

The uploaded BW deck is marked internal/draft. This article uses its architecture and terminology but excludes unverified commercial claims and internal planning assumptions. Release-sensitive prerequisites were checked against current SAP Help and product documentation.

Structured data