Migrating From Azure Analysis Services to Power BI - What You Need to Know

If you're running Azure Analysis Services (AAS) today, you've probably been watching Power BI's capabilities creep closer and closer to what AAS offers. And you've probably started asking the same question a lot of our clients ask: "Should we migrate?"

The short answer is yes, probably. The longer answer involves a bunch of caveats that Microsoft's migration documentation covers in detail. But here's the practical perspective from someone who's helped multiple Australian organisations through this transition.

Why This Migration Makes Sense Now

AAS has been a solid platform. We've deployed it for enterprise clients who needed a proper tabular model engine sitting between their data warehouse and their reporting layer. It works. It's mature. The tooling is familiar if you've been in the Microsoft BI ecosystem for any length of time.

But here's the thing - Microsoft has been steadily pouring investment into Power BI in Fabric while AAS has been in maintenance mode. There's no deprecation announcement (and Microsoft has explicitly said there are no plans for one), but the writing is on the wall. New features land in Fabric. AAS gets stability patches.

The gap in capabilities has been growing every quarter. Features like hybrid tables, automatic aggregations, Direct Lake mode, and optimised memory management are all Fabric-only. If you're staying on AAS, you're leaving performance and functionality on the table.

What Power BI in Fabric Gives You That AAS Doesn't

Let me be specific about what you gain, because vague "it's better" statements don't help anyone make a business case.

Co-location of models and reports. This is bigger than it sounds. Right now, if you're running AAS, your reports live connect to the AAS model. That works fine, but it means you're managing two separate services, two sets of credentials, two cost lines. Moving to Fabric puts your semantic models and reports in the same workspace. One service. Simpler governance. Easier for your team to manage.

Better scalability architecture. AAS scales by server size - you pick a tier (S1, S2, etc.) and that's your ceiling until you manually scale up. Fabric uses a distributed architecture with CPU smoothing, which means temporary spikes in query load don't necessarily mean you need to jump to a bigger tier. We've seen clients reduce their effective BI compute costs by consolidating onto Fabric SKUs, though this depends heavily on workload patterns.

Hybrid tables. This is one of the most useful Fabric features for organisations that need near real-time data without fully committing to DirectQuery. A hybrid table keeps historical data in Import mode (fast) while the most recent partition uses DirectQuery (current). You get performance for historical queries and freshness for recent data. We've deployed this pattern for several retail clients who need yesterday's sales in seconds but also need today's numbers to be live.

Direct Lake mode. If you're using OneLake as your data storage layer, Direct Lake lets Power BI query delta tables directly without import or DirectQuery. It's fast - noticeably faster than DirectQuery because it reads columnar data from OneLake into memory on demand. For organisations already invested in Fabric's data engineering workloads, this is a significant advantage.

Autoscale. Fabric can automatically add compute capacity when you're under heavy load. AAS doesn't do this - if you hit your server's ceiling during a busy reporting period, queries slow down or fail until you manually intervene. With Fabric's autoscale, you get burst capacity when you need it and only pay for the extra compute while it's active.

What to Watch Out For

This isn't a lift-and-shift with zero friction. Here's where we've seen migrations get complicated.

XMLA Endpoint Differences

If your team uses XMLA-based tools - Tabular Editor, SQL Server Management Studio, or custom scripts that manage partitions and process tables - most of this will work in Fabric. Power BI exposes an XMLA endpoint that supports read/write operations. But "most" isn't "all." Some XMLA operations behave slightly differently. Test your tooling before you commit to a migration date.

Processing and Refresh Semantics

AAS processing is straightforward - you tell it to process and it processes. Fabric semantic model refresh has some nuances around sequential vs parallel refresh, Enhanced Refresh API behaviour, and how refreshes interact with capacity throttling. If you have complex processing schedules with dependencies between tables, plan for some rework of your refresh orchestration.

Query Scale-Out Differences

AAS query scale-out uses read-only replicas - it's a well-understood pattern. Fabric handles query scale-out differently. It works, and for most workloads it works well, but the mechanics are different. If you've built monitoring or load balancing logic around AAS replicas, that logic won't directly translate.

Cost Modelling

This is where things get genuinely tricky. AAS pricing is per-server, per-hour. Fabric pricing is per-capacity, and that capacity is shared across all Fabric workloads (not just BI). Comparing the two directly isn't straightforward.

In our experience, organisations that consolidate from a dedicated AAS server to a Fabric capacity that also runs data engineering and data science workloads often come out ahead on total cost. But if you're running a single AAS model and nothing else, the maths might not work in your favour. Run the numbers for your specific situation.

The Migration Path

The actual technical migration follows a fairly predictable path:

1. Assess your current AAS model. Document the tables, relationships, security roles, processing schedules, and any XMLA-based tooling. Identify calculated tables and calculated columns that might need adjustment.

2. Create a Fabric workspace and capacity. Choose the right SKU based on your current AAS tier and expected workload. Start with what you think you need - you can scale up without downtime.

3. Deploy the model. Use Tabular Editor or Visual Studio (SSDT) to deploy your existing model to the Fabric workspace via the XMLA endpoint. The deployment process is essentially the same as deploying to AAS.

4. Migrate security. Row-Level Security (RLS) roles and rules should transfer directly, but test them. Object-Level Security (OLS) and dynamic security patterns also need verification.

5. Reconnect reports. Update your Power BI reports to connect to the new Fabric semantic model instead of the AAS instance. If you have reports using live connections, you'll need to update the connection strings.

6. Validate. Run your key reports against both the old AAS model and the new Fabric model in parallel. Compare numbers. Check performance. Verify that security roles behave correctly.

7. Cut over. Once you're confident the Fabric model is producing correct results with acceptable performance, redirect all users and decommission the AAS instance.

Self-Service and Enterprise BI in One Place

One of the less obvious benefits of this migration is what happens after the technical work is done. With AAS, there's often a sharp divide between "the enterprise model" (managed by IT, hosted in AAS) and "the self-service reports" (built by business analysts in Power BI). That divide creates friction.

In Fabric, the enterprise semantic model and the self-service reports live in the same workspace ecosystem. Business analysts can build their own reports against the enterprise model without IT having to set up live connections to an external service. IT can adopt and operationalise reports that business users have built when those reports become important enough to warrant governance.

This convergence isn't just a nice talking point - we've seen it genuinely reduce the time it takes for insights to go from "someone's personal report" to "the official version everyone trusts."

Should You Migrate Now or Wait?

If you're actively hitting limitations with AAS - performance, cost, features you need - migrate now. The tooling and migration path are mature enough that there's no reason to wait.

If AAS is working fine and you're not under pressure, you can afford to be more deliberate. Plan the migration for a natural transition point - a model refresh, a platform renewal, or a new BI project that would benefit from Fabric features.

What I wouldn't do is invest in expanding your AAS footprint. New models, new servers, new development work - do that in Fabric. Treat AAS as stable-but-legacy.

Getting Help With the Migration

We've helped multiple Australian organisations migrate from AAS to Power BI in Fabric, and each one has had its own quirks. The technology transfer is usually the straightforward part. It's the organisational pieces - training teams on Fabric, updating operational procedures, reworking monitoring and alerting - that take the most effort.

Our Power BI consultants and Microsoft Fabric consultants can help you plan and execute the migration. Whether you need a full assessment or just someone to validate your migration plan, reach out to us and we'll figure out the right level of support.