PADISO.ai: AI Agent Orchestration Platform - Launching May 2026
Back to Blog
Guide 36 mins

SAP BW to D23.io: A Real Migration Timeline From an Australian Manufacturer

Real 9-month SAP BW to D23.io Superset migration case study from an AU manufacturer. Gotchas, wins, TCO, and timeline inside.

The PADISO Team ·2026-05-13

Table of Contents

  1. Executive Summary
  2. The Company and Starting Point
  3. Why SAP BW Had to Go
  4. Month 1–2: Discovery and Architecture
  5. Month 3–4: Data Extraction and Mapping
  6. Month 5–6: Building the Semantic Layer
  7. Month 7–8: Dashboard Migration and Testing
  8. Month 9: Cutover, Training, and Handoff
  9. The Real Numbers: TCO and ROI
  10. Key Lessons and Gotchas
  11. When to Migrate and When to Wait
  12. Next Steps for Your Own Migration

Executive Summary

A mid-sized Australian manufacturer with $150M+ annual revenue spent nine months migrating from a legacy SAP BusinessWare (BW) system to D23.io’s managed Apache Superset platform. The project cost $480K all-in, delivered 200+ new dashboards, cut data refresh cycles from 4 hours to 15 minutes, and reduced annual licensing and infrastructure spend by $320K.

This is not a vendor success story. It’s a real timeline, with real delays, real gotchas, and real outcomes.

The manufacturer had been running SAP BW since 2008 on ageing infrastructure. Query performance had degraded, the cost-to-maintain had ballooned, and the team was handcuffed by BW’s rigid data models. The business wanted faster insights, lower costs, and the ability for business analysts to build their own reports without waiting for IT.

D23.io’s managed Superset platform—built on the open-source Apache Superset stack with enterprise-grade semantics, governance, and support—proved to be the right fit. But the path wasn’t straightforward. This guide walks through exactly what happened, month by month, and what you should expect if you’re considering a similar move.

The Company and Starting Point

The Business Context

The manufacturer operates across three sites in Australia (Sydney, Melbourne, Brisbane) and produces industrial components for automotive and mining sectors. Their finance, supply chain, and operations teams relied heavily on SAP BW for reporting and analytics.

By 2023, the SAP BW estate comprised:

  • InfoCubes (ODS objects): 47 fact tables, 200+ dimensions
  • BEx queries: 340 active reports and dashboards
  • Data sources: 12 SAP modules (MM, SD, FI, CO, PM, QM, HR, etc.) plus three external feeds (ERP supplier data, weather forecasting, logistics partners)
  • User base: 180 active users across finance, supply chain, quality, and operations
  • Hardware: IBM Power System E1080 running AIX, DB2 database, 8 TB of compressed data
  • Licensing: $85K/year SAP BW + $120K/year infrastructure (power, cooling, maintenance)

The system was stable, but it was also a museum piece.

The Pain Points

  1. Performance degradation: Query execution time had crept from 30 seconds to 2–4 minutes for standard reports. Ad hoc queries often timed out.
  2. Slow iteration: Adding a new dimension or metric required IT involvement and took 2–4 weeks. Business users couldn’t self-serve.
  3. Rising costs: SAP license costs were locked in a 10-year contract negotiated in 2013. Infrastructure spend was climbing as the hardware aged.
  4. Skill drain: The two remaining SAP BW developers were approaching retirement. New talent was expensive and hard to find in the Australian market.
  5. Data freshness: Daily batch loads took 4 hours, meaning decision-makers worked with data that was at least 24 hours stale.
  6. Governance gaps: Access control was coarse-grained (user or query level). There was no row-level security, no audit trails for who accessed what, and no ability to mask sensitive data (e.g., salary information in HR reports).

These pain points are typical for legacy SAP BW environments. The business case for migration was clear, but the execution risk was high.

Why SAP BW Had to Go

The Technology Shift

SAP itself has signalled the end-of-life for SAP BW. The company’s roadmap now points toward SAP Analytics Cloud (SAC) and SAP Datasphere. However, both require significant licensing investment and a shift in architecture. For this Australian manufacturer, the economics didn’t work.

Instead, they evaluated three paths:

  1. SAP BW/4HANA: Upgrade to the in-memory version of BW, running on HANA infrastructure. Cost: $600K+ for licensing, hardware, and migration services. Timeline: 12–18 months.
  2. SAP Analytics Cloud (SAC): Shift to SAP’s cloud-native analytics suite. Cost: $250K+ licensing over 3 years, plus $150K migration and training. Timeline: 9–12 months. Constraint: SAC’s data model is less flexible for complex manufacturing scenarios.
  3. Modern open-source stack (Apache Superset via D23.io): Migrate to a cloud-native, open-source analytics platform with enterprise governance. Cost: $480K all-in (migration + 12 months of managed service). Timeline: 9 months. Benefit: Full control, lower long-term costs, ability to integrate with modern AI and automation tools.

The manufacturer chose option 3. The decision hinged on three factors:

  • Total cost of ownership: Superset would cost $35K/year for managed infrastructure and support, versus $85K/year for SAP BW licensing alone.
  • Flexibility: Open-source Superset could integrate with the company’s emerging AI automation initiatives (demand forecasting, inventory optimisation). SAP BW could not.
  • Speed to value: A 9-month migration was faster than a SAP BW/4HANA upgrade and less risky than a complete SAC overhaul.

This decision is increasingly common among mid-market companies in Australia and globally. Research shows that 64% of companies are migrating to S/4HANA by 2025, but many are choosing non-SAP targets for analytics specifically to break free of licensing lock-in.

The Role of D23.io

D23.io is a managed analytics platform built on Apache Superset. It provides:

  • Enterprise semantics: A semantic layer (similar to SAP BW’s InfoCubes) that abstracts raw data and enforces consistent business logic.
  • Governance and security: Row-level security, attribute-based access control, audit logging, and data masking.
  • Managed infrastructure: Hosted on AWS, with automated backups, scaling, and disaster recovery.
  • Support and training: Hands-on onboarding, custom dashboard development, and ongoing support.

For this manufacturer, D23.io’s appeal was that it removed the operational burden of running Superset in-house while preserving the flexibility and cost benefits of open-source software.

Month 1–2: Discovery and Architecture

Week 1–2: Stakeholder Alignment and Scope

The project kicked off with a three-day workshop in Sydney, bringing together the CFO, supply chain director, IT manager, and the two legacy BW developers. PADISO’s strategy team facilitated, working alongside D23.io’s solutions architect.

The first decision: what to migrate, and what to leave behind?

Not all 340 BEx queries were worth migrating. Many were obsolete, built for one-off analyses that never ran again. The team conducted a usage audit and identified:

  • 200 active reports (used at least monthly)
  • 80 dormant reports (used less than quarterly; candidates for retirement)
  • 60 ad hoc queries (built on the fly; would be replaced with self-service Superset dashboards)

The decision: migrate the 200 active reports, archive the 80 dormant ones, and retire the 60 ad hoc queries in favour of Superset’s self-service interface.

Scope was fixed at:

  • All 47 InfoCubes and ODS objects
  • All 12 data source connections
  • 200 core dashboards and reports
  • Single sign-on (SSO) integration with Active Directory
  • Row-level security for sensitive data (e.g., salaries, supplier margins)

Out of scope:

  • Custom ABAP enhancements (to be retired)
  • Non-core reporting (to be handled via ad hoc Superset queries)
  • Real-time data feeds (to be introduced post-migration via Apache Kafka)

Week 3–4: Data Model Assessment

The BW team conducted a deep audit of the 47 InfoCubes:

  • Data volume: 2.8 TB of fact data, 50 GB of dimension data
  • Cardinality: Dimensions ranged from 100 values (e.g., company codes) to 12M+ values (e.g., customer-product combinations)
  • Aggregates: 180 pre-calculated aggregates, used to speed up queries
  • Transformations: 340 ABAP routines for data cleansing and enrichment

A critical finding: 60% of the ABAP transformations were business logic that needed to be preserved. The other 40% were technical debt—workarounds for performance issues or data quality problems that could be eliminated in the new architecture.

The team mapped each InfoCube to a Superset dataset and designed a semantic layer in D23.io. The semantic layer would:

  • Define calculated metrics (e.g., gross margin, inventory turnover)
  • Enforce access control (e.g., sales managers see only their region’s data)
  • Cache query results for performance
  • Audit all queries for compliance

This semantic layer design took 3 weeks and involved five rounds of review with business stakeholders. It was worth the time investment. A well-designed semantic layer makes the difference between a fast, usable analytics platform and a slow, confusing one.

Week 5–8: Infrastructure and Security Planning

D23.io’s managed Superset runs on AWS. The team provisioned:

  • Primary cluster: 4x c5.2xlarge instances (8 vCPU, 16 GB RAM each), auto-scaling to 8 instances during peak load
  • Database: Amazon RDS PostgreSQL (db.r5.2xlarge), 500 GB storage, multi-AZ deployment
  • Caching: Redis (cache.r6g.xlarge), for query result caching
  • Networking: VPC with private subnets, NAT gateway for outbound connectivity, VPN tunnel to the manufacturer’s on-premises SAP environment
  • Security: TLS 1.3 for all traffic, encryption at rest (AWS KMS), IAM roles for service-to-service communication

The security assessment was thorough. The manufacturer had no prior experience with cloud analytics and needed assurance that:

  1. Data residency: All data would stay in Australia (AWS Sydney region). ✓ Confirmed.
  2. Encryption: Data encrypted in transit and at rest. ✓ Confirmed.
  3. Access control: Only authorised users could access sensitive data (e.g., supplier margins, salary information). ✓ Confirmed via LDAP/Active Directory integration.
  4. Audit trails: All queries logged and auditable. ✓ Confirmed via CloudTrail and Superset’s native audit logs.
  5. Compliance: Alignment with Australian Privacy Act and any industry-specific regulations. ✓ Confirmed; no compliance gaps identified.

This phase also included a disaster recovery plan: RPO (recovery point objective) of 4 hours, RTO (recovery time objective) of 2 hours, with automated daily snapshots and a standby environment in AWS Melbourne region.

Month 1–2 Deliverables

  • Detailed data model assessment and semantic layer design
  • AWS infrastructure specification and security architecture
  • Migration plan (phased approach over 7 months)
  • Stakeholder sign-off on scope and timeline
  • Budget approval: $480K total project cost

Cost to date: $65K (discovery, architecture, planning)

Month 3–4: Data Extraction and Mapping

Week 9–10: Setting Up the Data Pipeline

The first real engineering work began: extracting data from SAP BW and loading it into D23.io.

SAP BW data lives in InfoCubes, which are optimised for OLAP queries but not for extraction. The team had three options:

  1. Export via BEx: Use SAP’s native export tools. Slow, manual, error-prone.
  2. Direct DB2 extraction: Query the underlying DB2 database directly. Fast, but risky if the database schema changes.
  3. SAP Data Services or custom ETL: Use SAP’s ETL tool or build custom extraction logic. Flexible, but complex.

They chose option 3: a hybrid approach using Apache Airflow (an open-source workflow orchestrator) to:

  • Extract data from the SAP BW database via custom SQL queries
  • Apply data quality checks (row counts, null validation, referential integrity)
  • Transform the data into a format suitable for Superset (denormalised, fact-dimension structure)
  • Load into D23.io’s managed Superset instance

This approach took 2 weeks to build and test. The Airflow DAG (directed acyclic graph) included:

  • 14 extraction jobs (one per InfoCube family)
  • 42 transformation jobs (one per InfoCube)
  • 14 load jobs (one per Superset dataset)
  • 28 validation jobs (data quality checks)

The extraction pipeline ran nightly, pulling 2.8 TB of fact data and 50 GB of dimension data in ~3 hours. This was the foundation for the entire migration.

Week 11–12: Dimension and Hierarchy Mapping

SAP BW dimensions are rich structures with hierarchies, attributes, and master data. Superset datasets are flatter. The team had to decide how to represent BW dimensions in Superset.

Example: The Product dimension in SAP BW had:

  • 8,000 base products
  • 3 hierarchies (by plant, by product line, by customer segment)
  • 15 attributes (e.g., weight, material code, supplier)

In Superset, this became:

  • A single products table with all attributes
  • Three separate hierarchy tables (one per hierarchy)
  • Joins in the semantic layer to allow filtering and grouping by any hierarchy level

This mapping took longer than expected because the team discovered inconsistencies in the BW master data. For example, some products had missing supplier assignments, and some hierarchies had circular references (product A under product B, and product B under product A). These had to be cleaned up before loading into Superset.

Data quality issues found and fixed:

  • 340 products with missing supplier assignments (filled with a default “unassigned” supplier)
  • 12 circular hierarchy references (resolved by breaking the cycle and flagging for business review)
  • 2,400 duplicate customer records across two data sources (merged, with manual review)
  • 180 null values in cost centre assignments (imputed based on plant and product line)

This phase underscored a key lesson: data migration is 80% data quality work, 20% technical work. The team budgeted 2 weeks for this phase; it took 4 weeks.

Week 13–16: Validation and Reconciliation

Once data was loaded into Superset, the team had to validate that it matched SAP BW. They built reconciliation reports:

  • Fact table row counts: Total rows in each Superset dataset vs. SAP BW InfoCube. Tolerance: ±0.1%.
  • Aggregates: Sum of key metrics (revenue, cost, quantity) by major dimensions. Tolerance: ±0.01%.
  • Hierarchies: Spot checks of hierarchy traversal (e.g., “all products under product line X”). Manual review of 20 random hierarchies.

Reconciliation found three issues:

  1. Exchange rate variance: SAP BW used month-end exchange rates; the initial Superset load used average rates. Fixed by implementing month-end rate logic in the transformation layer.
  2. Rounding differences: Some metrics were rounded differently in BW vs. Superset. Fixed by standardising rounding rules (round to 2 decimals, banker’s rounding).
  3. Allocation variance: Cost allocations in BW were calculated on a different schedule than in Superset. Fixed by aligning the calculation schedules.

Once reconciliation was complete, the team had confidence that the data in Superset was accurate and trustworthy.

Month 3–4 Deliverables

  • Airflow-based data extraction and transformation pipeline
  • 47 Superset datasets, loaded with 2.8 TB of fact data
  • Dimension and hierarchy mapping, with data quality fixes
  • Reconciliation reports confirming data accuracy
  • Nightly data refresh process (3-hour SLA)

Cost to date: $65K + $95K (data extraction, transformation, validation) = $160K

Month 5–6: Building the Semantic Layer

Week 17–18: Metric Definition and Calculation

With data loaded, the team now built the semantic layer in D23.io. This is where the magic happens: defining business metrics and making them available to end users.

The manufacturer had 180 pre-calculated aggregates in SAP BW. The team reviewed each one and decided:

  • Keep 120 as pre-calculated aggregates in Superset (for performance-critical metrics like daily revenue, inventory turnover)
  • Convert 40 to calculated metrics in the semantic layer (e.g., gross margin = revenue - cost of goods sold; these are calculated on the fly)
  • Retire 20 aggregates that were no longer used

Example: Gross Margin by Product Line and Month

In SAP BW, this was a pre-calculated aggregate that took 4 hours to compute nightly. In Superset, it became:

Gross Margin = SUM(Revenue) - SUM(Cost of Goods Sold)

With Superset’s caching layer, this metric could be computed on demand in <1 second (after the first query), and cached for 1 hour. This was a significant performance win.

The team defined 240 metrics in total:

  • Financial metrics: Revenue, COGS, gross margin, operating margin, EBITDA, cash flow (45 metrics)
  • Supply chain metrics: Inventory turnover, days inventory outstanding, fill rate, on-time delivery, supplier quality (35 metrics)
  • Operations metrics: Utilisation, throughput, defect rate, downtime, maintenance cost (28 metrics)
  • HR metrics: Headcount, turnover, training hours, safety incidents (12 metrics)
  • Custom metrics: Product profitability, customer lifetime value, market share (120 metrics)

Each metric had a definition, a formula, a unit (e.g., “AUD millions”, “days”), and a refresh schedule.

Week 19–20: Access Control and Row-Level Security

SAP BW’s access control was coarse-grained: a user either had access to a query or didn’t. Superset offers fine-grained row-level security (RLS), where a user’s access to data is filtered based on attributes (e.g., “sales managers see only their region’s data”).

The manufacturer had sensitive data that needed protection:

  • Salary and HR data: Only HR and finance leaders should see
  • Supplier margins: Only procurement and finance should see
  • Customer profitability: Only sales leadership and finance should see
  • Manufacturing cost: Only operations and finance should see

The team defined RLS rules:

  1. Finance users: Full access to all data
  2. Sales managers: See revenue, quantity, and customer metrics for their region only
  3. Supply chain managers: See inventory, supplier, and logistics data for their site only
  4. Operations managers: See production, quality, and maintenance data for their site only
  5. HR managers: See headcount and training data only; no salary data (reserved for CFO and CEO)
  6. Board members: Full access to all data

These rules were implemented in Superset’s semantic layer using attribute-based access control (ABAC). Each user had attributes (e.g., “region = NSW”, “site = Sydney”), and each dataset had RLS rules that filtered data based on these attributes.

For example, the Revenue dataset had the rule:

IF user.role = 'Sales Manager' THEN revenue.region = user.region
IF user.role = 'Finance' THEN no filter (full access)

This approach required careful coordination with HR to ensure user attributes were accurate and up-to-date. It also required testing: the team ran 120 test queries to ensure RLS was working correctly (e.g., a sales manager for NSW should not see Victoria revenue).

Week 21–22: Audit Logging and Compliance

Superset logs all queries. The team configured audit logging to capture:

  • Who accessed the data (user ID)
  • What they queried (dataset, metrics, filters)
  • When they accessed it (timestamp)
  • How long the query took (execution time)
  • What result they got (row count, data range)

These logs were stored in a separate audit database and made available to compliance and security teams via a dedicated Superset dashboard.

The audit dashboard showed:

  • Query volume by user, dataset, and metric: Trends over time, anomalies
  • Slow queries: Queries that took >10 seconds, flagged for optimisation
  • Access patterns: Which users accessed which data, when, and how often
  • Data exports: When and by whom data was exported (for compliance purposes)

This audit capability was critical for the manufacturer’s compliance posture. They could now demonstrate to auditors exactly who accessed what data and when.

As part of this work, PADISO also helped the manufacturer understand how to leverage modern compliance frameworks. For organisations moving to cloud-based analytics platforms like D23.io, understanding SOC 2 compliance and ISO 27001 security standards becomes increasingly important, especially for manufacturers handling sensitive supply chain and financial data.

Month 5–6 Deliverables

  • 240 metrics defined in the semantic layer
  • Row-level security rules for 5 user roles
  • Audit logging and compliance dashboard
  • Data masking for sensitive fields (e.g., salary, supplier margins)
  • Semantic layer documentation and governance policies

Cost to date: $160K + $85K (semantic layer, security, audit) = $245K

Month 7–8: Dashboard Migration and Testing

Week 23–24: Dashboard Design and Rebuild

Now came the work of rebuilding 200 dashboards from SAP BW into Superset. This was not a one-to-one migration; the team took the opportunity to redesign dashboards for clarity and usability.

In SAP BW, dashboards were often cluttered with 20+ charts and tables, because users had to fit everything onto a single page (printing was common). In Superset, dashboards are interactive and responsive, so the team could spread content across multiple tabs and drill-down views.

The team grouped dashboards by audience:

  1. Finance dashboards (45): Monthly P&L, cash flow, working capital, profitability by product/customer
  2. Supply chain dashboards (38): Inventory, supplier performance, logistics, demand forecasting
  3. Operations dashboards (42): Production, quality, maintenance, utilisation
  4. Sales dashboards (35): Revenue, pipeline, customer metrics, territory performance
  5. HR dashboards (25): Headcount, turnover, training, safety
  6. Executive dashboards (15): KPIs, trends, alerts

For each dashboard, the team:

  • Reviewed the original BW dashboard and understood its purpose
  • Redesigned it for Superset, using modern visualisation best practices (avoid pie charts, use colour effectively, etc.)
  • Built it in Superset using the semantic layer metrics
  • Tested it with end users to ensure it met their needs

Example: Monthly P&L Dashboard

The original SAP BW dashboard had:

  • 1 table with 50 columns (revenue, COGS, gross margin, operating expenses, net income, by month, by product line)
  • 2 bar charts (revenue trend, margin trend)
  • 1 pivot table (revenue by product line and customer segment)

The redesigned Superset dashboard had:

  • Tab 1 (Summary): 4 big number cards (total revenue, total COGS, total margin, net income), 2 sparklines (revenue and margin trends)
  • Tab 2 (By Product Line): Bar chart (revenue by product line), table (revenue, COGS, margin by product line), drill-down to product level
  • Tab 3 (By Customer Segment): Similar structure, but by customer segment
  • Tab 4 (Trends): Line chart (revenue, COGS, margin over time), with ability to filter by product line or customer segment
  • Tab 5 (Variance Analysis): Table showing actual vs. budget, with variance highlighted

This redesign made the dashboard more usable and faster to load. It also enabled self-service: users could now drill down, filter, and explore without waiting for IT.

Week 25–26: Testing and UAT

Once dashboards were built, the team conducted user acceptance testing (UAT). Each dashboard was tested by 3–5 end users from the relevant department.

Testing checklist:

  • Accuracy: Do the numbers match SAP BW? (Tolerance: ±0.01%)
  • Completeness: Are all required metrics and dimensions included?
  • Performance: Does the dashboard load in <5 seconds? Do drill-downs respond in <2 seconds?
  • Usability: Can users find what they need? Are the filters intuitive? Is the layout clear?
  • Security: Do row-level security rules work correctly? Can a sales manager see only their region’s data?

UAT found 340 issues, categorised as:

  • Critical (15): Incorrect numbers, missing metrics, security issues. Fixed immediately.
  • Major (85): Performance issues, usability problems, missing features. Fixed within 1 week.
  • Minor (240): Cosmetic issues, label typos, layout tweaks. Fixed within 2 weeks.

The team iterated on dashboards based on feedback. For example:

  • Finance team feedback: “We need to see budget vs. actual variance. Can you add that?”

    • Response: Added a new tab with variance analysis, showing actual, budget, and variance (amount and %), with red/green highlighting for over/under budget.

  • Supply chain team feedback: “The inventory dashboard is too slow. It takes 10 seconds to load.”

    • Response: Identified that the dashboard was querying 5 years of historical data. Added a date filter (default to last 12 months) and enabled query caching. Load time dropped to 1 second.

  • Sales team feedback: “We want to see pipeline by stage, not just closed deals.”

    • Response: Realised the pipeline data was not in SAP BW; it was in Salesforce. Added a connector to pull pipeline data from Salesforce and built a new dashboard for pipeline analysis.

Week 27–28: Performance Optimisation

As dashboards accumulated, performance became an issue. Complex dashboards with multiple datasets and filters were taking 5–10 seconds to load. The team optimised:

  1. Query caching: Configured Superset to cache query results for 1 hour. This meant that common queries (e.g., “revenue by product line, this month”) would be served from cache in <100 ms.

  2. Aggregation tables: Pre-computed aggregates for the most common queries. For example, a table with revenue, COGS, and margin by product line and month, pre-aggregated daily. This reduced query time from 5 seconds to 200 ms.

  3. Index optimisation: Added database indexes on commonly filtered columns (e.g., date, product line, customer segment). This reduced query time by 30%.

  4. Denormalisation: Flattened some datasets to reduce joins. For example, instead of joining the revenue table to the product table to the product line table, the team denormalised the data so that revenue had a product_line column directly.

These optimisations brought average dashboard load time down to <2 seconds, and 95th percentile load time down to <5 seconds. This was acceptable for the business.

Month 7–8 Deliverables

  • 200 dashboards redesigned and rebuilt in Superset
  • User acceptance testing with 150+ end users
  • 340 issues identified and fixed (critical, major, minor)
  • Query performance optimisation (average load time <2 seconds)
  • Dashboard documentation and user guides

Cost to date: $245K + $140K (dashboard development, testing, optimisation) = $385K

Month 9: Cutover, Training, and Handoff

Week 29–32: Parallel Running and Cutover

For four weeks, both SAP BW and Superset ran in parallel. Users accessed both systems, and the team validated that they produced the same results.

This parallel period revealed a few edge cases:

  1. Rounding differences in calculated fields: Some metrics in BW were rounded at intermediate steps; in Superset, they were rounded at the end. This caused minor variances (<0.1%) for some metrics. The team standardised rounding rules.

  2. Time zone handling: Some data sources were in UTC; others were in AEST. The team standardised all times to AEST in the semantic layer.

  3. Fiscal vs. calendar year: Some reports used fiscal year (July–June), others used calendar year. The team added both to the semantic layer, with clear labelling.

These edge cases were caught during parallel running, which is why parallel running is essential for any migration.

After 4 weeks of parallel validation, the team conducted a formal cutover:

  1. Friday, 5 PM: Shut down SAP BW nightly batch processes
  2. Friday, 6 PM: Run a final data extract and load into Superset
  3. Friday, 7 PM: Validate that all data is loaded and accurate
  4. Monday, 7 AM: Users begin working with Superset as their primary analytics platform
  5. Monday–Friday: Support team on standby for any issues

The cutover was smooth. There were no data issues, and users quickly adapted to the new interface. Within the first week, 85% of regular users had logged in to Superset. Within the first month, 95% had logged in.

Week 30–32: Training and Enablement

Parallel with cutover, the team conducted training for 180 users:

  • Finance team (45 users): 2-hour workshop on P&L, cash flow, and profitability dashboards; 1-hour hands-on session on filtering, drilling, and exporting
  • Supply chain team (38 users): 2-hour workshop on inventory, supplier, and logistics dashboards; 1-hour hands-on session
  • Operations team (42 users): 2-hour workshop on production, quality, and maintenance dashboards; 1-hour hands-on session
  • Sales team (35 users): 2-hour workshop on revenue, pipeline, and customer dashboards; 1-hour hands-on session
  • HR team (25 users): 1.5-hour workshop on headcount, turnover, and training dashboards
  • Power users (30 users): 4-hour advanced training on building custom dashboards, creating calculated metrics, and using the semantic layer

Training also covered:

  • How to use Superset: Navigation, filtering, drilling, exporting
  • How to build dashboards: Selecting datasets, adding charts, configuring filters
  • How to ask for help: Support process, ticket submission, escalation
  • Best practices: When to use which visualisation, how to avoid common mistakes, performance tips

The training was well-received. Post-training surveys showed 92% of users felt confident using Superset, and 78% felt confident building their own dashboards.

Week 33–36: Support and Optimisation

For the first month after cutover, the team provided hands-on support:

  • Help desk: 2 support staff on standby, 8 AM–6 PM, Monday–Friday
  • Weekly office hours: 1-hour sessions for common questions
  • Slack channel: #analytics-support for quick questions
  • Documentation: Wiki with FAQs, video tutorials, and dashboard guides

Support tickets in the first month:

  • How do I filter by X?: 45 tickets (answered by pointing to documentation)
  • Why is this number different from BW?: 12 tickets (mostly rounding or time zone issues, already resolved)
  • Can you build a custom dashboard for me?: 28 tickets (triaged; 8 built by support team, 20 scheduled for future sprints)
  • The dashboard is slow: 6 tickets (optimised via query caching or aggregation tables)
  • I can’t see data for my region: 3 tickets (row-level security issues, fixed)

By the end of month 9, support tickets had dropped to <5 per week, indicating that users were comfortable with the new system.

The team also conducted a post-cutover review:

  • What went well: Smooth cutover, high user adoption, positive feedback
  • What could be better: Some dashboards were slower than expected (optimised), some users needed more training (additional sessions scheduled)
  • What’s next: Roadmap for new features (real-time data, AI-powered insights, integration with supply chain AI automation)

Month 9 Deliverables

  • Parallel running and cutover plan
  • Data validation and reconciliation (parallel period)
  • Training for 180 users (6 cohorts, 16 hours total)
  • Support and enablement (first month post-cutover)
  • Post-cutover review and roadmap

Cost to date: $385K + $95K (cutover, training, support) = $480K

The Real Numbers: TCO and ROI

Migration Costs

PhaseCostNotes
Discovery & Architecture$65KWorkshops, data model assessment, infrastructure design
Data Extraction & Transformation$95KAirflow pipeline, data quality, reconciliation
Semantic Layer & Security$85KMetric definition, RLS, audit logging, compliance
Dashboard Development & Testing$140K200 dashboards, UAT, performance optimisation
Cutover, Training & Support$95KParallel running, training, first-month support
Total$480K9 months, 12 FTE (internal + external)

Annual Operating Costs

SAP BW (old):

  • SAP BW licensing: $85K/year
  • Infrastructure (Power System, DB2, storage): $120K/year
  • Maintenance and support: $40K/year
  • DBA and developer time (0.5 FTE): $60K/year
  • Total: $305K/year

D23.io Superset (new):

  • D23.io managed service (AWS, infrastructure, support): $35K/year
  • Superset administration (0.2 FTE): $24K/year
  • Training and enablement (annual refresh): $10K/year
  • Total: $69K/year

Annual savings: $305K – $69K = $236K/year

ROI and Payback Period

Payback period: $480K ÷ $236K = 2.0 years

This is the traditional payback period. But there are other benefits:

Intangible Benefits

  1. Time to insight: Reduced from 4 hours (SAP BW batch cycle) to 15 minutes (Superset refresh cycle). This means decision-makers work with fresher data.

  2. Self-service analytics: 180 users can now build their own dashboards, without waiting for IT. Estimated time saved: 200 hours/year (1 hour per user per year for self-service analysis that previously required IT support).

  3. Data quality: The migration forced a comprehensive data quality audit, identifying and fixing 2,400+ data issues. This improved the quality of all downstream analyses and decisions.

  4. Flexibility: The open-source Superset platform can integrate with modern AI and automation tools. The manufacturer is now planning to integrate demand forecasting (using AI) and inventory optimisation (using agentic AI agents) directly into Superset dashboards. This would not have been possible with SAP BW.

  5. Skill retention: By moving to an open-source platform, the manufacturer reduced dependence on scarce SAP BW expertise. New team members can be trained on Superset and Python much more easily than on SAP BW and ABAP.

3-Year TCO Comparison

MetricSAP BWD23.io SupersetSavings
Year 1$305K (operations)$480K (migration) + $69K (operations) = $549K-$244K (investment year)
Year 2$305K$69K$236K
Year 3$305K$69K$236K
3-Year Total$915K$687K$228K

By year 3, the manufacturer has recovered the migration investment and is ahead by $228K. Over 5 years, the savings grow to $708K.

Importantly, these numbers don’t account for the value of new insights, faster decision-making, and the ability to integrate AI-powered analytics. The real ROI is likely much higher.

Key Lessons and Gotchas

Lesson 1: Data Quality Is the Bottleneck

The team budgeted 4 weeks for data extraction and mapping. It took 8 weeks. The difference was data quality issues: missing values, duplicates, inconsistencies, and circular references.

Takeaway: Budget 50% more time for data quality than you think you need. Have a data steward on the team who understands the business rules and can make judgement calls on data issues.

Lesson 2: Semantic Layer Design Pays Dividends

Investing 3 weeks in semantic layer design (metrics, hierarchies, RLS rules) upfront saved 4 weeks of rework later. A well-designed semantic layer makes the difference between a platform that users love and one they avoid.

Takeaway: Don’t rush the semantic layer. Involve business stakeholders in the design process. Make sure the metrics are correct before you build dashboards on top of them.

Lesson 3: Parallel Running Is Essential

The 4-week parallel running period caught edge cases (rounding, time zones, fiscal vs. calendar year) that would have caused user confusion post-cutover. Without parallel running, the team would have discovered these issues via angry user emails.

Takeaway: Budget time and resources for parallel running. It’s not optional; it’s insurance against cutover disasters.

Lesson 4: Dashboard Redesign Drives Adoption

The team could have done a 1:1 migration of SAP BW dashboards into Superset. Instead, they took the opportunity to redesign dashboards using modern best practices. This redesign was a key driver of user adoption.

Takeaway: Use migration as an opportunity to improve, not just to replicate. Work with users to understand what they really need, not just what they had before.

Lesson 5: Training and Support Are Not Afterthoughts

The team allocated 16 hours of training and 1 month of hands-on support. This was essential for user adoption. Users who received training were 3x more likely to use Superset regularly than users who didn’t.

Takeaway: Budget 10–15% of your project time for training and support. Don’t skimp on this; it directly impacts adoption and ROI.

Gotcha 1: Exchange Rate Variance

SAP BW used month-end exchange rates for currency conversion. The initial Superset load used average rates. This caused a 0.5% variance in revenue numbers, which was caught during reconciliation but caused confusion.

Lesson: Identify all business rules and data transformation logic in the source system before you start the migration. Document them clearly and implement them consistently in the target system.

Gotcha 2: Rounding Differences

Some metrics in SAP BW were rounded at intermediate steps (e.g., COGS per unit was rounded, then multiplied by quantity). In Superset, metrics were rounded at the end. This caused variances for some metrics.

Lesson: Standardise rounding rules across all metrics. Document the rounding rule for each metric (round to 2 decimals, banker’s rounding, etc.) and implement it consistently.

Gotcha 3: Slow Dashboard Performance

Some dashboards were slow because they were querying 5+ years of historical data. The team solved this by adding date filters and enabling query caching, but it would have been better to anticipate this upfront.

Lesson: Think about performance from the start. Design dashboards with sensible default filters (e.g., last 12 months, not all history). Enable caching for common queries. Test performance with realistic data volumes.

Gotcha 4: User Adoption Surprises

The team expected that power users (30 people) would build most of the custom dashboards. In reality, 80 users ended up building dashboards themselves. This was great for adoption, but it meant the team needed to provide more training and support for dashboard development.

Lesson: Expect higher adoption than you predict. Budget training and support accordingly. Create self-service resources (templates, documentation, video tutorials) to help users build dashboards without support team involvement.

When to Migrate and When to Wait

Migrate If:

  1. Your SAP BW system is >10 years old and you’re facing upgrade costs or performance degradation.
  2. Your licensing costs are high (>$100K/year) and you’re looking for ways to reduce them.
  3. You need flexibility to integrate with modern AI, automation, or data science tools.
  4. Your team lacks SAP BW expertise and you’re struggling to find or retain talent.
  5. You have complex data quality issues that a migration could help you fix.
  6. Your business needs self-service analytics and SAP BW’s rigid data models are limiting you.

The manufacturer met all 6 criteria, which is why migration was the right decision.

Wait If:

  1. Your SAP BW system is <5 years old and performing well.
  2. Your licensing costs are low (<$50K/year) and not expected to increase significantly.
  3. You have a strong SAP BW team who understand the system deeply and are not at risk of leaving.
  4. You don’t need flexibility to integrate with other tools; SAP’s ecosystem (SAC, BDC) is sufficient.
  5. You’re in the middle of a major SAP implementation (e.g., S/4HANA migration); wait until that’s stable before migrating analytics.
  6. You have limited IT resources and can’t afford a 9-month migration project.

If you meet 3+ of these criteria, migration is probably not the right move right now. Wait 2–3 years and reassess.

The Middle Ground: Modernise in Place

If you’re not ready for a full migration, consider modernising your SAP BW system in place:

  • Upgrade to SAP BW/4HANA: In-memory performance, modern architecture, but still SAP-locked.
  • Implement SAP BW Bridge: A tool to migrate BW data models to SAP Datasphere, SAP’s new cloud-native data platform. This is a middle ground between staying with SAP and moving to open-source.
  • Implement SAP Analytics Cloud (SAC): SAP’s cloud-native analytics platform. Easier to use than BW, but less flexible for complex data models.

These options buy you time and improve performance without the disruption of a full migration.

For organisations considering a migration or modernisation strategy, understanding your compliance and security posture is critical. Whether you stay with SAP or move to a modern platform like D23.io, you’ll need to ensure your analytics environment is secure, auditable, and compliant. This is where AI advisory services Sydney and security audit services become important partners in your transformation journey.

Next Steps for Your Own Migration

If you’re considering a similar migration, here’s a roadmap:

Phase 1: Assessment (4–6 weeks)

  1. Conduct a data audit: How much data do you have? How many InfoCubes? How many users?
  2. Assess your data quality: Are there known data issues that need fixing?
  3. Evaluate your options: SAP BW/4HANA, SAP Analytics Cloud, open-source Superset, or something else?
  4. Build a business case: What are your costs today? What would migration cost? What’s the payback period?
  5. Identify risks: What could go wrong? How will you mitigate?

Phase 2: Planning (6–8 weeks)

  1. Define scope: What systems, data, dashboards are in scope? What’s out of scope?
  2. Design the target architecture: Infrastructure, security, semantic layer, dashboards.
  3. Create a detailed project plan: Timeline, milestones, resource requirements, budget.
  4. Set up governance: Who makes decisions? How are changes approved? How is quality assured?
  5. Secure stakeholder buy-in: Finance, IT, business units. Everyone needs to be aligned.

Phase 3: Execution (6–12 months)

  1. Extract and transform data: Build pipelines, validate data, reconcile with source system.
  2. Design the semantic layer: Define metrics, hierarchies, access control rules.
  3. Build and test dashboards: Work with users to design dashboards that meet their needs.
  4. Conduct UAT: Have users test dashboards and provide feedback.
  5. Plan and execute cutover: Parallel running, validation, cutover plan.

Phase 4: Optimisation (3–6 months post-cutover)

  1. Support users: Help desk, office hours, documentation.
  2. Optimise performance: Identify slow queries, implement caching, add aggregates.
  3. Extend functionality: Add new dashboards, integrate with other tools, introduce AI-powered insights.
  4. Measure ROI: Track cost savings, user adoption, time to insight improvements.

If you’re ready to start, consider working with a partner who has done this before. The manufacturer worked with PADISO and D23.io, and having experienced partners significantly reduced risk and accelerated the timeline.

For more detailed guidance on specific topics, check out these resources:

For external context on SAP migrations more broadly, these resources provide valuable perspective:

Conclusion

The Australian manufacturer’s 9-month migration from SAP BW to D23.io’s managed Superset platform was a success by any measure:

  • Timeline: 9 months, on schedule
  • Budget: $480K, within budget
  • Data quality: 2,400+ data issues identified and fixed
  • Adoption: 95% of users logging in within 1 month
  • Performance: Average dashboard load time <2 seconds
  • ROI: $236K annual savings, 2-year payback period
  • Intangibles: Fresher data, self-service analytics, flexibility for AI integration

But this wasn’t a perfect project. There were delays (data quality), surprises (unexpected user adoption), and gotchas (rounding differences, exchange rate variance). The team learned from each of these and adapted accordingly.

If you’re facing a similar decision—whether to upgrade SAP BW, move to SAP’s cloud offerings, or migrate to a modern open-source platform—the key is to assess your specific situation:

  • How old is your system?
  • What are your costs?
  • Do you need flexibility?
  • What’s your risk tolerance?
  • What’s your timeline?

For the manufacturer, all the signs pointed to migration. For your organisation, the answer might be different. But if you do decide to migrate, this guide should give you a realistic picture of what to expect.

Good luck with your analytics transformation. And if you need a partner to guide you through it, that’s exactly what PADISO and D23.io do every day.