SAP BW Modernisation: Beyond the Platform Decision

Every organisation wants AI that can answer real questions about its business. For SAP customers, the data and the business meaning those answers depend on often sit in BW, or in a mixed estate where BW sits alongside other platforms. So the BW modernisation decision is no longer just a platform choice. It is a decision about how trusted business context will be made available to AI, now and in the years ahead.

I've lost count of the number of BW conversations I've had this year. On the surface they start with the same question: what do we do next? But more and more, there's a second question sitting underneath it. How do we get our data ready for AI?

Those two questions are more connected than most organisations realise.

AI is only as useful as the context it has. Ask it about margin, revenue or cost and it needs to know what those things mean in your business, how the numbers roll up and who is allowed to see what. For a lot of SAP customers, that context has lived in BW for years. Business logic that was never properly documented. Reports that parts of the business can't do without. And in plenty of cases, the person who originally built it left in 2014.

So when people ask "what should we move to?", I think it's the wrong first question. The better one is: what is BW actually doing for us today, what do we need to preserve, and what do we need from our data that it isn't giving us now? Increasingly, the answer to that last part is "something AI can use".

The timing matters too. For BW 7.5 customers, the end of mainstream maintenance in 2027 is getting close, and for others the question is what comes after BW/4HANA. Some will rightly decide to stay where they are for now. But treating this purely as a support deadline misses the bigger opportunity. Whatever you decide about BW is also a decision about the foundation your AI will sit on.

What BW still gets right

People are quick to call BW old and clunky.

Parts of it are. But I've worked with BW for more than 20 years, and there's still a lot it does very well. It takes messy transactional data and turns it into numbers the business believes.

Revenue means the same thing in every report. Hierarchies reflect how the organisation actually works. Currency conversion, navigation attributes, compounding, customer exit variables, time dependency and authorisations are all built into the model. It isn't exciting. It's also exactly the context AI needs.

Ask an AI model why margin dropped in Q3 and its answer is only as good as its understanding of what "margin" means, how cost centres roll up, which sources are authoritative and what that user is allowed to see.

Point it at raw tables and it can give you a very confident, and possibly very wrong answer.

Give it governed data, trusted definitions and proper business context, and you've got a much better starting point.

That's what worries me about some modernisation programmes. It's possible to move the data and lose the meaning. You flatten ten years of modelling into tables on a shiny new platform, tick the migration box and discover you've recreated the trust problem BW solved years ago. Right at the point when AI is making trusted context more important, not less.

There are at least four credible paths

This is where the conversation gets more interesting, because there isn't one obvious answer.

1. Stay put and stabilise

Sometimes doing less is the right decision.

You may have an S/4HANA programme consuming most of your transformation capacity. You may have other priorities. You may simply need more time. Stabilising the current estate while planning a longer-term exit can be perfectly rational. The risk is that "we'll deal with it later" becomes permanent, while the rest of the organisation builds new data capabilities around you.

2. Move to BW/4HANA

For organisations on older BW versions, BW/4HANA can still be a logical step. It keeps much of the SAP context and semantics intact, reduces disruption compared with a complete re-platform and remains part of SAP's long-term maintenance strategy.

But moving to BW/4HANA doesn't automatically solve problems around agility, openness or how you want to use data in the future. If those are the real reasons you're modernising, a technical upgrade alone will likely give you a newer version of the same challenge.

3. Move towards SAP Business Data Cloud

SAP's strategic direction is clear.

For existing BW customers, SAP now talks about a "lift, shift and innovate" journey. That can include moving an existing BW estate into the private cloud component of SAP Business Data Cloud first, then progressively adopting capabilities such as SAP Datasphere and SAP Databricks.

There is a strong argument for this route, and I think it's often underestimated. SAP understands its own data better than anyone. SAP-managed data products can bring business context with them, with SAP taking responsibility for maintaining that context as the underlying source systems evolve. And BW Private Cloud Edition means years of investment in BW models doesn't have to be thrown away on day one. For SAP-heavy organisations, that's a lot of risk taken off the table.

If much of your most valuable data sits inside SAP, retaining SAP business context alongside that data matters. It also doesn't have to be a big-bang migration. A phased path may make much more sense. But that doesn't mean you should choose it simply because it's SAP's strategic direction. Test it against your estate, your use cases, your architecture, your skills and the economics of your organisation.

But BDC may be the right destination without "lift, shift and innovate" being the right starting point. In large, complex organisations with multiple BW systems, databases and data lakes, moving first to BW Private Cloud Edition may not be the most logical route, but moving to BDC and Datasphere still might be.

4. Leave SAP for analytics

Snowflake. Databricks. Microsoft Fabric. BigQuery. For some organisations, one of these platforms may genuinely be the better long-term answer.

Perhaps SAP is only one data source among many. Perhaps your data engineering team already works primarily outside the SAP ecosystem. Perhaps the use cases you're building extend well beyond what sits in your SAP estate.

Historically, one of the biggest challenges with moving away from SAP analytics has been recreating all the business meaning embedded in BW.

But is that starting to change?

Is AI changing the economics of leaving BW?

This is the part I find most interesting.

AI is already becoming useful at some of the grunt work that made these programmes so difficult. Reading transformations. Interpreting technical field names. Mapping objects to business concepts. Documenting lineage. Drafting metric definitions. Helping create semantic models on another platform. Work that once required a team of specialists to unpick manually can increasingly be accelerated, although the output still needs expert validation.

That doesn't mean AI magically gives you a trusted semantic layer. Trust still comes from reconciliation against numbers the business already signs off. From someone owning definitions. From governance. From controlling what happens when the source changes. AI doesn't remove those responsibilities. But it may reduce the cost and effort involved in getting there. And if that continues, the decision changes. The question becomes less "Can we afford to rebuild this outside SAP?" and more "Which platform actually makes the most sense for us?"

But SAP isn't standing still either

There's another side to this. While AI may be making it easier to rebuild business meaning elsewhere, SAP is working hard to make that meaning more valuable where it already sits.

The SAP Knowledge Graph is a good example. It sits across Business Data Cloud as a semantic layer, describing how SAP business objects, processes and data relate to each other. Joule and SAP's AI agents use it to understand the business context behind the data, not just the data itself. Add the push to bring BTP, BDC and Business AI together into one governed environment, and the direction is clear. SAP wants the context layer, the bit AI actually depends on, to live inside SAP.

That's a genuine strength. If your AI agents understand your business through SAP's own model of it, they start from a far better place than a model pointed at raw tables. The trade-off is dependency: the more of your business meaning lives in SAP's semantic layer, the more your architecture relies on it. For many organisations, that's a perfectly sensible trade. It just needs to be a conscious one.

There's a separate, more practical question too: how you're allowed to get SAP data out. That has become more complicated over the last couple of years. ODP-RFC, the interface behind many third-party extraction tools, is a good example. SAP says it was only ever intended for SAP-to-SAP data transfers and is now moving to enforce that technically. The updated SAP API Policy in April 2026 goes further. Section 2.2.2 restricts systematic or large-scale extraction and replication, as well as AI agents that plan and execute sequences of API calls, unless they use SAP-endorsed architectures or specifically permitted pathways. That's a significant consideration for anyone building analytics and AI capabilities outside SAP.

To be fair, SAP is clear this isn't a ban. You can still use third-party platforms, as long as you go through published APIs and approved pathways. Some of those pathways are genuinely good. The challenge is for organisations whose pipelines were built around methods that no longer fit. Moving them onto an approved route can mean rework, new tooling and a rethink of the architecture. If your current extraction into a data lake relies on third-party connectors, that's worth checking now, not halfway through a migration.

So there are forces pulling in different directions. AI is lowering the cost of rebuilding meaning outside SAP. SAP is raising the value of keeping it inside, and tightening the routes for getting it out. Rebuilding outside SAP might be getting easier. Feeding it might not be. Which one wins depends on how much of your trusted context is SAP context in the first place, and how comfortable you are with it sitting in one vendor's ecosystem. It's also worth asking how well the knowledge graph copes with heavily customised estates, which is the reality in every BW I have ever come across.

SAP may still win that decision for plenty of organisations and in my opinion is a very strong proposition. But it should win on merit, not because every alternative looks too painful, or because leaving gets a little harder every year.

Any recommendation made before understanding what you've actually got should be treated with caution

I work with SAP every day. Sometimes SAP will be the right answer. Sometimes it won't. Sometimes the best answer will be to do very little for the next 18 months. And modernising BW is not necessarily the same thing as modernising analytics: you can upgrade the platform without changing how the business uses data, or develop new capabilities while the existing BW estate continues to run. Anyone recommending a destination before understanding what you've got should be challenged.

For me, the decision comes down to a few things:

• Where does your most valuable data actually live?
• Which parts of your existing BW estate still matter?
• What can you stop carrying forward?
• What can your internal teams realistically build and support?
• Are you trying to improve reporting, or fundamentally change how people interact with data?
• Where will your trusted business definitions live?
• And increasingly, can your AI tools access that context safely and reliably?
• How much of the decision is being driven by business value, rather than internal politics?
  

What looked obvious two years ago may not be obvious today.

Start with what you've got

Before choosing a destination, take a look at the estate. There's nearly always more in BW than anyone actually needs: queries nobody has run for years, duplicate data flows, and custom logic supporting an organisational structure that disappeared three restructures ago.

Migrating all of that can start to get costly. Retiring what is no longer needed takes analysis, but can avoid unnecessary migration effort. Then identify the things that really matter: the definitions, hierarchies, transformations, rules and authorisations. These are the pieces that make people trust the numbers.

Protect those, wherever they eventually live. Because modernising BW shouldn't start with a platform decision. It should start with understanding what you have, what you still need and what you're trying to achieve.

That's why we're offering a free half-day BW Modernisation Assessment.

We'll look at where you are today, the realistic paths available to you and the questions you need to answer before committing to one. No predetermined destination. No assumption that the answer has to be SAP. Just a clearer view of what should come next.