TL;DR
An SSAS Tabular model becomes a Microsoft Fabric semantic model with almost no DAX changes, since the two engines are the same. A Multidimensional cube is a full rebuild, because Fabric replaces MDX with DAX and has no cube form. Direct Lake mode reads Delta tables straight from OneLake. A refresh takes seconds instead of minutes. Calculated columns fail on Direct Lake, so that logic moves into the Lakehouse. Kanerika’s FLIP accelerator automates the transfer and validation, and it shrinks a months-long build to 2 to 8 weeks.
Key Takeaways SSAS Tabular and Microsoft Fabric semantic models run on the same engine, so most DAX measures and relationships carry over with light validation only. SSAS Multidimensional cubes rely on MDX, unary-operator hierarchies, and writeback, which have no direct Fabric equivalent, so they need a genuine re-model. Direct Lake mode reads Delta tables in OneLake directly into memory, so refreshes run in seconds rather than the minutes or hours of an SSAS processing cycle. Calculated columns are not supported on Direct Lake tables, so shaping logic moves upstream into the Lakehouse or a Dataflow Gen2 before the model sees the data. Migration effort concentrates in the MDX inventory, not the table count, which makes the source-mode assessment the single best predictor of the timeline. A Kanerika SSAS-to-Fabric migration delivered 25% higher real-time analytics capability, 40% less manual maintenance, and 35% lower operating cost. Watch on YouTube
State of Enterprise Data Migration 2026: Why 73% of Migrations Fail
Kanerika’s own 2026 research across enterprise data migrations found why the majority fail or stall. If SSAS is on your decommissioning list, this is the failure pattern to plan against before you start.
A Month-End Close That No Longer Waits for the Cube Picture the finance analyst waiting on a processing window that ran long, the Power BI author who cannot connect to a model without the VPN, and the BI manager pricing a server refresh for a workload Microsoft itself has stopped investing in. That trio is the real reason SSAS to Microsoft Fabric migration jumped from back-burner conversation to standing agenda. Fabric carries the same semantic-model discipline into a capacity-based, cloud-native platform, and it registers every refresh the moment data lands in OneLake.
The migration still has to be done accurately. Multidimensional cubes, MDX scripts, and security roles do not lift-and-shift, and every calculation needs to reconcile against the reports the business already trusts. Below, the mapping tables, conversion rules, roadmap, and effort drivers cover both paths.
What Is SSAS, and Why Are Enterprises Moving Off It? SQL Server Analysis Services (SSAS) is Microsoft’s on-premises OLAP and semantic-modeling engine, shipped as part of SQL Server since 2005. It comes in two distinct modes that behave like different products. Multidimensional is the MDX-based OLAP cube built for pre-aggregated star-schema reporting. Tabular is the in-memory, DAX-based engine introduced in SQL Server 2012, which later became the same engine behind Power BI Desktop and the entire Fabric semantic-model layer. The distinction matters so much that we treat it as its own migration decision below.
Both modes are still fully supported, but Microsoft’s investment has moved almost entirely to the cloud. SSAS receives security patches and nothing else; it will not see Direct Lake refreshes, Copilot integration, or any of the semantic-model capabilities landing in Microsoft Fabric . Enterprises respond to that investment asymmetry long before any end-of-life date arrives. The same pressure drives neighboring projects such as Azure to Fabric and Databricks to Fabric migrations.
Listen on Spotify
Why Fabric Is Becoming the Go-To Data Platform | SSIS to Fabric
The operational complaints repeat across almost every SSAS estate we assess.
Remote access is VPN-gated. SSAS instances sit behind the corporate network, so distributed and hybrid teams need VPN tunnels just to connect Power BI Desktop or Excel to a model.Scaling means buying hardware. More concurrent users or bigger models mean provisioning bigger servers months in advance, not sliding a capacity control.Processing cycles fight the clock. Large Tabular models need scheduled, sequential processing windows overnight, and a load that runs long makes the next morning’s reports stale.Cloud interoperability needs manual glue. Connecting on-prem SSAS to the Power BI Service, Fabric pipelines, or third-party BI requires an on-premises data gateway and configuration for each new integration.Skills are drifting. The team that wrote MDX calculated members in 2015 is retiring, while every new hire arrives fluent in DAX, notebooks, and Git-backed workflows instead.Is Your Organization Actually Ready to Migrate? Not every SSAS estate should move to Fabric today. Before scoping a project, check whether these signals actually apply, because migrating an estate that is not ready just relocates the same problems onto a new platform.
Datasheet
FLIP Migration Accelerators for Faster Data Platform Migration
How Kanerika’s FLIP accelerators automate the mechanical work of a platform migration — schema conversion, calculation translation, and visual recreation — so converted logic is validated rather than rebuilt by hand.
View the Datasheet →
Analytics scale is outgrowing on-prem hardware. If the team is already budgeting a server refresh for growth, that spend is better directed at the migration itself.Remote or hybrid teams need direct access. VPN-gated SSAS access shows up as a recurring ticket queue, not a one-off complaint.The calculation layer is mostly Tabular, or the Multidimensional inventory is small. A handful of simple cubes is a very different project from dozens of MDX-heavy cubes with custom rollups, so know which estate you have before committing a timeline.Someone owns validation. A BI or data team member needs authority to sign off on every migrated calculation against production reports; without that owner, migrations stall in an unvalidated limbo.Downstream cloud integrations already exist or are planned. If Power BI Service, Fabric pipelines, or other cloud tools are already in use, Fabric removes the gateway and VPN glue they currently need.If most of these do not apply yet, meaning a small on-prem footprint, no remote-access pain, and no cloud integrations planned, then foundational modernization is the better next step. Cleaning up the existing model, documenting calculation logic, and fixing data-modeling hygiene first makes the later migration faster anyway.
Estates running Azure Analysis Services (the PaaS sibling of SSAS) get a slightly different map. Microsoft’s migration guidance routes Azure Analysis Services workloads toward Power BI semantic models on Fabric, using the same Tabular engine underneath. Teams hosting models on SQL Server on-premises have one more consideration, whether server-side features that Power BI does not offer are in use; those need explicit handling in the design phase rather than discovery during validation.
SSAS object Fabric equivalent Transfer effort Data sources OneLake, Lakehouse tables via pipelines or shortcuts Low, once Delta landing exists Fact and dimension tables Delta Parquet tables read by Direct Lake Low to medium, conversion tooling exists DAX measures (Tabular) DAX measures in the semantic model Low, validate against originals MDX scripts and named sets DAX measures and calculation groups High, manual rebuild per script Calculated members with unary operators Redesigned hierarchy plus custom DAX rollup logic High, design work per hierarchy Bridge cubes (many-to-many) Bridge table with bidirectional or CROSSFILTER relationships Medium, cardinality testing required Partitions and storage settings Direct Lake framing or explicit Import partitions Low to medium, policy decision Roles and security filters Row-level and object-level security on Microsoft Entra ID groups Medium, redesign with testing
Readiness is also a governance question. Fabric workspaces, deployment pipelines, and Git integration change how models are versioned and promoted, and an estate with no release discipline on SSAS will hit that gap the moment the first Fabric model is promoted. Budget a small readiness slice for process work alongside the technology work.
SSAS Multidimensional vs. Tabular: Which One Are You Actually Migrating? The single biggest scoping mistake in an SSAS migration is treating both modes as the same problem. They are not, and the gap shows up immediately once conversion starts.
Tabular models already speak the target language. They run the same VertiPaq engine and the same DAX layer that Fabric semantic models run, so most measures, relationships, and hierarchies migrate with light validation rather than a rewrite. The work is largely mechanical: import the model, re-point data sources to OneLake or a Fabric Lakehouse, and test. Calculation groups and compatibility-level concepts carry the same definitions on both sides.
Multidimensional cubes are the harder migration. They are built in MDX and lean on features that have no equivalent in a DAX-based semantic model: writeback, parent-child hierarchies driven by unary operators, and many-to-many dimension relationships modeled as bridge cubes. None of these translate automatically.
Calculation groups, introduced at Tabular compatibility level 1500, close a large part of the gap by applying one reusable calculation across many base measures, which is exactly the class of problem unary operators and MDX scripts used to solve. Calculation groups do not recreate writeback or true many-to-many bridge logic, though, so those pieces need a genuine re-model, not a converter.
Practically, if the source model is Tabular, budget for a technical migration measured in weeks. If it is Multidimensional, budget for a redesign measured in months, and start by inventorying every MDX script and calculated member before touching a single cube dimension.
What Moves Where, and What Has to Be Rebuilt The clearest way to scope the project is to map each SSAS object type to its Fabric counterpart before writing any conversion plan. The mapping itself is stable; what varies is how much of each object your estate contains.
Table 1: SSAS to Fabric Object Mapping
Microsoft Fabric Semantic Models and Direct Lake Mode, Explained A Fabric semantic model is the direct successor to an SSAS Tabular model, with the same DAX engine and the same relationship and measure concepts. The difference is storage mode. A semantic model can run in three modes: Import, DirectQuery, and Direct Lake. Direct Lake is the one that changes the economics of a migration, and understanding Direct Lake semantic models in Power BI and Fabric is really the heart of the project.
Direct Lake reads Delta Parquet files straight out of OneLake into memory , without a separate import step. A refresh in Direct Lake mode is a metadata operation that re-points the model at the latest version of the underlying Delta tables, which Microsoft documents as framing, and it completes in seconds. An Import-mode refresh copies the entire dataset again, which is exactly the SSAS Tabular processing pattern the migration is meant to retire.
The trade-off is real. Calculated columns that reference Direct Lake tables are not supported, and heavy in-model transformations do not belong there at all. Direct Lake is built for performance at scale on data that is already clean, so typing, derived columns, and joins happen upstream in the Lakehouse via Spark, T-SQL, or a Dataflow Gen2. The guide to DAX calculated columns and tables in Fabric covers the patterns that survive the move.
Teams that migrate a calculated-column-heavy SSAS model without moving that logic upstream watch Direct Lake silently fall back to DirectQuery and lose the performance gain with no error message.
Dimension SSAS (on-premises) Microsoft Fabric (Direct Lake) Data loading Full processing cycle copies data into the model Metadata-only framing; data read from OneLake Refresh time Minutes to hours, depending on model size Seconds, independent of data volume Calculation language MDX (Multidimensional) or DAX (Tabular) DAX only Calculated columns Fully supported in both modes Not supported on Direct Lake tables; pre-compute upstream Scaling model Buy and provision more on-prem hardware Adjust Fabric capacity (F-SKU) allocation Security Windows/AD-based roles configured per cube Row and object security tied to Microsoft Entra ID Remote access Requires VPN or on-premises data gateway Native cloud access, no gateway Cost structure Fixed hardware plus SQL Server licensing Consumption-based Fabric capacity AI surfaces None beyond classic client access Copilot integration and Microsoft Fabric data agents
Capacity also behaves differently. Direct Lake models consume Fabric capacity only for the metadata operations and the queries that run against them, while an SSAS estate pays for idle RAM around the clock. Connector throttling and measure misuse still matter, though; a semantic model that pushes first-pass event trimming to the server, as Microsoft documents for DirectQuery optimization, holds its headroom under load. Watch capacity metrics from the first week of the parallel run, not after go-live, so the resize decision is made on real query traces.
This is also where Fabric’s default semantic models help: every Lakehouse and Warehouse automatically provisions a semantic model over its tables, and Microsoft’s own documentation treats that auto-generated model as the normal starting point. Extending the default model, or hand-building on top of the landed Delta tables, beats building a semantic model from a blank page.
What actually moves to OneLake, and in what order: the fact and dimension tables a Direct Lake model reads must land in OneLake as Delta tables, and that is the non-negotiable part. Reference data that is small and rarely changes, such as lookup tables or one-off exports, can be imported directly and does not need to move on day one.
The sequencing that works in practice moves the highest-traffic fact tables first, the ones driving the slowest SSAS processing cycles today, validates Direct Lake performance against them, and brings the rest of the estate over in later phases rather than one cutover. The OneLake catalog makes that mixed-state period visible to data stewards instead of tribal knowledge.
SSAS vs. Microsoft Fabric: Architecture, Cost, and Performance Compared Table 2: SSAS vs. Microsoft Fabric Semantic Models
The right pick depends on how much longer the organization can tolerate VPN-gated access, fixed hardware costs, and manual model upkeep. For a Tabular-only estate, Fabric is close to a pure upgrade. For a Multidimensional estate, it is a genuine re-architecture that is still worth doing, as long as the plan and timeline reflect that difference from day one.
DAX and MDX: What Converts Cleanly, and What Doesn’t Model conversion lives or dies on the calculation layer, so it is worth breaking down what actually happens to each type of logic. The MDX patterns below account for almost every conversion problem we see in a Multidimensional migration.
Table 3: MDX Pattern to DAX Approach
Every converted measure should be validated against production reports, not spot-checked in DAX Studio on a sample. A measure that looks right on ten rows can diverge at scale once real filter contexts and relationship cardinalities apply. If any dimension of the estate has not been inventoried by this point, the schedule risk lives in that gap, and the table count is a weak proxy for it; our data consolidation checklist applies here too when several SSAS projects are merging during the migration.
Aspect SSAS Tabular source SSAS Multidimensional source Calculation conversion DAX to DAX, mostly direct MDX to DAX, manual rebuild for complex logic Typical timeline Weeks Months Hardest feature to migrate Calculated columns referencing Direct Lake tables Unary-operator hierarchies and writeback Validation focus Measure checks against production reports Full reconciliation of every conversion group and bridge
Will Excel and MDX Client Reports Still Work? Excel pivot-table users are the easiest group to forget, and the hardest to disappoint. Excel can connect to a Fabric semantic model through Analyze in Excel, and the pivot experience remains faithful for measures and hierarchies. What Excel does not carry over is MDX scripting done at the cube layer, and heavy MDX-driven workbooks that practiced those tricks will need their calculations rebuilt as DAX measures or absorbed into the semantic model itself.
The same logic extends to legacy MDX-based report suites. Any scheduled report, dashboard, or embedded BI client that sends MDX directly at the SSAS endpoint needs assessment, because Fabric has no MDX consumer surface. The practical sequencing runs in three moves. Inventory every consumer of the SSAS endpoint, from Excel workbooks to third-party tools. Classify each by whether it speaks DAX, MDX, or SQL, and rebuild the MDX consumers first.
Teams that handle this step early report far less end-user friction at cutover; teams that discover a critical Analyst-managed MDX workbook in week six of a program have a hard conversation with finance.
There is a related subtlety worth naming for teams that keep both tools. Some organizations maintain SSAS alongside Fabric for a while, which preserves MDX tooling but doubles validation work. A staged retirement with a hard exit date, and a semantic model that covers Excel connectivity from day one, avoids the two-truths problem that parallel runs create. The Fabric capacity guide helps size that coexistence window.
Migration ROI Calculator
Estimate Your SSAS to Fabric Migration Savings
Now that the effort drivers are priced out, get a first estimate of the cost and time savings a Fabric migration could deliver for your specific SSAS estate.
Calculate Your Migration ROI The SSRS to Power BI migration playbook covers the sibling problem with paginated reporting.
A Practical Migration Roadmap The roadmap below is deliberately conservative; each phase ends with an artifact the next phase needs. Microsoft’s Fabric migration overview organizes the same flow by source technology, and its structured checklists are worth adopting into your own plan documents.
Assess. Inventory every model: mode (Multidimensional or Tabular), size, calculated columns, MDX scripts, security roles, partitions, and every report and consumer that depends on it. This is the step most teams under-scope, and it is the single biggest predictor of timeline accuracy.Design the target model. Map SSAS objects to Fabric equivalents, decide what runs Direct Lake versus Import mode, shape the Delta tables, and push calculated-column logic upstream into the Lakehouse.Convert and rebuild. Migrate Tabular models directly; rebuild Multidimensional cube logic as DAX measures and calculation groups, replacing unary-operator hierarchies and bridge-table patterns as needed.Validate. Run the old and new models side by side against the same reports and reconcile every number before anyone treats the new model as authoritative. Wild numbers discovered here, not at the user acceptance test, cost the least to fix.Migrate security and cut over. Rebuild row-level and object-level security on Microsoft Entra ID groups, run a parallel period with both systems live, then decommission SSAS once validation holds for a full reporting cycle.Validation depth scales with the source. A Tabular estate can reconcile a sample of representative reports per model. A Multidimensional estate needs full reconciliation of every converted calculation group and bridge table, ideally automated. Identical report inputs go into both engines, outputs compare cell by cell, and divergences get triaged into conversion defects, engine differences, or stale source data. Automation matters because manual spot checks tire, and the drift they miss is exactly what end users find first.
Tooling makes the reconciliation sustainable. DAX Studio and Tabular Editor handle the measure-level comparisons, while a simple reconciliation harness that logs both engines’ outputs per report page turns week-long manual checking into an automated regression suite. That one-off build outlives the migration itself and becomes the regression suite every future measure change runs inside.
Which reports count as the validation set is a decision to make explicitly rather than by convenience. Pull the twenty reports with the largest audiences, the ten with the most complex calculation logic, and every report tied to a regulatory filing, and treat that list as the acceptance suite. Anything discovered outside it during the parallel run gets logged, but does not extend the cutover automatically, or the program loses its exit gate to the tail of the long tail.
A date for the parallel run deserves its own line in the plan. Reconcile a full reporting cycle rather than a handful of spot-check days, because month-end closes, quarterly rollups, and annual hierarchies each exercise paths the other reports never touch. Teams that cut over after two clean closes rarely get a second chance, so the run period is a schedule item with its own acceptance criteria, signed off by the owner named in the readiness assessment.
Where Migration Effort and Cost Really Go Executives usually price an SSAS migration by table count, and that number is almost meaningless. Effort concentrates in the calculation and governance layers. The five drivers below explain most of the variance between a clean Tabular project that lands in weeks and a Multidimensional program that runs for quarters.
Cost moves with it. A decision on the exact Fabric capacity (an F-SKU) replaces both the hardware refresh and SQL Server licensing for the analytics tier, and the capacity bill behaves like a consumption curve instead of a 3-year capital item. Practitioner experience also shows Microsoft-funded paths can offset part of the program for qualifying estates, so evidence that the migration is well-scoped matters commercially as well as technically.
Table 4: Migration Effort by Source Type
How Row-Level and Object-Level Security Translate Security is the layer that breaks quietly, so it earns its own pass in every migration plan. SSAS role membership lives in Windows/AD groups managed on the cube. Fabric ties row-level security to Microsoft Entra ID groups through dynamic or static filters defined in the semantic model, and object-level security hides tables or columns from roles entirely. The OneLake security model and workspace-level permissions add layers SSAS never had, which is a net improvement for governance but demands explicit design.
The migration technique that works is a security matrix, built during assessment, listing every role, its members, the tables and filters it grants, and the reports depending on it.
Rebuild each row deliberately in Fabric, then test with the real group memberships rather than an admin account, because an administrator sees everything and hides exactly the failures RLS exists to catch. Dynamic filters deserve special care, as measures that ignore them silently return unfiltered totals for the worst users, the ones who should see less. The Fabric warehouse security playbook covers the warehouse-side controls that complement the model.
Common Migration Pitfalls to Avoid Each of these failure modes shows up late and expensive, which is the reason the roadmap above sequences the inventory and validation work so far in front.
MDX pattern DAX approach Risk Standard DAX measures (Tabular source) Migrate directly and validate against original output Low Time-intelligence MDX shells Rebuild once as a calculation group applied to base measures Low to medium Unary-operator parent-child rollups Redesigned dimension table plus custom DAX rollup logic High, costliest conversion in the estate Many-to-many via bridge cubes Bridge table with bidirectional or CROSSFILTER relationships Medium, watch for double-counting Writeback cubes Re-architect around a separate operational store the model reads High, requires redesign Cell-level security expressions RLS filters plus object-level security where supported Medium, model-dependent
Treating a Multidimensional cube like a Tabular model. Assuming MDX will mostly convert leads to underestimated timelines and half-working calculation groups discovered late in testing.Leaving calculated columns pointed at Direct Lake tables. This silently forces a fallback to DirectQuery, and the promised refresh-speed gains disappear without an obvious error message.Skipping side-by-side validation. A measure that returns the right total in isolation can still diverge once real report filters and relationship cardinalities apply.Migrating security as an afterthought. Row-level and object-level rules built for on-prem Windows/AD roles need redesign around Microsoft Entra ID groups, not a copy-paste. The Power BI row-level security model carries over conceptually but not configurationally.Running the cutover as a single big-bang event. A parallel-run period, where both SSAS and the new Fabric model serve the same reports, is what catches reconciliation gaps before end users do.Forgetting the MDX consumer inventory. The Excel inventory step in the compatibility section applies here: discovering an MDX-dependent workbook after cutting over turns a cutover into an emergency.How Kanerika Accelerates SSAS to Microsoft Fabric Migrations Kanerika’s FLIP accelerator was built to remove exactly the manual bottleneck this guide keeps running into. Rather than hand-converting each measure and security role, FLIP automates the relationship, calculation, and security-model transfer from SSAS, then reconciles the converted logic against the original model before anything goes live.
Case Study
SSAS to Microsoft Fabric Migration Boosts Model Efficiency
Kanerika automated the transfer of relationships, calculated tables, columns, and security settings from SSAS to Microsoft Fabric for an enterprise client, running the new model on Direct Lake. The result: a 25% increase in real-time analytics capability, a 40% reduction in manual maintenance effort, a 20% improvement in data integration efficiency, and 35% lower operational costs.
Read the Full Case Study It sits inside a wider data migration practice covering Azure Synapse and SQL Server sources alongside SQL Server and SSAS to Microsoft Fabric migration services , so a single program can carry the semantic models, the underlying databases, and the SSIS pipelines that feed them. Kanerika holds the Microsoft Data Warehouse Migration to Azure specialization, and the FLIP Migration Accelerator runs as a native Microsoft Fabric workload, available directly from a Fabric workspace since the March 2026 launch.
The engagement runs through the same five phases as the roadmap above, with the mechanical conversion automated and a Kanerika data engineering lead reviewing every calculation group and security-role rebuild rather than trusting a black-box converter. For Multidimensional sources, the team inventories every MDX script and unary-operator hierarchy first, because that inventory and the table count set the timeline together, in roughly that order of weight. Where legacy ETL needs the same modernization, the ETL process optimization approach reduces the rework before the models land in Fabric.
Kanerika Service
SQL Server & SSAS to Microsoft Fabric Migration Services
Kanerika's migration practice handles the full estate, SSAS semantic models, SQL Server databases, and SSIS pipelines, moving to Microsoft Fabric under one validated roadmap instead of three separate projects.
Explore Migration Services Manual migration leaves conversion errors that surface only after go-live. FLIP compresses a typical SSAS-to-Fabric migration from months into 2 to 8 weeks depending on model complexity, with governance and business logic validated at every stage rather than rebuilt after the fact.
Talk to Kanerika
Planning an SSAS to Microsoft Fabric Migration?
Get a scoped assessment of your SSAS estate, Multidimensional and Tabular, and a realistic migration timeline before you commit resources.
Book a Free Consultation Wrapping Up Microsoft Fabric is the successor platform to SSAS. Fabric carries all new analytics investment, from Direct Lake refreshes and capacity-based scaling to Copilot and the data agents, while SSAS sits in maintenance mode with security patches only. Tabular models make the move with light rework; Multidimensional cubes need a genuine re-model of MDX logic, hierarchies, and security. Either way, the project succeeds or fails on how carefully the calculation layer is inventoried and validated, far more than on how quickly the data itself moves.
If aging infrastructure, VPN-gated access, or growing maintenance overhead have become standing conversations for the analytics team, the path forward is clear. Score your estate against the readiness signals, prioritize data-modeling and consolidation cleanup where needed, and run the five phases with validation in front of cutover, holding the parallel run for a full reporting cycle before anyone retires the old cube farm.
Frequently Asked Questions
Why are organizations moving SSAS models to Microsoft Fabric? Organizations move off SSAS because Microsoft’s investment now flows to Fabric, while SSAS receives security patches only. Fabric adds cloud-native scaling, Direct Lake refreshes that complete in seconds, native remote access without a VPN or gateway, tighter Power BI integration, and Copilot and data-agent surfaces. The engine skills are also shifting, since new analysts arrive fluent in DAX and Git-backed workflows.
Can existing SSAS models be reused in Microsoft Fabric? Tabular models reuse very well. Tables, relationships, measures, and hierarchies carry over from the shared VertiPaq engine, and the main work is re-pointing data sources to OneLake and validating. Multidimensional cubes cannot be reused directly. Their MDX scripts, unary-operator hierarchies, and writeback features need rebuilding as DAX measures, calculation groups, and redesigned dimensions. An assessment grades each model’s reuse level before any timeline is quoted.
What happens to DAX calculations and calculation groups during migration? DAX measures move directly because both engines speak the same calculation language, though each one should be validated against the original SSAS output on real reports. Calculation groups work in Fabric’s Tabular engine at compatibility level 1500 and above, so they carry over at higher levels. Where a level is lower, the calculations are refactored once, ideally as calculation groups, before cutover.
How is security handled when moving from SSAS to Microsoft Fabric? Row-level and object-level security both exist in Fabric, rebuilt around Microsoft Entra ID groups instead of on-premises AD roles. The recommended technique is a security matrix built during assessment, listing every role, its members, and the filters it grants, then recreating each row deliberately in the Fabric model. Testing uses real user accounts, because admin accounts see everything and hide RLS defects.
What are the hardest parts of a Multidimensional cube migration? Three features drive nearly all the pain. Unary-operator parent-child hierarchies need redesigned dimension tables plus custom DAX rollup logic. Many-to-many bridge cubes become bridge tables with bidirectional or CROSSFILTER relationships, which double-count unless tested carefully. Writeback has no equivalent, so those use cases are re-architected around a separate operational store the semantic model reads. MDX scripts convert one by one into DAX measures or calculation groups.
How long does an SSAS to Microsoft Fabric migration take? A Tabular-only estate typically measures the migration in weeks, because the engine and the calculation language carry over. A Multidimensional estate measures it in months, driven by the MDX script inventory rather than table count. Parallel validation and a parallel-run period add calendar time to either path. Accelerators such as Kanerika’s FLIP compress complex migrations to roughly 2 to 8 weeks.
Will Excel and other MDX client tools still work after migration? Excel keeps working through Analyze in Excel connectivity to the Fabric semantic model, with pivots, measures, and hierarchies intact. What stops working is anything that sends raw MDX at the SSAS endpoint, because Fabric has no MDX surface. The correct move is a consumer inventory during assessment that classifies every workbook and report as DAX, MDX, or SQL, then rebuilds the MDX consumers first.
What is Direct Lake mode and why does it matter for SSAS migrations? Direct Lake is Fabric’s storage mode that reads Delta Parquet tables straight from OneLake into the engine’s memory, skipping a copy step. Its refresh is a metadata framing operation that takes seconds instead of the minutes or hours an SSAS Tabular processing cycle needs. That brand-small change is the core economic argument for migrating, since reports stay current the instant new data lands.
Is it better to move to Power BI first and Fabric later? It depends on the estate. Teams whose only need is modern BI reporting can migrate SSAS Tabular models straight into Power BI semantic models and do so quickly. Fabric adds OneLake storage, pipelines, the Lakehouse, and governance, so estates with growing data-ops needs benefit from landing there directly. Splitting the migration into two moves doubles validation, so keep the timeline honest either way.
