SSAS & SSIS Alternative: A Modern, Open-Source Data Stack

Read the Signals Together

Nobody has sent you an end-of-support letter for SSAS or SSIS. Read what Microsoft has actually done, though, and the direction is not ambiguous.

SSRS already got the letter. Microsoft has confirmed in writing that no new versions of SQL Server Reporting Services will be released, and that on-premises reporting is consolidated under Power BI Report Server from SQL Server 2025. The reporting leg of the SQL Server BI stack is finished. That is the precedent, and it is documented.

SSAS is being maintained, not developed. It still ships and it is still supported — but the analytical investment has moved. Direct Lake, OneLake integration, Fabric Git source control, deployment pipelines: all of it is built for Power BI semantic models under Fabric, not for Analysis Services. Microsoft publishes a migration guide from Azure Analysis Services to Power BI Premium, with tooling to automate it. Features have been pruned along the way — Data Mining was deprecated and removed. In January 2026 the SCOM management packs for SSRS/PBIRS and SSAS were deprecated too. None of that is an obituary. All of it is the same direction.

SSIS is being wrapped, not extended. New feature work has slowed to a trickle since 2019, and Microsoft's recommended modernisation destination is Fabric Data Factory. The clearest tell is the Invoke SSIS Package activity: a Fabric pipeline that executes your existing .dtsx in place. Your packages are cargo to be carried, not a platform being built on.

So the honest summary is not "SSAS and SSIS are dead." It is that the entire SQL Server BI stack is being absorbed into Fabric, one component at a time, and one of the three has already completed the journey.

The Bigger Problem: Look Where That Road Goes

The destination matters more than the timing, because the Fabric answer changes the economics of your data platform permanently.

Neither was ever free — they came bundled with something costly. SSAS and SSIS arrive with SQL Server Enterprise, which is licensed per core at roughly $15,123 per two-core pack, about $7,100 a core. Microsoft also requires a minimum of eight cores per server, so the entry ticket for a single machine is north of $60,000 before you have loaded a row. Add a second node for high availability and you have done it again.

That was, at least, a purchase you owned and could run for a decade. The Fabric answer is not: capacity is rented by the month and Power BI is billed per person, so the meter now runs in step with how many colleagues look at your data. It is a different relationship with your own reporting, and it becomes very hard to reverse once the models live there.

And those terms move without you. Microsoft announced the retirement of the Power BI Premium P SKUs in March 2024: new purchases stopped that July, and existing customers were transitioned onto Fabric F SKUs by 1 January 2025. Power BI Pro went from $10 to $14 per user per month, Premium Per User from $20 to $22. If you had planned capacity around a P1, that plan was rewritten for you. Per-core licences you have bought do not reprice mid-decade; a subscription tier can, and did.

Cloud-first by design. If you have regulatory, latency, or sovereignty reasons to keep analytical data on your own infrastructure, the direction of travel is away from you. On-premises is where these products are, not where they are going.

Then there is the day-to-day, which is what people actually complain about:

SSIS development is stuck in Visual Studio. Which SSDT version works with which SQL Server target version is a rite of passage nobody enjoys. .dtsx is XML that does not merge, so two people editing one package is a manual reconciliation. Deployment means SSISDB and environment configurations, debugging means clicking through a designer, and there is no testing framework worth the name. Packages that work on one machine and not another is a genre of bug, not an incident.

MDX is a skill nobody is learning. SSAS Multidimensional is deep, mature, and genuinely good at what it does. It is also the older of the two SSAS models, its innovation has plainly slowed, and the people fluent in MDX learned it a long time ago. New analysts learn DAX, or SQL, or nothing. When your cube person leaves, you find out how much of the business logic lived in calculated members nobody documented.

Windows Server only, with processing windows. Cube processing has to fit in a nightly slot. Tabular models have to fit in memory, and memory is the thing you cannot buy incrementally. Neither product runs anywhere but Windows, which makes containers and cloud-agnostic deployment awkward.

What DataPallas Does Instead

DataPallas covers the same ground — semantic modelling, ingestion, transformation, and an OLAP engine — plus the whole BI layer on top of it that SSAS and SSIS were never meant to provide. It is open source and self-hosted, it runs on hardware you own, it reaches any database that speaks JDBC, and it is equally at home on Linux, Windows, or macOS.

No SQL Server Enterprise licence. No per-core fee. No capacity unit. DataPallas is open source with fair commercial pricing, and it is priced around the people who build and administer the models and reports — not around your cores, your servers, or your readers. Hardware is not a licensing metric here and readers are not a licensed tier.

The Semantic Model — What SSAS Was For

Cubes are DataPallas's semantic layer: dimensions, measures, joins, segments, and hierarchies declared once, then consumed identically by reports, dashboards, AI chat, and embedded components. Joins are declared once so nobody double-counts through a one-to-many. "Revenue" resolves to the same definition everywhere it appears.

Three differences from an SSAS model:

• It is a text file. The Cube DSL diffs, merges, and gets code-reviewed like any other source — no .bim in a Visual Studio project, no model that one person opens and deploys.
• AI writes the first draft. Hey AI, Help Me… reads your live schema and produces the cube definition, so a new subject area starts from something working.
• AI can then query it safely. A question asked through a cube resolves to a named, reviewed measure rather than the model guessing which column means revenue — see AI & Cubes. Self-service without MDX, and without a training course.

Ingestion — What SSIS Was For

CDC replication via the Altinity Sink Connector streams changes from your operational databases into ClickHouse in seconds. MySQL and PostgreSQL natively; SQL Server, Oracle, Db2, and MongoDB through Debezium.

Enable CDC on the source, put your connection details in docker-compose.yml, run docker compose up. There is no package to build, no Control Flow to lay out, no SSISDB to deploy to, and no nightly batch window — because it is not a batch. The equivalent SSIS work is hours or days of designer, deploy, and schedule.

Transformation — dbt, Not a Designer

dbt Core ships with the ClickHouse adapter for turning raw replicated tables into a real star schema — staging views, dimensions, facts, analytical views — in plain SQL. One command runs the transform.

Everything is version-controlled, testable, and readable by anyone who knows SQL. A .dtsx is XML too, technically — but it is XML a designer generated, stuffed with layout coordinates and GUIDs, which is why two people editing one package means a manual reconciliation rather than a merge. Deployment goes through SSISDB, and there is no native testing story at all.

The same holds for the reports and models you build here. You configure them on screen — data source, template, parameters, schedule — with AI writing the SQL or the template whenever you want it to, and staying quiet when you do not. What gets saved is plain text meant to be read by a person. So you keep the convenience of a UI and still get pull requests, diffs, branches, and a way back when a change was wrong. This is the single biggest quality-of-life difference in the whole comparison.

The Engine — Three Tiers, One Component

DuckDB handles roughly 100K to 100M rows embedded, with zero administration. ClickHouse takes it from there to billions, pre-configured in Docker Compose. The same <rb-pivot-table> component works identically across both — start on a laptop, scale to a cluster, change no code.

No dedicated SSAS instance, no memory-sizing exercise, no processing window.

And the Whole BI Platform Above It

This is the part SSAS and SSIS never claimed to do, and where you stop buying separate tools: report generation from HTML/CSS templates, automated bursting and distribution, a document portal where each recipient sees only their own files, interactive dashboards, embeddable data tables and charts, Chat2DB for plain-English querying, and the AI crew — Athena knows this OLAP stack specifically and will walk you through CDC setup, star schema design, and ClickHouse tuning.

The Honest Bit: You Rebuild, You Do Not Import

.dtsx packages do not run here, .bim models do not import, and MDX is not a query language DataPallas speaks. Those definitions have to be recreated, and none of that is trivial. Get the measure of it before committing to a date.

Two things make the scope smaller than it looks. Your cube's business logic — the measures, the hierarchies, the joins — is what you are actually porting, and AI drafts the DSL for it from your live schema. Your SSIS packages, honestly examined, are usually 80% "move these tables from A to B," which CDC replaces outright rather than reimplements; what remains is the genuine transformation logic, and that becomes dbt SQL.

Where SSIS is genuinely deeper: its 30-plus built-in transformation components — Slowly Changing Dimension, Fuzzy Lookup, Fuzzy Grouping, Merge Join — plus breakpoint debugging and mid-pipeline data viewers. If your pipelines lean on fuzzy matching or elaborate per-row error routing, that logic has to be rewritten in SQL rather than dragged from a toolbox. Scope those packages first; they are the ones that will tell you how big this really is.

Phase One: Run the New Warehouse Alongside the Old One

You never have to switch everything over at once, because the first phase simply runs alongside what you already have.

Point CDC replication at the same source databases your SSIS packages read from. Nothing changes upstream: SSIS keeps running its nightly load into your existing warehouse, while DataPallas streams the same tables into ClickHouse continuously. Build the dbt models, define one cube over the result, and compare the numbers against what SSAS reports for the same period.

That gives you the one thing no evaluation document can: your own data, in both stacks, side by side, with the differences visible. You cut over per-subject-area when the numbers agree, and you keep SSIS running until they do.

Phase two is retiring packages, one at a time, starting with the ones that are pure table movement.

Where to Start

1. Inventory honestly. How many SSIS packages are genuinely transforming data, and how many are moving tables? How many cubes are Multidimensional, and how much MDX would have to be rewritten?
2. Stand up DuckDB or ClickHouse and point CDC at one source database. Nothing upstream changes.
3. Build the dbt models for one subject area and define a cube over them.
4. Compare the numbers against SSAS for the same period, and keep comparing until you trust them.
5. Then price the Fabric path — capacity plus per-user, monthly, forever — against what you have just built.