Almost every platform conversation I have with a CTO or head of data arrives, sooner or later, at the same question: if we build on Microsoft Fabric, how hard would it be to leave?
It is the right question to ask, because a decade of proprietary warehouse formats taught buyers to be cautious. Once your data sat inside someone else's engine, in a format only that engine could read, the cost of leaving quietly became the vendor's pricing power, and plenty of teams are still paying for decisions they made on that basis back in 2015.
So when we recommend Microsoft Fabric to clients, we expect the lock-in challenge and we welcome it, because the honest answer is more interesting than a straight yes or no. The format problem that used to define lock-in has largely been solved, and Fabric is one of the clearer examples of how. What remains of lock-in now lives somewhere else entirely, and knowing where it lives is what makes a platform decision safe.
It Starts With Open Formats
The foundation of Fabric is OneLake, a single logical data lake for the whole tenant, and everything Fabric's engines produce lands there in a single format: Delta Lake tables on Parquet files. Neither of those is a Microsoft invention. Delta is an open source table format sitting on an open source file format, held in storage you can address directly.
This matters for two reasons. The first is internal: because every Fabric engine works on the same copy of the data, Spark can write a table that the T-SQL warehouse queries and Power BI reads through Direct Lake, with none of them needing a copy of their own. Microsoft documents this Delta interoperability across engines as a design guarantee rather than a feature you switch on.
The second reason is the one that answers the exit question. Because your tables are Delta on Parquet, any tool that can read Delta can read them, and by now that covers most of the serious data ecosystem. If you decided tomorrow to move your estate elsewhere, the work would be copying files and re-pointing compute rather than a long programme of exporting and transforming, because your data was never translated into anything proprietary in the first place.
Shortcuts: Use Data Where It Already Lives
Interoperability is not only about being able to leave. Most organisations we work with are not on one platform and never will be: there is data in an Azure lake, something in S3 because an acquisition brought AWS with it, and a supplier feed landing in Google Cloud Storage. The traditional answer was to build pipelines that copied everything into the warehouse and then keep those copies in sync forever.
OneLake shortcuts take a different approach. A shortcut is a live pointer to data that stays where it is, which Fabric then treats as if it were local. Shortcuts to ADLS Gen2, Amazon S3 and Google Cloud Storage and S3-compatible stores are generally available, with optional caching to keep cross-cloud egress bills in check, and because nothing is copied there are no sync schedules to maintain and no second version of the truth to reconcile.
The door swings both ways, too. OneLake exposes the same APIs as ADLS Gen2, so tools outside Fabric can read and write OneLake data directly, a pattern Microsoft's own guidance on integrating Fabric with external systems describes at length. Fabric ends up as a participant in your data estate rather than a walled garden at the centre of it.
The Snowflake Bridge, Built On Iceberg
The sharpest test of any vendor's openness claim is how it behaves towards a direct competitor, and Snowflake is the obvious case. The answer is now concrete: OneLake and Snowflake interoperability is generally available.
Snowflake can store its managed Apache Iceberg tables directly in OneLake, Fabric can surface its own tables as Iceberg so that Snowflake reads them natively, and a shortcut to an Iceberg table written anywhere is virtualised as a Delta table for every Fabric engine, with no conversion job in sight.
It is worth pausing on what that means in practice: one copy of the data, held in open formats and queried by two competing vendors' engines, each unaware it is sharing. Five years ago that would have been a fantasy slide in an analyst deck, and today it is a supported configuration.
Databricks: Same Files, Different Engine
Databricks is an easier story again, because Delta Lake is Databricks' native format. Its clusters can read and write OneLake directly through the ADLS Gen2 APIs, and Microsoft and Databricks have gone further with catalog federation between Unity Catalog and OneLake, so that tables governed in one platform are discoverable and usable in the other.
For teams running both, this removes the worst kind of architectural argument, because nobody has to pick a winner and migrate the loser. Data engineering can carry on in Databricks while the business reports through Fabric and Power BI, all over one copy of the data, with each side keeping its own governance.
Mirroring: Even The Replicas Are Open
Analytics platforms have always needed operational data, and getting it there has traditionally meant pipelines that someone has to build and then babysit. Fabric's answer is mirroring, which gives you near real-time replication of SQL Server, Azure SQL, Cosmos DB, PostgreSQL, Snowflake and others into OneLake, managed by the platform itself.
The detail that matters for this discussion is where mirrored data lands: as Delta tables in OneLake, in the same open format as everything else, which means even your replicas are portable. For sources without a native connector, Open Mirroring publishes the specification so that any application can write changes into a mirrored database itself, and Microsoft's own documentation on unifying data with shortcuts and mirroring is candid that the goal is one copy of the data, used everywhere.
Where Lock-In Actually Lives Now
I would be selling you something if I stopped there, because although the format problem is solved, data gravity is not. The honest list of what still ties you to any platform, Fabric included, looks like this:
- Semantics and logic. Your Delta tables are portable, and notebooks written in Python or Spark SQL will move with only modest rework, but the semantic models, low-code pipelines and reports built around them are real work to rebuild anywhere else.
- Governance. Permissions, lineage, sensitivity labels and policies are platform constructs, and they do not travel with the Parquet files.
- Skills and habits. A team fluent in one platform's tooling has a switching cost measured in months, whatever the storage format says.
- Integrations. Every downstream system wired to a platform endpoint is a thread that needs re-pointing.
None of that is unique to Fabric, and none of it is fixed by choosing a different vendor; it is managed through architecture. Keep transformation logic in portable layers like Spark and SQL rather than proprietary designers where you can, standardise on open table formats end to end, and test the exit path once by reading a Fabric table from an external engine early in the project, so that portability is a verified property rather than a comfort blanket.
Choosing A Platform Without Marrying It
The lock-in question deserves a better answer than vendor reassurance, and with Fabric the evidence is checkable: open formats on disk, documented APIs in and out, live bridges to Snowflake and Databricks, and replication that lands in formats you could walk away with. That leaves you free to commit to the platform because it earns its keep, in the knowledge that your data was never the collateral.
Synapx is one of only 30 partners worldwide in Microsoft's Fabric Featured programme, and we spend our days designing estates where Fabric works alongside what clients already run rather than instead of it. If you are weighing a platform decision and want an honest view of where the boundaries really are, talk to us, or see how similar organisations approached it in our case studies.