BW (Business Warehouse) has powered SAP analytics for decades. But it was built for a different era: smaller data volumes, centralized data warehouses, batch ETL cycles. Modern analytics demand real-time data, federation across platforms, and rapid user self-service. Organizations are modernizing BW workloads, but there's no one path. Some migrate entirely to Datasphere. Some maintain hybrid BW/Datasphere architectures. Some focus on query optimization before considering migration. Some lift BW into SAP Business Data Cloud as a private cloud edition and publish BW data as data products while they modernize. The five scenarios below show where BW modernization pays for itself; they are composites of common patterns, and their figures illustrate scale, not measured client results. Some focus on Datasphere migration for new workloads. Some focus on planning modernization where transformation is especially valuable. Some focus on hybrid approaches where legacy BW and modern Datasphere coexist. These scenarios show that modernization is a journey, not a flag flip—and that's how it should be.
Modernization reality: The scenarios here work because they take a pragmatic approach. Not "rip and replace BW"—that's a multi-year pain. But "new workloads go to Datasphere, query optimization happens on legacy BW, and over time the balance shifts." Modernization that respects the operating model and the maintenance burden of legacy systems.
Scenario 1
BW to Datasphere Migration: Phased Approach for a Global Manufacturer
Global manufacturers often have large, complex BW estates built over 15+ years. Full rip-and-replace migration is risky. Phased migration to Datasphere by business domain reduces risk and spreads investment.
The Problem
Manufacturing company runs 80+ BW InfoCubes supporting 500+ reports. BW maintenance consumes 6 FTEs. Query performance is degrading as data volumes grow. New analytics requests require weeks of BW modeling work.
Your global manufacturing company has operated BW since 2005. Over 20 years, 80+ InfoCubes have been built. 500+ reports depend on them. A dedicated team of 6 FTEs maintains the cubes: creating new dimensions, optimizing aggregates, tuning queries. BW query performance is degrading as data volumes grow (5 years of history = 15 billion transaction rows). A new analytics request (e.g., "show me product profitability by customer by region") requires weeks of BW modeling: design the InfoCube, build aggregates, test performance. Users want self-service analytics, but BW's modeling curve is too steep. Meanwhile, you're considering an S/4HANA migration, and moving reporting from BW 7.5 to SAP Analytics Cloud looks like either a full replacement (too risky for 500 reports) or a hybrid that keeps BW running, which for BW 7.5 works only until its maintenance ends (end-2027 mainstream, end-2030 extended, 2033 at most in Business Data Cloud). Neither is attractive on its own.
The Solution
Phased Datasphere migration by business domain. Maintain BW for legacy reports. New analytics build on Datasphere. Over 24-36 months, shift 80% of reporting to Datasphere.
Instead of "BW replacement project," adopt a phased modernization strategy. One option today is to lift BW into SAP Business Data Cloud as a private cloud edition first, so the Data Product Generator can publish BW history as data products that the new Datasphere models reuse while domains move. Year 1: Sales Analytics (highest usage, least complex). Datasphere replicates data from ERP, builds semantic model for sales orders, customers, products. SAC replaces legacy BW Sales InfoCubes. 120 reports migrate, BW cube retired. 6-month engagement. Year 2: Supply Chain Analytics. Datasphere adds procurement, inventory, production data. New semantic model joins supply chain dimensions. 150 legacy BW reports are replaced and enhanced with new capability (real-time visibility). BW cubes retired. Year 3: Finance and HR Analytics. The most complex domains, but by then the team understands the pattern. By end of year 3, 80% of reporting has shifted to Datasphere. BW goes into maintenance mode (4 FTEs freed for other priorities). New analytics requests are built on Datasphere (weeks become days). User self-service analytics are possible for the first time because Datasphere semantic models are more intuitive than BW dimensions/hierarchies.
BW maintenance effort falls as domains retire. New analytics requests turn around faster. User self-service improves.
Efficiency: In a phased program like this, BW maintenance shrinks to the remaining legacy InfoProviders, and freed BW specialists move to Datasphere work. Speed: New analytics requests move from BW modeling cycles to Datasphere semantic models, which turn around faster once the domain model exists. Adoption: Self-service on governed Datasphere models tends to widen the user base beyond BW report consumers.
Prerequisites
BW landscape documented. Migration sequence planned (highest impact / lowest risk domains first). S/4HANA plan is clear.
Current BW landscape is documented (InfoCube count, report count, usage by domain)
Migration sequence is agreed (which domain first, which last, what's the business priority)
Datasphere is available and deployment team is trained
Replication flows (or other integration) from ERP to Datasphere are set up
SAC is deployed and can be the new reporting layer
Governance and semantic modeling capability is in place (or can be hired)
Scenario 2
BPC to SAC Planning Migration: Financial Planning Transformation
Planning tools (BPC, legacy planning engines) are ripe for modernization. Moving to SAC Planning enables real-time, collaborative planning that traditional systems can't provide.
The Problem
Finance uses SAP BPC for annual budget and rolling forecast. Cycle time is 8 weeks. Models are rigid (changing assumptions requires IT). Collaboration is email-based (versions are unclear).
Your finance team uses SAP Business Planning and Consolidation (BPC) for annual budget and rolling forecast. Process is: Finance publishes budget template (in Excel), departments download, fill in, email back. IT consolidates (manually reconciling spreadsheets), publishes revised template for next round. Consolidation takes 6-8 weeks total. When an assumption changes (e.g., revenue growth rate), the team rebuilds models manually. Collaborative planning is impossible: multiple people working on same Excel sheet creates version chaos. Rolling forecast updates happen quarterly, not monthly, because the manual cycle is too slow. The team wants rolling monthly forecasts (more accurate), but the planning tool can't support the velocity needed. And SAP's maintenance for BPC 10.1 on BW 7.5 runs to the end of 2027 (SAP's BPC strategy adds optional extended maintenance to the end of 2030).
The Solution
Migrate to SAC Planning. Web-based collaborative interface. Real-time scenario modeling. Automatic aggregation of department plans. Rolling monthly cycles become feasible.
SAP Analytics Cloud Planning replaces BPC and Excel. Finance departments access a web-based planning interface (no Excel). Each department inputs their plan directly. SAC aggregates the department plans automatically (no email ping-pong). When an assumption changes (revenue growth rate), the model updates automatically across all department plans. Collaboration is real-time: Finance can see department edits in real-time, ask questions via SAC comments, make approvals directly in SAC. The planning cycle drops from 6-8 weeks to about 2 weeks. Rolling monthly forecast becomes feasible (the 2-week cycle repeats monthly). Predictive planning (ML models suggesting forecast values based on historical trends) can be enabled, making planning more data-driven.
Planning cycles compress (here, from about 8 weeks to 2). Monthly rolling forecasts become feasible. Forecasts reflect more recent actuals.
Speed: Moving from spreadsheet-driven BPC cycles to SAC Planning removes much of the manual collection and reconciliation work, which is where the weeks are lost. Frequency: With faster cycles, a quarterly rolling forecast can become monthly, so forecasts reflect more recent actuals. Adoption: A single web-based planning interface usually raises participation compared with circulating spreadsheets.
Prerequisites
BPC or legacy planning system is being used. Finance team wants to accelerate planning cycles. Datasphere is available.
Current planning system (BPC, legacy planning, or Excel-based) is documented
Planning requirements are clear (what needs to be planned, what levels of detail, what governance)
SAC Planning is available and deployment is planned
Datasphere is live with planning-ready data model (actuals, dimensions)
Finance team has agreed that faster planning cycles add business value
Migration path from BPC (or legacy system) to SAC Planning is supported by IT
Scenario 3
Hybrid BW/4HANA + Datasphere: Coexistence for Historical Analytics
Organizations don't always need to retire BW. For read-heavy historical analytics, BW can coexist with Datasphere for new interactive analytics.
The Problem
Organization has 50 years of historical financial and sales data in BW. Regulatory requirements mandate 7-year history. New analytics need real-time data and interactive exploration.
Your organization has been operating for 50 years. Regulatory requirements for financial reporting mandate keeping 7-year history accessible. BW contains 50 years of summarized data: monthly/annual balances, key metrics, regulatory reports. This historical BW data is read-only (no changes, no interactive exploration needed). But new analytics users want real-time order data, customer behaviors, product trends—all interactive, all self-service. BW's summarized historical data isn't useful for interactive exploration (it's too aggregated). You need both: historical BW (for compliance and regulatory reporting), plus new interactive analytics on current data (for operational and business intelligence).
The Solution
Keep BW for historical (7+ years) and regulatory reporting. Build Datasphere for current (rolling 3-year) interactive analytics. Federate both in Datasphere semantic model.
Instead of migrating all BW data to Datasphere (expensive and unnecessary), adopt a hybrid model. BW remains the source of truth for historical data older than 3 years and for regulatory reporting (immutable archive). New Datasphere instance handles current 3-year rolling window of transaction data (orders, customers, products, actuals). When a user asks for a "5-year trend," Datasphere combines both: the current 3 years from its own transaction data, the older 2 years from BW, read through remote tables on BW InfoProviders (or, if BW runs in Business Data Cloud, from BW data products replicated by the Data Product Generator). Semantic layer unifies the two: "revenue" is defined once and applies to both Datasphere and BW sources. Users experience unified analytics without worrying about where data came from. BW maintenance burden goes down (reading only, not modeling new requirements). Datasphere grows over time. The hybrid can run for as long as your BW release is maintained (BW/4HANA: to at least 2040, with release upgrades).
SAP Datasphere (current analytics, 3-year rolling)
Federated semantic model (unified definitions)
SAP Analytics Cloud (unified reporting layer)
Expected Impact
BW maintenance stays flat (no new work). Interactive analytics enabled on current data. Long-term history stays available for regulatory reporting.
Efficiency: A hybrid like this postpones a full BW migration: BW effort shrinks to archival operations, and new interactive analytics run on Datasphere (3-year rolling) without disrupting the historical data. Compliance: Regulatory reporting still runs on BW (immutable, tested process). New exploratory analytics run on Datasphere. User experience: Users see unified analytics across the full time horizon without worrying about data sources.
Prerequisites
BW historical data is stable (no changes). New analytics requirements are for current data. Regulatory requirements are clear.
BW contains mature historical data that's rarely changed or updated
Regulatory reporting requirements are documented (how far back, what data, what reconciliation)
New analytics requests are primarily for current (rolling 1-3 year) data
Datasphere is available for current data modeling
Federation capabilities between BW and Datasphere are available
Semantic modeling can create unified definitions across BW and Datasphere sources
Scenario 4
BW Query Optimization: From Overnight Reports to Interactive Dashboards
Before considering BW migration, query optimization can unlock dramatic performance improvements and buy time before a replacement.
The Problem
Key BW reports take 45 minutes to run. High-cardinality dimensions (product, customer) are causing query explosion. Users have given up on interactive exploration.
Your finance team has a key monthly reporting suite in BW that generates consolidated P&L across 50+ business units. The report currently takes 45 minutes to complete. It runs overnight because it's too slow for interactive use. Users have given up on "what-if" analysis because every query takes 30+ minutes. The root cause: BW is aggregating across 500K products and 100K customers in real-time (cardinality explosion). Your actual report only needs 50 business units and 200 product families, but the BW design is querying the full grain. Before funding a BW replacement for performance reasons alone, query optimization might be the answer.
The Solution
BW query optimization: the right granularity, variables, and hierarchy levels, plus aggregates and indexes where BW runs on a non-HANA database. The overnight report becomes interactive, and the work buys time within the release's support window.
Query optimization starts with analysis: profile which characteristics drive the query's cost (usually high-cardinality ones like product, customer, GL account). Report at the level the business needs (business units and product families, not products), and use variables and hierarchy levels to restrict what the query reads. If BW runs on a non-HANA database, build aggregates at that level and keep indexes and database statistics current. On SAP HANA (BW on HANA, BW/4HANA), aggregates are not supported and would not help, so the work goes into query and model design instead, for example a provider loaded at the summarized level. Result: the overnight report becomes an interactive query, so users can drill and slice without waiting. Investment: a few months of focused tuning, far less than a replacement program. Bonus: optimization buys time to plan the next step, but only within your release's support window (BW 7.5: mainstream maintenance to the end of 2027, extended maintenance to the end of 2030).
SAP Stack
BW query optimization (query design, variables, modeling; aggregates and indexes on non-HANA databases) + SAC for visualization
Legacy BW (optimized)
Aggregates (non-HANA databases only)
Variables and hierarchy levels (restrict what queries read)
Indexes and statistics (non-HANA databases only)
SAP Analytics Cloud (for modern visualization)
Expected Impact
Report run times drop from batch to interactive. Interactive analytics become feasible. Replacement can be planned calmly, within the support window.
Performance: Tuning a large query to report at product-family level, with variable filters, can turn an overnight job into an interactive one. Analytics enablement: Once queries answer quickly, users move from batch reporting to interactive exploration and start asking new questions. Timeline: A replacement planned in a hurry can move to a calmer date, but for BW 7.5 not beyond the end of its maintenance (end-2027 mainstream, end-2030 extended, or 2033 in Business Data Cloud).
Prerequisites
BW reports exist and performance is slow. Root causes of slowness are identifiable (usually dimension cardinality). Optimization expertise is available.
BW queries with performance problems are identified and prioritized
Query execution analysis is available (which dimensions are causing cardinality explosion)
Aggregation strategy can be designed (what levels of summarization are needed)
BW optimization and query tuning expertise is available (or can be contracted)
Database administration support is available (indexes and statistics on non-HANA databases)
SAC is available for visualization (connecting to optimized BW queries)
Scenario 5
Content Lifecycle Management: Cleaning 15 Years of BW Objects
Large BW installations accumulate technical debt: obsolete cubes, unused reports, duplicate objects. Systematic cleanup frees maintenance effort and simplifies the landscape.
The Problem
BW system has 200+ InfoCubes, 500+ queries, accumulated over 15 years. 40% of objects are unused. Maintenance team spends time on zombie objects that nobody uses.
Your organization has operated BW for 15 years. During that time, 200+ InfoCubes were created, 500+ queries were built. But adoption patterns changed: new business models emerged, old analyses were replaced, departments merged. Today, your analytics team estimates 40% of BW objects are unused (no query in 12 months, no scheduled reports). But nobody knows for sure. Maintenance team still patches, backs up, and updates these zombie objects. When security patches are needed, they have to be tested on 200 cubes instead of 120. When performance optimization happens, 40% of the optimization work is on objects nobody uses. If you could identify and retire unused objects, the maintenance burden would drop roughly in line with what you retire.
The Solution
Systematic content lifecycle management. Audit object usage. Retire unused objects. Archive retirement documentation. Reduces maintenance burden in proportion to what is retired.
Implement content lifecycle management discipline. Audit BW system: which cubes are actually queried, which reports are actually scheduled, which objects have dependencies. Identify unused objects (no activity in 12 months). Archive documentation of retired objects (might need them later, but don't need to maintain them daily). Physically retire: remove unused cubes, retire unused queries, delete orphan objects. Maintenance team effort drops: 200 cubes to maintain becomes 120 cubes. Security patches are faster. Performance optimization is faster (less to tune). Bonus: with a cleaner landscape, new maintainers can understand the system more quickly. Turnover becomes less problematic.
Maintenance effort drops with every retired object. System becomes more manageable. Knowledge transfer becomes easier.
Efficiency: A systematic content audit often finds InfoProviders and queries with no recent use; retiring them shortens patch and test cycles and frees maintenance capacity. Knowledge: New team members could understand the system more quickly because the landscape was cleaner and more purposeful. Turnover impact was reduced. Modernization readiness: Cleaner BW landscape makes future migration to Datasphere more tractable. Cubes are fewer and better understood, which also shrinks the scope of a conversion or a move into Business Data Cloud.
Prerequisites
BW landscape is mature and likely contains unused objects. Usage tracking is available or can be implemented. Governance for retirement is agreed.
BW system is mature (10+ years) and likely to contain accumulated technical debt
Usage tracking capabilities are available (or can be added)
Dependency analysis between cubes, queries, and reports can be performed
Retirement governance is defined (who decides what to retire, how is it documented)
Knowledge management system exists (where to archive retirement documentation)
Maintenance team commitment to ongoing lifecycle management is obtained
Success pattern
What makes BW modernization scenarios succeed
All five scenarios share a pattern. They recognize that BW modernization is a spectrum, not a binary (on/off). Some move to Datasphere domain by domain (scenario 1). Some do hybrid (scenario 3). Some optimize the current BW to buy time within its support window (scenario 4). Some rethink planning tooling (scenario 2). Some clean up the landscape first (scenario 5). They succeed because they match the modernization path to the organization's risk tolerance, timeline, and technical capability. They recognize that "rip and replace" is risky and expensive. But "do nothing and maintain forever" is also expensive. Smart organizations modernize pragmatically: new workloads go modern, old workloads are optimized or rationalized, and the balance shifts over time.
They're pragmatic, not dogmatic
No universal "migrate all to Datasphere" mandate. Different workloads follow different paths based on risk/benefit.
They reduce risk through phasing
Phased migration (domain by domain) is less risky than big bang. Hybrid (coexistence) is less risky than replacement. Optimization buys time to plan a replacement, within the release's support window.
They address maintenance burden
All scenarios reduce the pain of maintaining aging infrastructure. Whether migration, optimization, cleanup, or planning modernization, they all ease the maintenance burden.
They enable new capability over time
Whether Datasphere self-service, SAC Planning collaboration, or optimized BW interactive exploration, they all move organizations toward better analytics capability.
From scenarios to delivery
Move from "I recognize my challenge" to "here's our plan"
You've read the scenarios. Now identify which modernization path most resonates with your BW landscape: phased migration, planning modernization, hybrid, optimization, or cleanup. Then link into the deeper content hubs below to understand the technical and organizational steps for your chosen path.