In the previous post I've given you the specs, the costs and some of the more abstract things. Now it's time for a case study.

Providing external customers with data

Now lets tackle a very specific case in which you are already mixing and matching technologies of the Microsoft stack and are seeking to improve the mix. Ideally you would want less components, keep all existing features and add new ones, without paying (significantly) more.

You already have a solution in place, which works fine. But you are always looking into improving it keeping it up to date and as future proof as possible.

Your current architecture looks like this:

SQL -> AAS -> Power BI -> Power BI Embedded Premium

Why do I want to look at this specific case? Well, while reading up on a lot of things related to the Power Platform I get the very strong impression that Microsoft is aiming it to be a one-stop shopping platform for all your BI and reporting needs. And the aforementioned components are some quite basic building blocks that you would find in most solutions.

Power BI Embedded will probably not be widely used in these types of solutions. But I use it in my blog, so I wanted to include it so I can see how it could fit in the big scheme of things. So there :-P.

First stop: features needed

You typically choose your technology based on the needs of what your trying to build or provide for your client. In this case it's quite straight forward:

  • You need SQL for data storage and some preprocessing before the data gets into the data model on AAS
  • You choose Power BI (and Power BI Embedded) since it's a tool that provides lots of options of presenting data to clients. And is very easy to use, since it doesn't necessarily require programming skills if the data (model) that it connects to has everything you need. Lastly, since you're already running on Microsoft products, using it would require less integration pains. Since you want to potentially display these dashboards and reports to customers outside of the Power BI Service environment, we need Power BI Embedded.
  • No building reports with lots of data in Power BI directly on SQL works perfectly fine. But if the report needs calculations that aren't present in SQL, you need to enrich the data with these calculations (enter DAX and depending on your connection M Query). Plus chances are the reports will load quite slowly, since SQL's strength is data storage not performance. So to tackle both the performance and extra calculations issue, we often introduce AAS. It boosts load performance, and packs a punch when you need lots of new calculations.

Since we're interested in whether Power BI Premium can replace AAS, lets take a closer look at what features we need in order to determine whether the shift can happen at all.

Currently AAS:

  • Is being fed from views in SQL
  • Contains some calculated columns, primarily to build up hierarchies (such as DateTime)
  • Contains a number of tables in Star Schema
  • Contains a number of measures needed for reporting
  • Contains some logic on which version of the calculations is needed depending on input filters
  • Has Row-Level Security

Second stop: pricing

This is where it gets interesting, because AAS and Power BI Premium don't just cost different amounts, they cost in completely different shapes.

Azure Analysis Services is billed per hour, by tier (the S-tier standard tiers being the relevant ones here). The killer feature for the wallet is that you can pause it. If your model only needs to be live during business hours, or only while a nightly refresh runs, you pay for those hours and nothing else. For an intermittent workload that's genuinely cheap.

Power BI Premium (the P-SKU capacities) is billed per month, as a fixed dedicated capacity that is just... on. You're renting the whole machine whether you're hammering it or it's idle at 3am on a Sunday. The upside is that everything's included: not only the model engine, but paginated reports, dataflows, AI, and — the big one for a lot of shops — unlimited report viewing without per-user licences.

And there's a newcomer to factor in: Premium Per User (PPU), announced recently, which gives you most of the Premium goodies on a per-user monthly basis instead of a whole capacity. For a smaller audience that changes the maths yet again.

So for our specific case — external customers, served through Embedded — the honest answer is "it depends on your shape." Always-on with lots of viewers pushes you toward a Premium capacity. Intermittent, a few heavy users, cost-sensitive pushes you back toward pausable AAS. There isn't a single winner; there's a winner for your usage pattern, which is exactly why the feature table in Part 1 couldn't decide it for you.

Third stop: migration effort

I've done a ton of research and tested some things on my own Azure account as well, and migrating from AAS to Power BI Premium can vary between a few clicks and a genuine project. Here are the basic strokes.

The good news: because Premium's dataset engine is Analysis Services under the hood, a lot moves across cleanly. Your star schema, your measures, your calculated columns, your row-level security — the core of the model — generally come over with little drama. If your model is "normal", you're closer to the few-clicks end than you'd fear.

The catches live in the edges. The SQL views feeding the model need to be reachable the same way, so gateways and connections have to be reconsidered. The logic that swaps calculation versions based on input filters wants testing carefully, because that's exactly the kind of thing that behaves subtly differently once it's running inside the Power BI Service. And anything leaning on an AAS-specific feature from that Part 1 table — object-level security, perspectives, scale-out — needs a proper rethink, because Premium hasn't caught up on all of those yet.

My honest verdict for this case: the shift is very doable, the model itself is the easy part, and the real effort is almost entirely in the connections, the testing, and confirming you're not depending on an AAS feature Premium doesn't have. Do a proper inventory against the Part 1 table first, and you'll know within an afternoon whether you're looking at a few clicks or a few weeks.