Lately, we've talked to a number of SAP customers that have reached an interesting crossroads in their analytics journey. Whether they're running legacy SAP BW workloads or BW/4HANA, most of these customers maintain a large inventory of reports built on older technologies like BOBJ and SAP Lumira—tools that once served their purpose but now struggle to keep up with evolving business needs and modern data expectations.
Meanwhile, business teams are increasingly moving away from canned reports and turning to third-party BI tools like Tableau and Power BI to meet their self-service analytics needs. That's on top of the ongoing skunk works of dumping SAP tables into CSV files and analyzing them in Excel. Put it all together, and it’s no surprise that a lot of organizations are feeling the squeeze of analytics sprawl.
While we've talked a lot lately about the impact modern data platforms like Microsoft Fabric, Snowflake, and SAP BDC are having on these conversations, today we're narrowing the focus. Today, we want to show you how Power BI can help you cut through the clutter, streamline your analytics environment, and unlock more value from your SAP data.
If you’re considering making the switch, you’re not alone—and you’ve probably got some big questions. Let’s walk through what you need to know before taking the plunge.
Why Power BI?
Since this article is by no means intended to be an infomercial for selling you on Microsoft BI products, we wanted to start by addressing a rather large elephant in the room.
One of the very first questions we get from customers when broaching the topic of using Power BI for SAP analytics workloads is why? Or, more specifically, it's "why wouldn't I just use SAP BI products?". After all, who else understands SAP data visualization better than SAP?
And, honestly, it's a very good question. While legacy tools like BOBJ and Lumira are definitely starting to show their age, SAP Analytics Cloud (SAC) can represent a nice modern alternative for some customers. At the end of the day, it's important to pick the right tool that best fits your organization.
If you're on the fence about this decision, here are a few compelling points to consider when thinking about Power BI:
Ease of Use: One of the reasons Power BI has gained so much popularity is because it's relatively simple to learn and use - even for non-technical analyst types that don't speak things like SQL and data cubes. Indeed, many business analysts have successfully transitioned their Excel skills over to Power BI. So, if you're looking for a BI tool that's approachable from a broad set of data consumer types, Power BI is honestly where it's at.
It's Not Just About SAP: While Power BI plays very nice with SAP data sources, one of its strengths is its ability to easily plug in data from just about anywhere in your data estate (and beyond). So, if you're planning to blend your SAP data with other sources—even unstructured ones—Power BI is uniquely equipped for the job.
Standardization: If your goal is to simplify your BI portfolio, then it probably makes sense to standardize with a good solid, general-purpose BI tool like Power BI. We've talked to countless business users that are frustrated having to navigate through so many BI tools. Power BI truly offers a one-stop shop for this.
By the Numbers
While we're on this topic, it’s worth noting that Microsoft has established a fairly sizeable lead in the BI platform race with Power BI. As shown in Figure 1 below, Gartner has once again positioned Microsoft as a clear leader in its Magic Quadrant for Analytics and BI Platforms. Whether or not you put much weight on analyst reports, the numbers speak for themselves—Power BI adoption is widespread, and if you’re considering it, you’re in very good company:
Over 95% of the Fortune 500 run Power BI
540K+ customers are running Power BI
There's an estimated 7M+ Power BI developers in the world
Figure 1: Positioning of Power BI in the Gartner Magic Quadrant for BI Platforms
How Much Does Power BI Cost?
This is the next most common question we hear from SAP customers—right after “Why should I use Power BI for SAP analytics?”
As with most enterprise software, licensing conversations are rarely simple. The total cost of ownership (TCO) depends on a number of factors: how many users you have, what kind of workloads you're running, whether you're embedding reports or just consuming them, and how much data you're moving around.
However, instead of just giving you the traditional consulting answer of "it depends", we'll do our best in this section to unpack Power BI licensing requirements. You can find a more detailed breakdown of Power BI pricing options on the Power BI product page.
Understanding Power BI Licenses & Capacities
Understanding Power BI licenses and capacities can feel a bit overwhelming at first—but it doesn’t have to be. With options ranging from free licenses to Premium and Fabric capacities (and even Embedded for external users), the key is knowing what each one actually does and when to use it. In this section, we’ll walk you through each option, one by one, so you can figure out what fits best for your team, your data, and your budget.
Power BI Pro License
To build and deploy custom reports and dashboards using Power BI Desktop (a free download available here), developers need to have a Power BI Pro license. These licenses currently retail at $14 per user/month (USD). However, since this license is also bundled with the Microsoft 365 E5 license plan (formerly Office 365 E5), it's quite possible that your team already has access to this license.
Smaller organizations/teams can often get by with just a handful of Power BI Pro licenses. Indeed, as long as everyone who needs to create or view reports has a Pro license, there's usually no need to invest in additional infrastructure. This can be a simple, cost-effective way to enable self-service analytics and team collaboration without overcomplicating things.
While you can achieve an awful lot with just a handful of Pro licenses, it's important to note that Power BI Pro users operate within a shared capacity. This means that their reports and datasets run on Microsoft’s multi-tenant cloud infrastructure where there are notable limitations in terms of dataset size, availability, and refresh cadences. Moreover, since this is a shared capacity, performance can vary—especially during peak usage times.
Microsoft Fabric Capacity
If you're going to be working with larger datasets—you know, like the ones you might load from SAP—then you're probably going to need to purchase a Microsoft Fabric Capacity. Since Microsoft Fabric is a relatively new topic, this requires some explanation.
As noted in the previous section, Power BI Pro licenses grant you limited access to a shared capacity where your datasets can be stored and periodically refreshed. However, if you're dealing with enterprise-grade workloads, this shared capacity isn't going to cut it. Therefore, you need to purchase a separate capacity to host your production Power BI workloads.
In the past, these capacities were referred to as Power BI Premium capacities. This changed in early 2024 when Microsoft announced that they were retiring Power BI Premium capacities and replacing them with Fabric capacities.
Despite the change in name, it's important to understand that this shift doesn’t require you to fully adopt Microsoft Fabric or radically change your cost structure (even though there are some notable benefits for SAP customers to do so). Instead, this transition is part of a natural evolution that's intended to further streamline the end-to-end development experience—especially since Power BI is already tightly integrated with Fabric’s runtime environments. Microsoft's goal here is to align its licensing and infrastructure strategy with where it's investing the most innovation: making capacities more powerful, flexible, and responsive across workloads.
For SAP customers, you can kind of think of Fabric capacities as being like the virtual, cloud-based equivalent to spinning up a BOBJ server on premises to host your reporting infrastructure. To run complex reports against large datasets, you really need a dedicated server resource to host the data and compute resources. Although Power BI SAP connectors enable you to execute real-time queries against SAP BW and/or SAP HANA systems, performance will be better across the board if you host your Power BI workloads on a Fabric capacity.
Since Fabric capacities are Azure based, you can purchase/configure/scale them via your Azure Portal account. You can find a detailed breakdown of Fabric capacity pricing here and here.
Power BI Premium Per User
For organizations looking to scale their analytics capabilities without committing to the purchase of a Fabric capacity, the Power BI Premium per user license presents an affordable compromise. For an additional $10 per user per month (i.e., $24 per user per month total), it builds on the Pro license by providing access to dedicated capacity—enabling improved performance, support for larger data models (up to 400 GB), and more frequent refresh schedules.
Beyond the performance upgrades, Premium licenses also unlock access to features like paginated reports, AI-powered analytics, and incremental refresh. They also enable sharing with free users, making it easier to distribute insights across the organization without licensing everyone individually.
In some cases, we see individual departments utilizing Power BI Premium licenses to spin up a Power BI reporting environment without the overhead and complexity of a full-scale rollout.
Power BI Free Accounts
While they don’t require a separate purchase, Power BI free licenses are automatically assigned to users within an organization—making it easy for people to view and interact with reports shared through a Premium or Fabric capacity. There’s no manual setup involved; users simply log in and start consuming content. This makes it easy to share insights broadly without the overhead of licensing every individual viewer.
User licenses are only needed when someone needs to build, publish, or collaborate on reports and dashboards. For those just viewing embedded dashboards, accessing shared workspaces, or exploring Power BI apps, the free license—paired with a backed capacity—is all that’s required.
Power BI Embedded Capacity
If you want to expose (or embed) your dashboards to external users—such as customers, partners, or suppliers—through a website or portal, then you’ll need to purchase a Power BI Embedded capacity. Or, alternatively, you can purchase a Fabric capacity and use for your Power BI embedded workloads.
Either way, the provisioned capacity provides the runtime environment needed to host and serve Power BI reports and dashboards outside of your organization. A key advantage of this model is that it eliminates the need to license individual external users. Instead, you simply pay for the compute capacity behind the scenes, making it a scalable and cost-effective way to deliver analytics to a wider audience.
You can find a detailed breakdown of Power BI Embedded pricing here.
Connecting Power BI to SAP
Now that we've addressed the "why" and "how much" questions, let’s talk about something just as important: how to actually connect Power BI to your SAP systems. At a high level, there are two main approaches. The first is to use one of Microsoft’s built-in connectors—ideal for direct access to SAP BW or HANA data. The second is to use Microsoft Azure and/or Microsoft Fabric as a staging layer, where you can land, transform, and model your SAP data before it hits Power BI.
There’s no one-size-fits-all answer here. The right approach depends on your data landscape, reporting needs, and whether you plan to continue investing in technologies like SAP BW or HANA. In this section, we’ll break down both options to help you decide which path makes the most sense for your organization.
Power BI SAP Connectors
By default, Microsoft provides three standard connectors that we can use to consume SAP data: the SAP BW connector, the SAP HANA connector, and the more general-purpose OData connector.
If you're still running SAP ECC or other legacy SAP Business Suite systems, there’s also an argument to be made for using other Power BI database connectors—such as those for Oracle or DB2—to access SAP system data directly. However, this can be a sensitive area in terms of SAP and database licensing agreements, and navigating those details is beyond the scope of this article. It’s also worth noting that, in more advanced scenarios, it’s possible to create our own custom connectors.
For now, we'll stick to the basics and have a look at the three standard connectors. You can refer to Figure 2 as an architectural reference to see how each connector works and securely connects to SAP systems—even those hosted in on-premises data centers. We’ll expand on the details of each approach in the sections that follow.
Figure 2: Power BI SAP Connector Architecture
SAP BW Connector
For customers running SAP BW—whether it's a legacy BW system or BW/4HANA—we can use the SAP BW connector to pull data directly into Power BI. This connector is primarily designed to work with BEx (Business Explorer) queries.
BEx queries are pre-defined views in SAP BW that combine data from InfoProviders (e.g., cubes) with business logic like filters, key figures, variables, and calculated fields. They act as a sort of semantic layer, making complex data easier to consume for reporting tools like Power BI.
From a modeling perspective, you can think of BEx queries as curated data sets built for analysis—optimized for performance and aligned with SAP business rules. As you can see in Figure 3 below, BEx queries are organized by functional area (e.g. purchasing), making it easier to find what you're looking for.
Figure 3: Importing Data From an SAP BW System Using the SAP BW Connector
The SAP BW connector supports data integration in two distinct modes:
Import Mode: In this scenario, data is imported from the connector, compressed, and loaded into a storage area within the aforementioned the Power BI / Fabric capacity. Then, at runtime, the data is loaded from the cache into Power BI's in-memory VertiPaq engine which is highly optimized for consumption from Power BI reports.
DirectQuery Mode: In this scenario, query requests from Power BI reports are routed directly to the SAP BW backend and Power BI is basically just a pass-through. Here, we should note that this mode does come with some functional limitations.
In most cases, we would recommend utilizing import mode as it offers the best overall performance. While some queries translate reasonably well, users will definitely feel the pain if every filter selection requires a roundtrip back to SAP.
Regardless of which mode you choose, requests from the SAP BW connector are routed through the On-Premises Data Gateway (OPDG) component, which acts as a piece of middleware that sits between the Power BI service in the Microsoft Cloud and your backend SAP system(s). This applies whether or not you're running your SAP workloads in an on-premises data center or in the cloud (e.g., SAP on Azure). You can find detailed setup instructions for the SAP BW connector here.
Figure 4: Understanding How the SAP BW Connector Works
From a technical perspective, the OPDG component shown in Figure 4 above plays two key roles:
First, it creates a secure network tunnel that ensures that SAP data requests are fully encrypted and secured. For accessing data from tier one systems like SAP, this is table stakes. Architecturally, the OPDG plays a similar to role the Cloud Connector SAP provides to connect their SAP BTP cloud platfomr to backend SAP systems.
Secondly, it serves as a kind of protocol translator, enabling the Power BI runtime to consume BEx queries using the RFC-based OLAP BAPI interface. Looking carefully at the architecture diagram from Figure 4, you can see that the RFC wrangling is handled by SAP .NET Connector (NCo).
Fortunately, all these details are neatly abstracted behind the OPDG. So, once your OPDG infrastructure is setup, the SAP BW connector makes it pretty easy to start ingesting data from SAP.
SAP HANA Connector
As the name suggests, the SAP HANA connector can be used to extract data from SAP HANA databases including:
HANA system databases for S/4 HANA or Suite on HANA (SoH) systems
HANA system databases for BW4/HANA systems
HANA cloud databases
HANA sidecar databases
If you've worked with other database connectors with Power BI (e.g., Azure SQL, SQL Server, Oracle, etc.), then the SAP HANA connector will feel pretty familiar in terms of its support for querying tables and views. What sets it apart is that it’s also designed to work seamlessly with HANA’s native modeling objects, particularly Calculation Views. These views are the backbone of HANA-native analytics and allow you to define complex business logic, aggregations, and joins—all of which can be consumed directly in Power BI for reporting and visualization.
As you can see in Figure 5, queries against SAP HANA databases are once again brokered through the OPDG component. Here, we must download and install ODBC drivers for SAP HANA so that the OPDG can create database connections. You can find detailed setup instructions here.
Figure 5: Understanding How the SAP HANA Connector Works
OData Connector
The last connector we'll touch on is the more general purpose OData Feed connector. This connector can be used to consume data from SAP backend systems via OData APIs. If you're running S/4 HANA or have a widespread deployment of SAP Fiori apps in your landscape, then then this connector makes it easy to tap into your SAP system's OData service catalog (Transaction /IWFND/MAINT_SERVICE).
Figure 6: Understanding How the OData Feed Connector Works
For customers that would prefer not to build on top of legacy BW infrastructure, this connector is especially appealing in that it makes it easy to integrate data from both S/4 and legacy ECC or Business Suite systems. Here, we can leverage the following types of OData services:
SAP standard OData services packaged with SAP Fiori apps
Custom OData services built using the SAP Gateway tool
OData services built on top of Core Data Services (CDS)
Building a Bridge with Azure and Fabric
While Power BI’s native connectors make it easy to get started with SAP data, you may eventually reach a point where you need something more scalable, flexible, and future-proof. In these situations, we can utilize Microsoft Azure and/or Microsoft Fabric to introduce a centralized data platform—one that brings all your SAP and non-SAP data together under one roof. This approach enables us to eliminate silos, implement advanced data integration scenarios, and set the stage for more advanced analytics and AI workloads.
One of the biggest benefits of this approach is performance. For example, Microsoft Fabric introduces new capabilities like Direct Lake mode, which allows Power BI to query data stored in OneLake directly—without having to import or use DirectQuery. This leads to lightning-fast performance, reduced refresh overhead, and a much more responsive experience for end users. This can be a real game-changer if you're working with large volumes of SAP data.
Of course, designing a unified data platform is a much broader topic—and one that goes well beyond the scope of this article. If you're ready to explore what that journey looks like, be sure to check out our recent blog series, Unlocking the Power of SAP Data with Microsoft Fabric where we go deep into architecture, best practices, and real-world use cases.
Storytelling with Your SAP Data
Once we've ingested SAP data into a semantic model in Power BI, it's pretty much business as usual when it comes to report and dashboard development. SAP data models are generally well-structured and consistent—even if they do expect you to speak "SAPese." On the other hand, for business users unfamiliar with terms like cost center, controlling area, or fiscal variant, the raw data can be a bit intimidating.
That’s where Power BI’s modeling capabilities really shine. When working in import mode, we can shape and simplify the data using Power BI’s semantic modeling layer. This allows us to create business-friendly field names, define meaningful relationships, and surface calculations that reflect how the business actually thinks about performance—all while hiding the complexity of the underlying SAP data.
Figure 7: Working with the Power BI Desktop Tool
Depending on your legacy report inventory, your approach may vary. For example, if you have a large number of tabular Webi reports, you might want to consider refactoring them into more modern, interactive dashboard designs. While Power BI does support tabular and even paginated report designs, there are often more engaging and insightful ways to visualize the same data using Power BI’s rich visual toolkit.
One such example is the Q&A visual shown in Figure 8 below. Here, with just a little bit of modeling (e.g., defining human readable labels or synonyms for SAP data points), we can enable users to ask questions about their data using natural language prompts.
Figure 8: Working with the Q&A Feature in Power BI to Ask Questions About Data
Another example is the smart narrative summary control shown in Figure 9. This context-sensitive visual is able to utilize generative AI to summarize the selected data on the screen.
Figure 9: Working with the Smart Narrative Summary Control
These examples barely scratch the surface of what's possible with Power BI. Some other powerful enhancements you can bake into your Power BI reports include calculated measures and KPIs using DAX, hierarchies to support intuitive drill-downs, custom date intelligence for SAP’s fiscal calendars, and tooltips or visual cues that help users explore and understand the story behind the numbers.
What About Data Security?
When it comes to SAP data access, security is always a top concern—and rightfully so. In Power BI, how security is handled depends largely on the storage mode you choose: import mode or DirectQuery mode.
With import mode, SAP data is typically loaded via data flows into a Microsoft Fabric capacity behind the scenes using an SAP service user account (think system user). Once the data is loaded, Power BI’s row-level security (RLS) features can be used to manage which users see what data at runtime. This approach is straightforward and highly performant, especially when paired with semantic models that abstract SAP complexity and apply business-friendly access logic.
Figure 10: Configuring Row-Level Security in Power BI
With DirectQuery mode, data access requests are sent to SAP in real time. In this scenario, it usually makes sense to configure single sign-on (SSO) using Kerberos or similar authentication protocols. This approach works for each of the three connectors listed above.
The primary benefit of this approach is that SAP role authorizations are preserved for the end user. However, while this SSO-based approach offers tight alignment with existing SAP security models, it often comes at the cost of reduced performance—especially for more complex queries or large user bases.
Performance aside, one of the key benefits of utilizing the Power BI row-based security model is that it allows you to map Power BI access roles to Entra ID (formerly Azure AD) groups, making it easier to manage user permissions across the enterprise in a consistent and scalable way.
Regardless of the direction you use, the good news is that you have plenty of choices to put together an effective security model that works well for your team.
Long-Term Outlook
Looking ahead, Power BI is well-positioned to remain a go-to data visualization tool for SAP customers—especially as more and more organizations shift toward cloud-based data platforms. Whether you’re building your future on Microsoft Fabric, or leveraging third-party platforms like Snowflake, Google BigQuery, or even SAP's new Business Data Cloud (BDC) platform, Power BI offers the flexibility to integrate seamlessly with all of them.
This kind of interoperability is a major advantage, particularly for complex data landscapes. As Power BI continues to gain traction as the enterprise-standard visualization tool, it brings with it a wealth of benefits: a familiar and intuitive interface for business users, robust support for self-service analytics, and deep integration with Microsoft 365 tools like Excel, Teams, and SharePoint. Standardizing on a tool that your users actually enjoy working with doesn’t just simplify training and support—it helps drive broader adoption and more consistent insights across the organization.
Closing Thoughts
Hopefully this article has given you some clarity on how Power BI can fit into your SAP analytics strategy—both now and in the future. Swapping out legacy BI tools like BOBJ and SAP Lumira for Power BI doesn’t mean starting from scratch. This approach is about simplifying what you already have, reducing reporting sprawl, and giving users easier access to the insights they need.
If you're looking for a quick way to get started with a BI modernization effort, Power BI offers a practical path forward, with strong integration into both the Microsoft ecosystem and a growing number of cloud data platforms. It’s flexible enough to work across SAP and non-SAP systems, and familiar enough that business users can pick it up quickly. So, if you're evaluating how to evolve your analytics environment, Power BI is a really solid place to start.
