Migrating Azure Analysis Services to Power BI Premium - Six Scenarios Compared

Migrating from Azure Analysis Services (AAS) to Power BI Premium is one of those projects that sounds straightforward on paper but gets complicated fast once you start looking at the licensing numbers. The technology migration itself is the simpler part. Getting the licensing right - matching your existing workloads to the right combination of Premium capacities and user licences - that's where the real planning happens.

We've worked through several of these migrations with Australian organisations, and the licensing question comes up in every single engagement. Microsoft's migration scenarios documentation lays out six hypothetical scenarios. They're a good starting framework, but they skip a lot of the nuance that matters in practice. Let me walk through what these scenarios actually mean and where the real decisions lie.

Why Organisations Move Away from AAS

Before getting into the scenarios, it's worth understanding why this migration keeps coming up.

AAS worked well as a standalone analytical engine. But it sits in an awkward spot now. Power BI has absorbed most of its capabilities, and running both systems means you're paying twice - once for the AAS compute and once for the Power BI frontend. You're also managing two separate environments, two sets of deployment pipelines, and two different monitoring setups.

Power BI Premium gives you the same tabular modelling engine (it's SSAS under the hood in both cases) plus the reporting layer, data refresh infrastructure, and a growing set of features that AAS will never get. Things like composite models, automatic aggregations, and dataflows gen2 are Power BI only.

The financial argument usually wins the conversation. But the operational simplification is just as valuable, if less visible on a spreadsheet.

Understanding the Licensing Building Blocks

Before jumping into scenarios, you need to understand three licence types:

Power BI Pro is the basic per-user licence. It allows users to create and share content but limits dataset sizes to 1 GB and doesn't provide dedicated compute capacity.

Premium Per User (PPU) gives each user their own slice of premium capacity. Datasets up to 100 GB, paginated reports, AI features - all included. The catch is every user who accesses the content needs a PPU licence, which gets expensive at scale.

Premium capacity (P1 through P5) is a shared pool of compute that any number of users can access with just a Pro licence. The capacity size determines the largest dataset you can host and the total compute available. P1 supports datasets up to 25 GB, P2 up to 50 GB, P3 up to 100 GB, and so on.

The right mix depends on three factors - your largest data model, your total user count, and how many regions you operate across.

Scenario 1 - Single Region, Large User Base

This is the most common pattern we see in Australia. The organisation already runs Power BI Premium for reporting and uses AAS as a backend semantic layer. They've got production models ranging from 15 GB to 60 GB, a test environment, and a dev environment. Around 20 developers maintain everything.

The migration path here is to consolidate the AAS models into an existing (or upgraded) Premium capacity. If your largest model is 60 GB, you need at least a P3 capacity. The existing P2 that handles reporting gets upgraded rather than adding a separate capacity.

The subtle point Microsoft makes - and it's correct - is that the 20 developers should move to PPU licences for their test and dev work. Premium capacity is expensive, and dedicating P-SKU capacity to test workloads used by 20 people is wasteful. PPU gives each developer up to 100 GB model support for testing, at a fraction of the cost.

What the docs don't mention: CPU consumption between AAS and Power BI Premium is not one-to-one. We've seen cases where models that ran comfortably on an S2 AAS SKU consumed more CPU on a Premium capacity due to differences in query caching, memory management, and background refresh overhead. Don't assume you can map AAS SKU sizes directly to Premium capacity sizes. Run parallel workloads for a couple of weeks before cutting over.

Scenario 2 - Multiple Regions

Things get more expensive when you need capacity in different regions. An organisation with production models in West Europe, Brazil South, and West US needs a separate Premium capacity in each region. You can't serve a model in Australia from a capacity running in the US - latency makes it impractical, and data residency requirements may prohibit it entirely.

This scenario forces you to size each regional capacity independently based on its largest model. The West Europe region with a 60 GB model needs a P3. Brazil South with a 30 GB model needs a P2. And so on.

The Australian angle: Data sovereignty matters here. If you're running AAS in Australia East or Australia Southeast, your Premium capacity needs to stay in one of those regions. This is non-negotiable for government clients and increasingly expected by enterprises in financial services and healthcare. We've seen organisations accidentally provision capacity in a US region because that was the default, then have to redo the entire setup when compliance caught it.

Multi-region deployments also mean multi-region monitoring. Power BI's capacity metrics app gives you visibility into each capacity, but you need to set up monitoring for each one separately. It's more operational overhead than a single-region deployment.

Scenario 3 - E5 Customers with Existing Pro Licences

Many Australian enterprises already have Power BI Pro included in their Microsoft 365 E5 subscriptions. These organisations often bolted AAS onto their stack later for models that exceeded Pro's 1 GB dataset limit.

The migration path is elegant here - add a Premium capacity to host the large models, and the existing Pro users can access them without any licence changes. The only additional cost is PPU licences for the developers who need to work with test models above 1 GB. There's even an add-on path to step up from Pro to PPU for those users.

Watch out for this: E5 Pro licences and standalone Pro licences behave identically in Power BI, but the billing sits in different places. When you're calculating migration costs, make sure your finance team understands which Pro licences are "free" (bundled with E5) and which are separate line items. We've seen cost analyses that double-counted Pro licence costs because the person doing the spreadsheet didn't know about the E5 bundle.

Scenario 4 - Smaller User Base, PPU-Only

This is the most cost-effective path for smaller organisations. If you have fewer than 500 users and your models fit within PPU's 100 GB limit, you might not need Premium capacity at all. Just put everyone on PPU.

With 350 users and 5 developers, PPU covers both production access and development work. No capacity to manage, no capacity autoscale to configure, no capacity metrics to monitor. It's simpler all around.

The tradeoff: PPU requires every content consumer to have a PPU licence. At 350 users, the maths usually works out cheaper than a P-SKU capacity. But there's a tipping point, somewhere around 500-700 users depending on your region's pricing, where a Premium capacity becomes cheaper per user. Run the numbers for your specific scenario. If you're growing, factor in where you'll be in 12-18 months, not just today.

Also consider: PPU doesn't support some enterprise features like Multi-Geo deployments or BYOK (bring your own key) encryption. If those are on your roadmap, PPU-only won't cut it.

Scenario 5 - Very Large Models

The enterprise scenario. Models above 100 GB, multiple production environments, dozens of developers. This is where you're looking at P5 capacities and the costs get significant.

When your largest model is 220 GB, you need the highest capacity tiers. There's no way around it. The three production AAS instances (S9, S8, S4) consolidate onto a single P5 capacity.

Real talk on costs: A P5 capacity is expensive. Before committing, verify whether model sizes can be reduced through better data modelling. We've worked on projects where a 200+ GB model was brought down to 80 GB through proper star schema design, removing unused columns, and implementing incremental refresh instead of full loads. That drops you from a P5 to a P3, which is a substantial cost difference.

Also question whether all those models genuinely need to be on the same capacity. If they serve different business units with different usage patterns, separate smaller capacities might give you better performance isolation and cost flexibility.

Scenario 6 and Beyond - What the Docs Don't Cover

Microsoft's documentation stops at six scenarios, but real migrations often involve combinations. Here are patterns we see regularly:

Hybrid approaches. Some organisations keep a small AAS instance for specialised use cases (like external client-facing models) while migrating internal analytics to Premium. This is valid, but make sure you have a clear reason for keeping AAS - "we haven't got around to migrating it yet" is not a good reason.

Fabric capacity vs. classic Premium. Microsoft is increasingly pushing Fabric capacity as the replacement for classic Premium P-SKUs. Fabric capacity (F-SKUs) offers more flexibility with pay-as-you-go pricing and the ability to pause compute. If you're starting a new migration today, evaluate F-SKUs alongside P-SKUs. The pricing models are different, and F-SKUs may work out cheaper for workloads with variable demand.

Development and test strategies. The documented scenarios assume developers all use the same environment. In practice, many teams want isolated development workspaces. PPU handles this well - each developer gets their own workspace with premium features. But coordinate your deployment pipelines so that changes flow from PPU dev workspaces to the production Premium capacity in a controlled way.

Planning Your Migration

Start with an honest inventory. Document every AAS model - its size, refresh frequency, query patterns, and who accesses it. Then map that to the licensing options.

Don't underestimate the CPU analysis. Run parallel workloads if you can. AAS and Power BI Premium use the same tabular engine, but the surrounding infrastructure handles memory, caching, and background operations differently. What ran on an S2 won't necessarily fit on the equivalent Premium capacity without adjustment.

Factor in growth. AAS models tend to grow over time as teams add more data and more measures. Size your target capacity for where you'll be in a year, not where you are today.

And get your stakeholders aligned on timeline. We've seen migrations stall because the team doing the technical work was ready but the licensing procurement took three months to process through enterprise purchasing.

If you're planning an AAS-to-Premium migration and want help working through the licensing maths, our Power BI consultants have done this enough times to spot the gotchas early. We also work with Microsoft Fabric for organisations looking at the newer capacity models, and our broader Azure AI consulting practice covers the data platform architecture around these decisions.

For the full set of scenarios with specific SKU mappings, see Microsoft's migration scenarios documentation.