Replacing SAP BW on HANA: Snowflake or Databricks?

For many years, SAP BW on HANA was the standard for structured reporting on SAP data. Today, many organisations are asking whether to keep investing in the SAP world or whether it is time for replacing SAP BW on HANA with a modern cloud data platform such as Snowflake or Databricks.

For IT decision-makers, this is not only a technical but also an economic question: How can the knowledge built up in SAP BW be carried over to a modern platform – and which architecture delivers the most value for business, analytics and governance? In this article, we compare both platforms and show how a migration succeeds.

Starting point

Why SAP BW on HANA is reaching its limits

Anyone considering replacing SAP BW on HANA usually also wants to integrate more data sources flexibly. Typical limitations are:

Rigid data model with limited options for non-SAP sources
High maintenance effort due to complex transformations and dependencies
High licence and operating costs
Little flexibility when connecting modern analytics and AI tools
Limited cloud readiness – BW/4HANA also remains strongly SAP-centric

On top of that comes the skills shortage: experienced BW experts are retiring, while few young talents choose BW.

Platforms

Snowflake and Databricks as modern alternatives

Snowflake – more than a data warehouse

Originally launched as a cloud data warehouse, Snowflake has evolved into a modern data platform with lakehouse capabilities. External Tables access data in the data lake, Snowpipe loads data continuously, Snowpark processes data in Python, Java or Scala directly on the platform, and Cortex adds AI functions.

The separation of storage and compute, support for semi-structured formats such as JSON, Avro or Parquet, and ACID transactions make Snowflake a powerful foundation – with a strong SQL focus and high usability. Combined with Qlik Talend Cloud, dbt or the Unified Star Schema, Snowflake is well suited for modern, modular architectures.

Databricks – the lakehouse for analytics, data science and AI

Databricks takes a different approach: its lakehouse architecture combines the benefits of a data lake and a data warehouse – as a basis for reporting, data science and artificial intelligence.

Delta Lake as the central storage format – ACID-compliant, fast and versioned
Apache Spark for large data volumes and parallel processing
Native support for machine learning and AI
Python, SQL, R and Scala combined in notebooks
Unity Catalog for data governance

Architecture

Data warehouse, lakehouse, hybrid or data mesh?

Classic data warehouse

For example, Snowflake “out of the box” – a good fit when structure and governance come first, BI and controlling are the main use cases, structured sources dominate and SQL-oriented teams need to deliver quickly.

Lakehouse

For example, Databricks or Snowflake with Qlik Talend Cloud – a good fit when structured and semi- or unstructured sources come together, large data volumes need processing and data science and AI are planned alongside reporting. Raw data first lands in a landing zone, is transformed, modelled for example with Data Vault, and then made available for reporting and analytics.

Hybrid architectures

For many organisations, a mix makes sense: structured SAP data flows into the platform through classic pipelines, event streams and logs through streaming solutions. Everything is consolidated in the Data Vault and exposed through a semantic layer, for example for Power BI or Qlik.

Data mesh

Where responsibilities are distributed across a large organisation, a data mesh can be the right choice – feasible with Snowflake as well as with Databricks.

Side note: MACH architecture as a strategic framework

Snowflake and Databricks fit well into MACH architectures. MACH stands for microservices, API-first, cloud-native and headless – a principle aimed at flexibility, scalability and independence from monolithic systems. This allows specialised tools to be combined along the entire data value chain – from integration and modelling to reporting in Power BI, Tableau or Qlik.

Modelling

Data Vault and Unified Star Schema working together

Modern data architectures benefit from combining modelling layers deliberately. Data Vault and the Unified Star Schema serve different purposes.

Data Vault

Data Vault is a methodical approach to flexible, historised and scalable data storage. Hubs, links and satellites create a traceable structure – ideal for organisations with strict governance requirements.

Historisation and auditability through hubs, links and satellites
ELT processing with Delta Lake on Databricks or streams and tasks on Snowflake
Scalability by separating structure and content
High degree of automation with dbt, Qlik Talend and other tools

Unified Star Schema

The Unified Star Schema (USS) by Bill Inmon and Francesco Puppini is a standardised reporting model for self-service BI. It presents complex data landscapes in a user-friendly structure.

Adaptable to new data sources and requirements
Holistic view without fan and chasm traps
Self-service friendly for Power BI, Tableau or Qlik

Migration

From SAP BW to a new platform in four steps

1. Analyse the existing BW landscape

Which objects such as InfoCubes, queries and transformations are active? Which sources are connected, which user groups and reports exist?

2. Map to the target architecture

BW queries become SQL views or materialised views in Snowflake
DSOs and InfoCubes become Delta tables in Databricks or optimised tables in Snowflake
Process chains become orchestrated pipelines, for example with Qlik Talend, dbt, Azure Data Factory or Apache Airflow

3. Choose the migration approach

Lift & shift: short-term, with little redesign
Greenfield or redesign: mid-term, with a new architecture and a modern model
Hybrid migration: quick first wins plus long-term optimisation

4. Build the data platform

This includes a central landing zone for raw data, automated loading processes, modelling with Data Vault or USS, a semantic layer for self-service, roles and permissions, and monitoring and cost control.

Decision guide

Decision matrix: Snowflake or Databricks?

Criterion	Snowflake	Databricks
Target group	BI, controlling, reporting	Data science, AI, engineering
Data formats	structured and semi-structured	structured, semi- and unstructured
Way of working	SQL, classic BI	Notebooks, code-first
Modelling	Data Vault, Unified Star Schema	Data Vault, USS possible
Architecture	Cloud DWH with lakehouse capabilities (Snowpipe, Snowpark, Cortex)	Lakehouse (Delta Lake, Unity Catalog, native ML)
Governance and sharing	Data sharing, masking, RBAC	Unity Catalog, RBAC, lineage
Cost model	usage-based, storage and compute separated	compute-intensive, finely scalable
Team skills	SQL, BI	Python, notebooks, engineering

Conclusion

The right way out of the SAP BW world

Replacing SAP BW on HANA is more than a technical project – it is a strategic step towards a modern, flexible data architecture.

Snowflake fits particularly well when clear structures, SQL-based ways of working and BI reporting are the priority. With External Tables, Snowpipe, Snowpark and Cortex, Snowflake can also be used as a lakehouse platform. Databricks shines in exploratory analysis, machine learning and large, heterogeneous data volumes.

In the end, what matters is: which goals are you pursuing with your data strategy – and which architecture suits your organisation? You can find more on the differences between the architectures in our article Data lakehouse and data warehouse compared (in German).

Assessment or pilot

How we support you in replacing SAP BW

Quick analysis of your existing BW architecture
Workshops on the target architecture with Snowflake or Databricks
Pilot setups with Data Vault or Unified Star Schema
Vendor-independent advice from experienced architects

FAQ

Frequently asked questions about replacing SAP BW on HANA

Why replace SAP BW on HANA?

SAP BW on HANA is expensive to run, strongly SAP-centric and only partly cloud-ready. Snowflake and Databricks offer more flexibility, scale better and integrate non-SAP sources much more easily.

What is the difference between Snowflake and Databricks?

Snowflake is an SQL-oriented cloud data warehouse with lakehouse capabilities, ideal for BI and reporting. Databricks is a lakehouse platform that combines data lake and data warehouse – strong in data engineering, machine learning and large data volumes.

Which modelling approach suits modern data platforms?

A proven combination is Data Vault for auditable, historised storage and the Unified Star Schema for consistent self-service reporting.

How does a migration from SAP BW to Snowflake or Databricks work?

First, the existing BW landscape is analysed and mapped to the target architecture. Then loading processes, models and reports are rebuilt step by step – orchestrated, for example, with Qlik Talend, dbt or Airflow.

Which platform is the better fit for my organisation?

For classic reporting and self-service BI, Snowflake is usually the obvious choice. For exploratory analysis, machine learning and large, heterogeneous data volumes, Databricks offers more room. We assess both independently of any vendor for your use case.

Note: This article was created or revised with the support of AI. Content, structure and professional assessment come from cimt; editorial review and approval are carried out by the authors.

Contact

Rouven HomannMember of the Executive Board, cimt Group

Snowflake or Databricks with cimt

We advise you independently of any vendor – from choosing the platform to data integration and operations.