May 2026: What Power BI's Python Deprecation Means for ISVs

If you ship a SaaS product with Power BI embedded dashboards, and any of those dashboards contain Python or R visuals, your charts will go blank in May 2026. 

Microsoft announced the deprecation in its November 2025 Power BI feature summary: effective May 1, 2026, Power BI will end support for embedding reports containing R or Python visuals via the "Embed for your customers" solution (app-owns-data) and Publish to Web. The charts simply stop rendering. This affects ISVs, SaaS companies, and developers who use Power BI Embedded to ship analytics to their own end customers. If that is you, you need a plan now.

What Exactly Is Being Deprecated

The deprecation covers Power BI's "Embed for your customers" scenario (sometimes called app-owns-data or PaaS embedding), and Publish to Web. These are the primary patterns ISVs use when they embed dashboards inside their own product for end users who do not have Power BI licenses.

After May 1, 2026, reports containing R or Python visuals will still load inside embedded contexts. The rest of the report renders fine. But the Python and R chart tiles will display as blank white boxes.

What is NOT affected:

• Embed for your organization (user-owns-data), where end users authenticate with their own Power BI accounts
• Secure embed to SharePoint Online
• Secure embed to websites or portals
• R and Python visuals used in Power BI Desktop or the Power BI Service (non-embedded)

The line Microsoft has drawn is clear: this is a PaaS-mode, customer-facing embedded analytics problem. Enterprise internal dashboards are untouched. ISV-built products are the ones on the hook.

Why Microsoft Made This Call

Python and R visuals in Power BI have always been operationally expensive. They require a live Python or R runtime on Microsoft's infrastructure, executing arbitrary user-supplied scripts inside a sandboxed environment. Running that at scale, for millions of embedded end users across thousands of ISV products, is a different cost equation than running it for internal enterprise dashboards.

The feature also had persistent reliability issues. Community reports of R and Python visuals failing silently in embedded contexts go back years, including version mismatches (Power BI Service running R 3.4 when developers had written scripts for R 4.3), inconsistent package availability, and rendering failures that were hard to debug remotely.

The low usage rate was the final variable. Microsoft's embedded product is marketed toward ISVs who ship visual dashboards to non-technical end users. Python and R visuals appeal to data scientists, not to the SaaS vendor's customers staring at a subscription analytics screen. The audience mismatch made this an easy cut.

The Blast Radius for ISVs

For most ISVs, Python visuals in embedded dashboards fall into one of three categories:

Statistical charts built in matplotlib or seaborn. Distribution plots, regression lines, box plots, custom correlation heatmaps. These were built in Python because Power BI's native chart library lacked them at the time, or because the data team came from a Python-first background. These will go blank.

Data transformation logic inside Python visuals. Some developers put data manipulation (reshaping, feature derivation, outlier removal) inside a Python visual block and then rendered the output. This is a particularly bad pattern because the transformation itself breaks, not just the chart.

Custom R visualizations. ggplot2 outputs, specialized statistical charts from R packages. Same outcome.

If your product has any of these in customer-facing embedded reports, your end customers will see blank panels starting May 2026 with no error message explaining why.

What Microsoft Recommends

The official guidance directs users toward two migration paths.

DAX measures and native Power BI visuals. For charts that can be approximated using standard aggregations, the suggestion is to rebuild them using DAX and native visual types. This works for simpler cases, like replacing a Python bar chart with a native clustered bar chart. It falls apart for any chart that required Python precisely because native visuals could not produce it.

Fabric Notebooks for advanced scenarios. Microsoft points to Fabric Notebooks as the home for Python-based analytics going forward. The idea is that you run Python in a notebook, produce a result, and surface it through Power BI via a semantic model or export.

This is technically sound but operationally heavy. Fabric Notebooks require a Fabric capacity license (F2 or higher, starting around $263 per month). For an ISV that was using Python visuals to avoid exactly this kind of infrastructure overhead, moving to Fabric Notebooks is a significant rearchitecting project.

The real message from Microsoft: Python computation belongs in the data layer, not the visualization layer. That is a reasonable architectural principle. But it is a painful retrofit for teams that built the other way.

The Deeper Problem: Platform Risk in Embedded Analytics

The deprecation itself is manageable. ISVs can audit their reports, identify the Python and R visuals, and either rebuild them or remove them. That work is bounded. The more important signal is what this pattern says about the cost of building a customer-facing product on top of Power BI Embedded.

Power BI is a business intelligence product designed for internal enterprise use. The Embedded tier exists to let ISVs extend that product into their own applications, but it was never built ground-up for customer-facing SaaS delivery. The licensing model (A-SKUs priced by capacity, not by tenant), the lack of a native multi-tenant architecture, the iframe-based embedding model, and now this deprecation are all symptoms of the same underlying mismatch.

ISVs using Power BI Embedded are tenants of Microsoft's product decisions. When Microsoft decides that Python visuals are too expensive to support in PaaS mode, ISVs carry the customer impact. There is no negotiation and no roadmap input.

What to Do Right Now

If you are affected, the immediate actions are in this order.

Audit first. Pull a list of all Power BI reports deployed in your embedded environment. Filter for any reports containing Python or R visuals. Many tools can do this programmatically via the Power BI REST API (GET /reports and inspecting the visual types). Know your surface area before you plan remediation.

Categorize by rebuild cost. Some Python charts can be replicated with native Power BI visuals. Others cannot. Separate these early because the remediation path differs. Simple charts get rebuilt natively. Complex charts require a decision: accept the loss, move to a different visualization approach, or evaluate whether the visual type itself belongs in a platform that better supports it.

Communicate with customers. If your customers have customized dashboards containing Python or R visuals, they need to know. Waiting until charts go blank is a support disaster. A proactive notice explaining the change and the migration path is the cleaner play.

Evaluate the platform decision. The deprecation creates a natural window to ask whether Power BI Embedded is the right long-term foundation for your product's analytics. If you are already carrying workarounds for multi-tenancy, pricing, or customization constraints, those costs compound. The remediation work you are about to do represents an investment. Consider whether that investment points forward or just digs the current hole deeper.

Why This Is a Good Time to Evaluate Embedded-Native Alternatives

Platforms built specifically for ISV and SaaS embedded analytics have a different risk profile than Power BI Embedded precisely because their product decisions are governed by ISV requirements, not enterprise internal use.

Zoho Analytics is one such platform. Its embedded analytics offering was designed for multi-tenant SaaS delivery, with three deployment modes covering white-label portals, SSO-based full workspace embedding, and API-based view-only embedding for high-volume end user scenarios.

The visualization layer in Zoho Analytics does not depend on an external runtime for core charts. Python integration in Zoho Analytics is handled at the data preparation layer through Zoho DataPrep, which means the computation runs before the report renders, not inside the rendering engine. This is the architectural separation Microsoft is now trying to push Power BI users toward via Fabric Notebooks. Zoho Analytics already works this way.

For ISVs reassessing their embedded analytics stack in light of this deprecation, the key evaluation criteria are:

• Multi-tenancy: Does the platform manage workspace isolation per customer tenant natively, without you building a management layer on top of it?
• White-labeling: Can the analytics experience match your product's brand without surface-level CSS overrides?
• Pricing model: Is the pricing per tenant, per viewer, or by capacity? Capacity pricing transfers Microsoft's scaling economics onto you; per-tenant models align vendor cost with your growth.
• Visualization coverage: Does the platform's native chart library cover your use cases, reducing dependence on runtime-based workarounds?
• Vendor stability: Is embedded analytics a core product for the vendor, or a bolt-on to an enterprise BI tool?

Frequently Asked Questions

What is the exact deprecation date for Power BI Python visuals in embedded scenarios?
May 1, 2026. After this date, Power BI reports containing R or Python visuals will still load in "Embed for your customers" and "Publish to Web" contexts, but the R and Python chart tiles will display as blank.

Does this deprecation affect Power BI Desktop?
No. R and Python visuals in Power BI Desktop are not deprecated. The change applies only to the "Embed for your customers" (app-owns-data) and "Publish to Web" deployment scenarios.

Does the Power BI Python visuals deprecation affect internal enterprise dashboards?
No. "Embed for your organization" (user-owns-data), secure embed to SharePoint Online, and secure embed to websites or portals are not affected. Python and R visuals in the Power BI Service itself continue to work.

What does Microsoft recommend as a replacement for Python visuals in embedded reports?
Microsoft recommends migrating to native DAX-based visuals where possible, and using Fabric Notebooks for advanced Python computation that feeds into a semantic model. Fabric Notebooks require a Fabric capacity license (F2 or above).

Can ISVs get an extension or exception to the May 2026 deprecation?
Microsoft has not offered an exception or extension path. The deprecation date is fixed at May 1, 2026.

What happens to reports that still contain Python visuals after the deprecation date?The report itself loads. Sections without Python or R visuals render normally. The Python and R visual tiles display as blank white boxes, with no error message shown to the end user.

Is there an alternative embedded analytics platform for ISVs moving away from Power BI Embedded?Several embedded-native platforms exist, including Zoho Analytics, which was designed for multi-tenant ISV deployment and handles Python-based computation at the data preparation layer rather than inside the visualization runtime. This avoids the architectural dependency that drove the Power BI deprecation.

How do I find out which of my embedded reports use Python or R visuals?The Power BI REST API exposes report metadata including visual types. Use the GET /groups/{groupId}/reports endpoint to retrieve reports, then inspect the report's page and visual metadata. Third-party audit tools for Power BI can also surface this report content at scale.

Zoho Analytics is a multi-tenant embedded analytics platform built for ISVs and SaaS companies, among others. Learn more about our embedded analytics solutions.