Every enterprise data leader we talk to is being asked to pick a side. The Microsoft account team wants a Fabric commitment. The Databricks team has a migration assessment ready to go. Snowflake has a business case for consolidating everything in one place. Each pitch ends the same way: choose us, retire the rest, and the complexity goes away.
The pitch is wrong, and most leaders quietly know it. It is worth being precise about why.
You already run more than one platform, and you always will
Look at any enterprise estate honestly and you will find at least two of the major platforms in production, plus a warehouse someone built in 2015 that still runs the finance close. This is not a failure of discipline. It is how estates actually form: an acquisition brings its own stack, a business unit buys what its team knows, a data science group needs something the standard platform does not do well, and a decade of reasonable local decisions accumulates.
Consolidation programs that fight this reality have a familiar shape. Year one produces a target architecture and a migration roadmap. Year two migrates the easy workloads and discovers the hard ones. Year three quietly rescopes, and the platform that was being retired is still there, now with less investment and more risk than before the program started.
The question is not which platform wins. The question is whether the platforms you run form one governed estate or three ungoverned ones.
Coexistence is an architecture, not a compromise
Running multiple platforms badly looks like duplication: the same data copied into each platform, the same metric defined three ways, access managed three different ways by three different teams, and nobody able to answer an auditor's question without a meeting.
Running multiple platforms well looks different. Each workload has a home, and there is a reason it lives there. The boundaries between platforms are deliberate: everyone knows which system owns which data, and what crosses the boundary is defined like a contract, with an owner, a schema, and a service level. Governance, cataloging, lineage, and access sit above the platforms, not inside each one separately.
None of that requires heroics. It requires someone to make the boundary decisions explicitly instead of letting them happen by default, and it requires those decisions to be written down where the next team can find them.
Why the vendors cannot tell you this
Platform vendors are not lying to you. Fabric, Databricks, and Snowflake are all genuinely excellent at a meaningful share of enterprise workloads, and each one is the right answer for something. But a vendor's advice stops where its product ends. No account team is funded to tell you that the workload you are discussing belongs on their competitor, and no partner-tier consultancy earning margin on one platform's licenses is neutral about where your workloads should live.
That is a structural problem with how enterprises buy data advice, and it has a structural answer: get the platform recommendation from someone who does not profit from the platform decision. Then hold them accountable for whether the architecture works, which is only possible if they also build.
What deciding well looks like
The estates that end up governed rather than sprawling tend to make three moves. First, they assess before they architect: inventory what actually runs, who runs it, and what standing still costs, so the decision is grounded in the estate they have rather than the diagram they wish they had. Second, they decide workload by workload, not estate by estate. Wholesale migrations fail; deliberate placements compound. Third, they design governance in from the first pipeline, because retrofitting lineage and access onto a finished platform is the most expensive way to buy them.
The platform war asks you to bet the estate on a vendor. The better war is smaller and winnable: every workload in the right place, every boundary deliberate, one set of answers when the board or the regulator asks.
That is the war worth fighting. If you are in the middle of it, write to us.