SAP BW to Databricks: How to Decide, and Why We'd Choose Databricks

TL;DR

• The deadline is real. SAP BW 7.5 is in mainstream maintenance until the end of 2027, with extended maintenance to 2030. SAP BW/4HANA is maintained until at least 2040.
• Four options, not two: BW/4HANA · lift-and-shift into SAP Business Data Cloud · SAP Datasphere · a lakehouse on Databricks.
• SAP's own recommendation is "lift, shift, innovate" — keep BW as it is, move it into private cloud inside Business Data Cloud, modernise later. That buys time. It does not change anything.
• The hard part of a BW migration is not the data. It is the meaning. BEx logic, exception aggregation, hierarchies and currency conversion do not travel.
• Check your HANA licence before you draw the architecture. Most BW customers hold a runtime licence, which restricts external connections to the HANA database layer and eliminates the approach most architects reach for first.
• Our verdict: Databricks, for most estates — with three honest exceptions where we would tell you not to.

Every SAP BW estate in Europe is now on a clock. SAP has confirmed that SAP BW 7.5 stays in mainstream maintenance until the end of 2027, with extended maintenance available to 2030. That is not a rumour from a consultancy blog; it is SAP's own published maintenance strategy.

What makes this difficult is not the deadline. It is that the two parties with the most to say about your decision both sell you something. SAP recommends a path that keeps you on SAP. Databricks recommends a path that moves you to Databricks. Both recommendations are coherent, both are defensible, and neither is neutral.

We are not neutral either. We are a Databricks Silver Partner, and this article ends with us recommending Databricks. What we have tried to do is show the working: what each option actually gives you, what breaks in a real migration regardless of which way you go, and the specific cases where we would tell you to stay where you are.

Databricks has published its own walkthrough of this migration: Moving from SAP Business Warehouse to Databricks.

Does SAP BW have a future?

Yes, but a narrower one than it had, and the answer depends entirely on which BW you are running.

SAP BW 7.5 is supported in mainstream maintenance until the end of 2027. After that you can buy extended maintenance to 2030, which covers critical fixes rather than new capability. So the honest framing is not "BW dies in 2027". It is: from 2028 you are paying more for a system that has stopped moving, and from 2030 you are on your own.

SAP BW/4HANA is a different story. SAP has aligned it with the S/4HANA maintenance extension and states it will be maintained until at least 2040. If you are already on BW/4HANA, you do not have a 2027 problem. You have a strategy question, and you can take it at your own pace.

The distinction matters because a lot of the urgency in the market is aimed at the wrong audience. If you are on BW/4HANA and someone is telling you the sky falls in 2027, check which product they are describing.

What has genuinely changed is SAP's centre of gravity. New investment is going into Business Data Cloud and Datasphere. BW is being maintained, not developed. That is the real signal, and it is a stronger argument than any date.

What replaces SAP BW? The four real options

1. Upgrade to SAP BW/4HANA

The conservative path. Your BW skills, your BEx queries and your governance model survive. Maintenance runs to at least 2040.

What it does not do is change your data model. You arrive in 2040 with a modernised version of an architecture designed around the constraints of 2010. If your BW estate is well-run and genuinely serves the business, this is a reasonable answer and we would not argue with it.

2. Lift BW as-is into SAP Business Data Cloud

This is SAP's own recommendation, and they are explicit about it. In SAP's own words, the approach is lift, shift, innovate: "Keep your BW as is… lift it to the private cloud within SAP Business Data Cloud."

It is genuinely the lowest-risk short-term move. Nothing is rewritten, nothing breaks, the maintenance clock stops being a problem.

Our objection is not technical. It is that it converts a strategy decision into a deferral. You spend a migration budget and arrive with the same model, the same BEx dependencies and the same reporting backlog, having bought roughly three years. For some organisations that is exactly the right trade, particularly if an S/4HANA programme is already consuming all available change capacity. For most, the second decision is harder than the first one would have been, because the estate has grown in the meantime.

3. Move to SAP Datasphere

Datasphere is the SAP-native modern answer, and it has one real advantage that is consistently underrated: it understands SAP semantics. Exit routines, conversions and the business meaning embedded in SAP objects are handled rather than rebuilt. If your analytics are overwhelmingly SAP-sourced and will stay that way, this is a serious option.

The constraint is the one its users raise most often: cost at volume, and the fact that you are still inside a single vendor's roadmap for the AI and data science work that is increasingly where the value is.

4. Migrate to a lakehouse on Databricks

The most work, the most disruption, and the only option that lets you redesign rather than port. You get an open format, one platform for BI and ML, and no obligation to keep SAP at the centre of an estate that is usually only partly SAP.

The cost is real: you rebuild semantics, governance and security yourself. The next section is about exactly that.

What actually breaks in a BW migration

These apply whichever direction you choose. They are the things that turn a six-month plan into an eighteen-month programme, and they come from practitioners who have done it rather than from vendor material.

The risk is semantic, not technical

Getting data out of BW is a solved problem with a licence attached. Getting the same number out is not.

BW accumulated years of embedded meaning: custom ABAP, transformations, BEx query logic, exception aggregation, hierarchies, currency conversion. None of it is in the tables. A practitioner summary of this work puts it plainly: "The most significant risk is not technical, but semantic."

Plan for reconstruction and reconciliation, not extraction.

Check the HANA licence before you draw the architecture

The single most expensive surprise in this work: most BW customers hold a HANA runtime licence, which restricts external connections to the HANA database layer.

That one clause eliminates the approach most architects reach for first — connect to the database, read the tables, land them in cloud storage. Teams discover it after the design is signed off. Check it in week one.

Delta handling and history

Not all BW tables carry a change timestamp, so there is no guaranteed route to change data capture. Objects at the application layer — extractors, ABAP CDS views — cannot be read from the database layer at all. Incremental extraction from InfoCubes works in some cases and needs testing object by object.

And the trap nobody expects: BW often holds more history than the ERP system underneath it. If you extract from S/4HANA instead of BW because it is easier, you can silently lose years of data.

Data representation

The quiet killers. Packed decimals lose precision. NUMC fields must stay strings or leading zeros disappear. Time zones and units drift. And one real example worth memorising: a team found duplicate records in their Bronze layer after migration, because BW's DSO activation had been silently deduplicating for years and the new ingestion did not.

Governance was the product

The thing BW actually gave you was one agreed definition of margin. Move to a lakehouse without replacing that and you get what one practitioner described exactly: "Each team — finance, commercial, logistics — will develop its own notebooks or pipelines to calculate 'their' version of the margin."

Also in scope, and routinely missed: BusinessObjects, SAP Analytics Cloud, Analysis for Office, BPC and Integrated Planning all hang off BW.

Why we would choose Databricks

Three reasons, in order of how much they actually matter.

1. It is the only option that lets you fix the model. BW/4HANA and lift-to-BDC both carry your existing design forward. That design encodes constraints that stopped applying years ago — aggregates built for disk that is no longer slow, cubes shaped around a reporting tool half the business has left. If your BW estate works well, that is fine. In our experience it usually does not, and a migration is the only moment anyone will fund changing it.

2. Most estates are not only SAP. The analytics that matter now join SAP data to things that never lived in SAP: web events, IoT telemetry, pricing feeds, third-party market data. Every SAP-native option optimises for the SAP half. A lakehouse treats them the same, which matters more each year.

3. One platform for BI and AI. You can bolt data science onto any of these. On Databricks the governance, lineage and compute are the same for a dashboard and a model, which removes an entire integration layer and the team that maintains it.

What we are not claiming: that it is cheaper, or faster, or lower risk. It is the most disruptive of the four. We think the disruption buys something the other three do not.

When we would tell you not to

A recommendation with no exceptions is a pitch. Three cases where we would tell you to choose something else:

• You are mid-S/4HANA. If an S/4HANA programme is already consuming your change capacity, start a parallel analytics migration and both will suffer. Lift to BDC, buy the time, revisit in 2028. This is the single most common case we see.
• Your analytics are ~entirely SAP-sourced and will stay that way. If almost nothing outside SAP enters your reporting, Datasphere's native handling of SAP semantics is a real advantage and you would be rebuilding by hand what it gives you.
• BW works and nobody is complaining. If the business trusts the numbers, the backlog is short, and you are on BW/4HANA with maintenance to 2040 — you do not have a problem. Upgrade and move on. Migration is a tool for fixing something, not a goal.

A decision rule you can use

Work down this list and stop at the first match.

Whichever row you land on, the first action is the same: an assessment of what is actually in your BW estate. Most organisations do not have an accurate inventory of their own warehouse — which objects are live, which reports are genuinely used, which transformations still encode a rule anyone can explain. Without that, every quote you receive is guesswork, including ours.

The Cosmos Thrace Perspective

We are a Databricks Silver Partner, and we have delivered dozens of data platform implementations across Europe, many of them on Databricks. We are not an SAP consultancy and we do not pretend to be.

Where we get called is the part after the data arrives: when the margin figure in the new platform does not agree with the margin figure in BW, and nobody can say which is right. That is almost never a pipeline bug. It is a governance gap — a definition that lived in a BEx query and was never written down, now reimplemented four different ways by four different teams.

Which is why our advice on this migration is the same regardless of platform: decide who owns each number before you move any of them. The technical work is tractable. The reconciliation is what runs over.

Sources

• SAP — NetWeaver and BW maintenance strategy (BW 7.5 to end of 2027, extended to 2030; BW/4HANA to at least 2040; SAP Note 1648480): pages.community.sap.com
• SAP — Modernize Your BW Landscape with SAP Business Data Cloud, the "lift, shift, innovate" position
• Databricks — Moving from SAP Business Warehouse to Databricks
• Practitioner discussions on r/SAP and r/databricks (HANA runtime licence constraint, delta and CDS limitations, DSO deduplication)