How Rede Vitrine went from 180 paid licenses to 400+ people with data access, cutting costs by 73%

By Tamires Cavani, 08/21/2026

The problem wasn't BI. It was the billing model.

Rede Vitrine (a fictional name for this case) is a retailer with 45 physical stores, one distribution center, and about 700 employees. Like many companies investing in data, it took the natural path: it started with a few Power BI reports, saw the value, and kept expanding.

Three years later, the BI team was celebrating adoption and struggling with the bill.

There were 180 active Power BI Pro licenses, spread across regional managers, store supervisors, finance, operations, and leadership. At a reference cost of $80/user/month, that meant:

$14,400/month in individual licensing alone $172,800/year.

And the worst part: only 9 people in the company actually built reports. The other 171 just needed to open a dashboard, look at a number, and make a decision. Even so, they paid the same license as the people building the models.

At the same time, there was a waiting list: more than 220 store employees shift supervisors, operations leads, warehouse staff who the company wanted to give access to the metrics, but couldn't afford to license.

The result was a common paradox: BI had become too successful for the cost model that supported it.

The diagnosis: who actually needs an individual license?

Before any architecture change, Vitrine's data team did a simple mapping, splitting users into two groups:

• Content producers people who create and publish reports, model data, and define business rules. This group: 9 people.
• Content consumers people who only view, filter, and interact with ready-made dashboards. This group: 171 active users, plus a backlog of demand from more than 220 more.

That second group was the problem and, at the same time, the opportunity. Consumers don't need an individual Pro license if report distribution runs through a properly sized shared capacity.

The architecture change

Vitrine moved from a model based solely on per-user licenses to an architecture combining:

• Microsoft Fabric as shared processing capacity, sized by load (not by number of users);
• An in-house access portal, unifying the report catalog, SSO with the corporate AD, access control by store/region, and favorites so store staff never needed to understand what a workspace or a dataset is, just open the portal and see their metrics.

The 9 content producers' licenses were kept they still need a Pro license to publish and manage models. What changed was everything downstream of that.

The numbers

The contracted Fabric capacity (F4 reference tier, resized after the pilot) plus portal costs came in at around $4,760/month even below the initial estimate, because the real usage pattern (many simple, simultaneous queries, few heavy models) required less capacity than the team had projected.

But the number that mattered most internally wasn't the savings. It was this:

Data access more than doubled (from 180 to 412 people) at a cost 73% lower than the previous model.

In other words: Vitrine didn't trade savings for reach. It got both at the same time because in a capacity-based architecture, adding user number 300 has a marginal cost close to zero, while under the license model that person would cost $80/month like any other.

What changed beyond the cost spreadsheet

• Store supervisors started tracking stockouts and daily sales without depending on a report emailed by the regional office.
• Finance gained real-time visibility by store, something that previously only existed in consolidated form, because licensing a dashboard per store wasn't feasible.
• Operations eliminated much of its manual spreadsheet reporting, since the portal became the single source of metrics for teams that previously didn't even have Power BI access.
• Leadership started treating BI internally as "the platform," rather than "that set of dashboards finance has."

According to Vitrine's fictional Data Director in the case, "the biggest change wasn't technical, it was cultural: once the cost of giving one more person access stops being a budget decision, BI stops being a scarce resource and becomes part of daily life for any team."

What Vitrine would do differently (lessons from the case)

Not everything was immediate. Some lessons came from learning along the way:

• Size by load, not by user count. The first capacity estimate was oversized because it started from the number of users, not actual behavior (simultaneous queries, model complexity).
• Not every old report should have been migrated as-is. Poorly optimized models, inherited from years of "stacking things on," consumed capacity disproportionately. A performance review before migration would have avoided mid-course capacity adjustments.
• Governance needs to be built alongside the portal, not after. Defining access control by store/region from the start avoided security rework later on.

Does this model make sense for every company?

No. And that's an important point even in a success case: capacity-based architecture tends to pay off when there are lots of people consuming and few producing content exactly Vitrine's profile, with 9 producers for hundreds of consumers.

Companies with few users, or with a large number of people creating and editing reports (not just consuming), may still be better served by the traditional per-user licensing model.

The right question isn't "is licensing or capacity cheaper." It's: what's the ratio between who creates and who consumes data at my company and how much is it costing today to keep the right people locked out of access?

This is a real case with fictional, illustrative data, built to practically demonstrate how moving from per-user licensing to shared capacity can impact cost and reach at the same time. The numbers reflect a simulation, not a quote actual results depend on SKU, region, usage patterns, Microsoft contract, and the architecture implemented.