During a discussion last week about architecting a new analytics platform, a customer of mine posed an interesting question.
“If we wanted to make sure we own all the data and everything else, could we build everything on-prem?”
Six months earlier, that question wouldn’t have come up. Today it comes up in most feasibility conversations I have in Sweden. The CLOUD Act has moved from legal footnote to boardroom agenda item. US political unpredictability has made procurement teams nervous in ways that risk frameworks were not designed for. For organizations classified as NIS2 essential entities, the obligations around data sovereignty have become impossible to ignore. [1][2]
I realized I didn’t know the answer to his question, as I have been guilty of letting my on-prem skills atrophy just like everybody else. I reached out to a few people I trust in the community, and then I went on a hunt for answers online.
Here’s the thing: this is not panic born from the current state of the world. It is due diligence that should have happened earlier. The problem is that when we actually try to answer the question, we discover something uncomfortable.
We might not have the skills to execute.
A Decade of Forgetting #
The industry spent ten years actively messaging away on-prem knowledge. The cloud was cheaper, faster to deploy, and someone else’s operational problem. That was often the right call. If Microsoft or AWS could worry about patching, hardware failures, and capacity planning, why carry that burden yourself?
The side effect is that we de-skilled an entire generation of practitioners. The people who know how to configure TempDB correctly, read (and act on!) wait statistics, tune storage I/O, or debug SQL Server connection pooling are senior enough now to be in architecture roles or management. The people doing hands-on implementation today may never have racked a server.
That is not a criticism. It is the reality your clients will hit about six weeks into an on-prem project, when something breaks and nobody on the team knows where to look.
What On-Prem Teaches You That Cloud Hides #
Here is the counterintuitive argument: learning on-prem in 2026 makes you a better cloud architect.
Cloud services are magnificent abstractions. But abstractions hide failure modes, and hidden failure modes are the ones that hurt you at 2 am.
On-prem forces you to reason about systems concretely. Failure modes are legible. Disk fills up. RAM is exhausted. The NIC is saturated. Cloud hides these behind managed services until something breaks, and you are reading documentation you should have read six months earlier.
Capacity planning becomes real. “Is this query cost reasonable?” is a much more concrete question when you can see what it costs in actual hardware terms.
Blast radius thinking becomes instinctive. What else breaks when (not if!) this breaks? Managed services let you ignore dependencies until an incident forces the question. On-prem makes dependency mapping a day-one activity.
And there is troubleshooting ownership. There is no support ticket to open. The stack is yours. That is uncomfortable, but it builds a kind of reasoning that transfers into every other part of your work.
Think about that the next time a cloud service goes down and your entire team is waiting for a status page to update.
The Microsoft Stack in 2026: What Is Actually There #
Let us be specific, because this is where conversations tend to go wrong.
SQL Server 2025 shipped in November 2025. [3] SSRS is dead as a new version. Power BI Report Server (PBIRS) is now the default on-premises reporting solution, bundled with both Enterprise and Standard editions, with no Software Assurance requirement. [4] That is a real licensing improvement. Standard shops were locked out before.
One gotcha: there is no in-place upgrade path from SSRS to PBIRS. You have to migrate the reporting catalog. [5] That is a project, not a checkbox, and it belongs in your scoping conversation.
SSAS 2025 is in better shape than many realize. Improved DirectQuery parallelism and updated Horizontal Fusion optimization bring it closer to cloud SSAS feature parity than it has been in years. [6] Tabular is the path forward. Multidimensional still works, but has no meaningful roadmap.
SSIS is stable and mature. It is not evolving, and BIML’s open-source tooling has stalled. Neither disqualifies it; the tooling was already functionally complete. Modern connectivity lives in the third-party layer: ZappySys PowerPack, CData, KingswaySoft, and COZYROC all cover REST/OAuth2, JSON, and XML APIs, and cloud storage sources, and all support SQL Server 2025. [7] This is a licensed cost line, not free, but it is maintained, and it works.
What is missing: no Lakehouse equivalent, no serverless compute, no elastic scale, no real-time ingestion story worth mentioning. Clients who expect a Fabric-equivalent experience on-prem need to hear that before the architecture decision is signed off, not after.
Buy vs. Build: The Question Behind the Question #
Here is where the conversation gets interesting. The real choice is not cloud versus on-prem.
It is buy a complete platform versus assemble one yourself.
Microsoft Fabric is the clearest buy option. Click a capacity into existence, and you have a complete analytics platform: Lakehouse, Warehouse, Pipelines, Semantic models, Power BI, all integrated, all governed, one license. The value is not just the feature list. It is that the integration is already done. You do not have to think about how the storage layer talks to the compute layer, how lineage is tracked, or how the semantic model connects to the lakehouse. Someone else solved that, and you are paying for the result.
The trade-off is equally clear. US-controlled infrastructure, consumption-based billing, and full exposure to Microsoft’s pricing decisions. The CLOUD Act applies. If that matters to your client, and for some it genuinely does, you need a different answer.
The build option is real. Apache Airflow for orchestration, Spark on Kubernetes for compute, MinIO or any S3-compatible object store for storage, Delta Lake for the table format, dbt for transformation. Add DuckDB or Trino for query, and you have a production-capable analytics stack that runs on your hardware, in your datacenter, under your jurisdiction.
But let us be direct about what that path actually costs.
The integration work is entirely yours. Every component talks to every other on your terms, which means someone has to build and maintain those connections. Kubernetes expertise is a prerequisite, not a nice-to-have. Monitoring, alerting, backup, and disaster recovery are your problems. There is no SLA and no support number. The talent pool for this stack in Sweden is smaller and more expensive than the Microsoft ecosystem.
This is not a technology decision. It is an operational ownership decision.
Fabric is low-ownership, high-lock-in. The OSS stack is high-ownership, low-lock-in. Neither is wrong. The question is what your organization can actually sustain, and that conversation is harder than “which platform has better features.”
There is a middle path worth naming: running cloud-agnostic tooling in Azure Sweden Central with data residency guarantees and private endpoints. It is not a full answer to CLOUD Act exposure, but it is where many clients land in practice. Sometimes, good-enough sovereignty is the pragmatic call. Note: make sure to read the fine print on private endpoints in Microsoft Fabric before you go down this route.
The Skills You Actually Need #
The gap is real, and it has two layers.
Technical: O/S administration, database configuration fundamentals, storage I/O, and networking without assuming a managed gateway exists. Add container basics if the build route is on the table.
Organizational: most shops will need either a specialist brought in for the initial architecture or a senior hire who never fully left the on-prem world. Budget for one or the other. The worst outcome is discovering the gap three months into a project.
The whiplash is not going away. The political landscape will not stabilize enough to make this a one-quarter question. The clients who navigate it well will not be the ones who panic into on-prem or refuse to revisit their cloud assumptions. They will be the ones with someone on the team who can reason clearly across the full spectrum of options and execute whatever they decide.
Those are the skills we forgot we would need.
Join the Conversation #
What’s your experience with this? I’d genuinely like to hear how people in data and AI roles are thinking about training data provenance - reach out on LinkedIn or BlueSky.
References #
[1] European Parliament. Directive on measures for a high common level of cybersecurity across the Union (NIS2). 2022. https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32022L2555
[2] US Congress. Clarifying Lawful Overseas Use of Data (CLOUD) Act. 2018. https://www.congress.gov/bill/115th-congress/senate-bill/2383
[3] Microsoft SQL Server Blog. Enhancing reporting and analytics with SQL Server 2025 tools and services. June 2025. https://www.microsoft.com/en-us/sql-server/blog/2025/06/19/enhancing-reporting-and-analytics-with-sql-server-2025-tools-and-services/
[4] Microsoft Learn. Reporting Services Consolidation FAQ. 2025. https://learn.microsoft.com/en-us/sql/reporting-services/reporting-services-consolidation-faq
[5] red9.com. SQL Server 2025 Has No SSRS. Here’s What That Means for You. March 2026. https://red9.com/blog/sql-server-2025-ssrs/
[6] Microsoft Power BI Blog. What’s New in SQL Server 2025 Analysis Services. June 2025. https://powerbi.microsoft.com/en-us/blog/whats-new-in-sql-server-2025-analysis-services/
[7] ZappySys Community. Deploying SSIS packages to SQL Server 2025 with ZappySys connectors. January 2026. https://community.zappysys.com/t/deploying-ssis-packages-to-sql-server-2025-with-zappysys-connectors/725