The end of a Azure Data Platforms era, and the future with Databricks- and Fabric-centric architectures

Highlight

Recent announcements were a final call for many of us to change how we think about design of modern data platforms. The question is, are you ready, and what about your current real-estate?

In this post, I want to go over recent changes and what they mean for us architects and platform owners.

Intro

The whole thing is a little bit rough, but the signals were there for quite some time.

The main things that happened over the last 2 years were:

2 years ago Microsoft Fabric was announced with a mission to replace Azure as a platform for Data & Analytics
1 year ago Microsoft removed all Azure Data role certifications
This year, entire documentation regarding Cloud-scaled Analytics & Data Landing Zones was removed from the Microsoft Learn

So it should not come as a surprise that this is finally here. But what is surprising is how fast this happened, especially the recent documentation removal.

March 2026 Announcement

Let’s start by unpacking the latest announcement, which is obviously a final nail in the coffin.

Here is the screenshot of the announcement

Three things to notice here

March 2026 news cloud-scaled analytics was deprecated
New guidance is called Unified Data Platform with Microsoft Fabric being the center of attention
April 2026 the entire cloud-scaled analytics, including data landing zones were removed from the docs!

What is a bit shocking is how brutal that change was. Docs were not just marked as deprecated and recommended to follow the new approach, but completely removed.

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 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.

Recommended approach is different now

So what is new? Actually quite a lot

Cloud-scaled Analytics doesn’t exist anymore
Data Landing Zones doesn’t exist anymore
New approach is Unified Data Platform with Microsoft Fabric in the center

Here are side by side diagrams of the before and after approach

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 - All AI in Microsoft Foundry - 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

What if I’m still in Azure

If you are still running your data platform on Azure, like many of us, remember that Microsoft docs were always a publicly available and open sourced on GitHub. If you need to find some docs from the past, they are available on their github on the last commit before April 30th.

Ref: Microsoft Learn docs GitHub from April 29

This isn’t solving 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.

The mindset change

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

Addressing the Elephants in the room

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 (example)

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 as the core ETL component

But we need to shift this thinking into

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

The story might be the same with Fabric; it’s not a Databricks-specific problem. But Databricks is more well-established, so I used it as an example since it’s a more common question for many of us.

New thinking

It’s about a mindset change. Change how we are going to build our platforms and what is the centerpiece of that platform. Whether this is Fabric or Databricks is your choice, but moving forward, it should not be Azure. Azure will be a backbone, not the core.

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

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 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, Fabric, etc

And obviously more. But asking these questions in the context of Databricks 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. In Snowflake setup, 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, we are in the same place with Databricks and Fabric. There might be gaps here and there, but the concept stays true.

This story is the same for Microsoft Fabric data platforms.

Interoperability will be the key factor in design

The level of unknown, the level of uncertainty is probably the highest it’s been in IT since most of us started working. It’s hard to make a choice when everything changes at the speed of light. Every day brings new features, capabilities, methodologies, and patterns. How does one even decide?

Obviously we have to decide to follow something. The reality is that most data platform providers probably have more than 90% of what you need, this means that regardless of the choice you make, you will be able to create value. The 10% matters too, but not in the context of choice, but at a design level, to at least have a plan on what to do with it.

The way most clients tackle this is that they have something they call a leading platform and a supporting platform. The leading platform has 90% of data & analytics solutions and is the default choice for everything unless specific requirements are met. Supporting platform(s) help with corner cases. For example, today this could be Azure Data Platforms for 90% of our D&A cases, and Google BigQuery + Gemini for narrow and specific D&A and AI use cases.

Regardless of how you think about it, it’s important to leave some room for change, multiple platforms and solutions, and to support evolution of our data platform. This is often done, but not limited to, by interoperability. 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, and recently the answer was already given: now. We must start changing the approach.

While existing platforms will slowly transition into the new world, I would strongly advise against building any new platform with Azure-centric mindset.

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. I don’t disagree, but my perception is that this is much more. This is about changing how we approach platform design.

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

The time to change our thinking is already here, so I’m changing how I will design platforms. The question is, will you?

Happy building.