The evolution of Azure Data Platforms, and the future with Databricks- and Fabric-centric architectures

Highlight

It is natural for platforms and cloud to evolve, the question is, are you and your platform ready for that?

Over the years, Azure Data Platforms evolved to the point where the line between Databricks/Fabric and Azure blurred. If you’ve been paying attention, Microsoft’s focus has been slowly moving away from Azure toward Fabric. What does that mean for your platform? Well, that’s the topic for today.

Intro

If you are in the Microsoft’s ecosystem, you’ve probably noticed a few but key events that the things are changing

2 years ago Microsoft Fabric was announced with a mission to to become “the” platform for Data & Analytics
1 year ago Microsoft removed all Azure Data role certifications
This year Cloud-scaled Analytics & Data Landing Zones was deprecated and the docs were pulled from the Microsoft Learn

So what does change for us? But before we go there let’s take a look at the third point. Because it is quite important.

March 2026 Announcement

I want to pause and go over the latest announcement which in my opinion is an important message to everyone who currently runs Azure-based data platforms

From official Microsoft docs

March 2026

New guidance Unify your data platform for AI and analytics: CAF has new guidance on how to unify your data platform with Microsoft Fabric. This guidance helps decision makers organize operating models around data domains, define clear data ownership and accountability, and establish standards for secure and governed data products. It also explains how high-quality data products support AI and analytics across the organization.

Deprecation notice

Cloud-scale analytics guidance is deprecated. We replaced this guidance with Unify your data platform for AI and analytics. The deprecation and deletion date was April 30, 2026.

Reference: March 2026 news

Make what you want from this.

Azure Data is very much alive

One thing should be said, and it’s extremely important in this context. Azure Data is alive and well, and will be used for many years to come. Services are not being deprecated. Only the patterns and official guidance. So if you are in Azure Today, no immediate action is needed. This post is talking about the future of data platforms, and a midset change tied to it.

That being said, no official guidance for your current platforms is a bit odd.

What if I’m still in Azure

If you are still running your data platform on Azure you are fine. It’s not like the platform is going away or Microsoft will drop the support. At least for foreseeable future. But that doesn’t mean you should do nothing. In fact, you should at least think what does this mean for you, and the future of your platform.

One thing that might be very helpful to do, is to download last commited version of the documentation for Azure Data Landing Zones and Cloud-scaled Analytics from Github. I’ve attached a link below for your convinience.

Reference: Microsoft Learn docs GitHub from April 29

This isn’t solving or changing anything, but at least you still got access to the docs that you might need on your platform. Even if you plan to move, you are here and now, and this might be very helpful thing to have.

What’s new?

March 2026 news propose a new pattern called Unified Data Platform and below is a high-level contrast of that compared to old data landing zones

Data Landing Zones	Unified Data Platform
Before - Core D&A in Azure - All reporting in Microsoft PowerBI - Data Landing Zones are a core design choice - Solutions grouped in Resource Groups	After - Core D&A in Fabric - Data Landing Zones are for legacy workloads - Azure is for networking, security, and governance - Solutions grouped in Workspaces

Reference: GitHub history Link	Reference: Docs Link

The mindset change

So what changes now? Anything, or everything, or something in between?

Let’s start with one of the first question that comes to mind.

But Adam, my Azure platform already runs 90% of workloads in Databricks/Fabric

And this is the same for me, and many companies I work with. But this change is about chaging how you think about platforms and their design.

Today we often will say

This is Azure Data Platform with Databricks/Fabric as the core data transformation component

But we need to shift this thinking into

Databricks/Fabric platform, with Azure for compute, storage, and networking components

New thinking

This whole thing is about a mindset change. A change in how we are going to think and build our platforms and what is the centerpiece of that platform. Whether this is Fabric or Databricks is your choice, but moving forward, if you are building a new platform, it should probably not be Azure. Don’t get me wrong, Azure isn’t a wrong choice, it’s still going to be here. But most likely the further we go, the more we will see Azure az a backbone, not the core of your data platform.

Once you decide that you are either Fabric or Databricks-centric, you will start thinking differently.

For example, if you choose Databricks as your center, maybe it’s worth asking a question “Do I even need to give people access to Azure?". Because maybe you don’t. Some data platform providers worked like that since forever.

Asking questions like

Will my user access my platform from Azure Portal, or only via Databricks/Fabric portals?
Do people need access to Azure resource groups?
Do I need separate resource groups per data product/data solution?
Do people need access to data lake, or should they only use unity/onelake as the access layer? What are the pros and cons?
Do I still need a key vault in Azure? If I do, where does it go?
Do people need access to Key Vault to manage secrets, or should they do it in Databricks via secret scopes? (missing UI, requires code)
How do non-data & analytics solutions source data from my Databricks platform?
What formats should I use? delta, iceberg, parquets? and for which cases?
Do I use managed tables or external tables?
What about infamous vendor lock-in?
How to allow different technologies to integrate with my platform? e.x. Snowflake

And obviously more. But asking these questions in the context of Databricks/Fabric being the core platform gives different answers than if we would ask them thinking that Azure is the platform.

I’m looking at Snowflake as a great example of that. If your platform is based on Snowflake at its core, even if you set up Entra and Azure integration, you never give people access to Azure itself. You can, but you technically don’t have to, and in most cases won’t want to. For Snowflake, Azure is a transparent layer. Once configured by the platform team, you never have to think about it. In my opinion, the same future will be with Databricks and Fabric. There might be gaps here and there, but the concept stays true.

Interoperability is important

There are a few things that we need to keep in mind. Even if the future is Databricks or Fabric, we are here Today, and we have platforms to run and evolve. In order to do that, while still maintaining the current operations we need to ensure we can evolve without disruptions. Interoperability isn’t ‘the answer’, but is a part of it that will make things easier and open. If you use native cross-platform open formats like parquet, delta, and iceberg, you are probably in a good place. This give you room to change, and pick the best service for the job.

In layman’s terms, by thinking about how all these tools, systems, and platforms can talk to each other and exchange data and information. Be it by using unified storage solution, common protocols, APIs, data formats, etc. The key is to have that in mind.

Because who knows, maybe the future of data platforms is to have platform that looks like this.

Shifting into Fabric- and Databricks-centric world

The shift has been happening for quite some time. It’s not a matter of asking if, but when. When we must start changing the approach. And if I were to be personally answer that, I’d say, for me that time is now.

Data Products Today

As of today, many data product solutions are built using the reference architecture below.

This architecture commonly includes:

Data Factory for data ingestion
Data Factory for orchestration
Databricks for transformation
Data Lake to store data
Key Vault to store secrets/credentials/keys

Data Product Reference closer look

If we look closer at a classic data product with Data Landing zones, and extra objects, most product would look like this

Or with Fabric:

The shift

But if we start thinking that Azure should be a transparent layer and will be a transparent layer, then there’s no purpose in showing its components on diagrams. Maybe there is no longer a need to do it.

So we show Databricks reference architectures as

with a closer look

So we show Fabric reference products as

with a closer look

This is all semantics

Yes, I know that most of this might be semantics to some of you. I don’t disagree, but my perception is that this is much more. This is about changing how we approach platform design.

Once we change the way we think, some answers will be different and might shape how you design your platform.