Ditching Legacy: Scaling Modern Medallion Architectures in Databricks vs. Fabric

We got an inside look at how two major engineering teams successfully navigated complex, high-stakes infrastructure overhauls. A huge thanks to the Xomnia team for hosting us! The speakers didn't hold back, giving us a transparent look at the exact technical choices, unexpected roadblocks, and architectural pivots that shaped their next-gen analytics platforms 🌟

Here’s a recap:

🎰 Modernizing Holland Casino with Databricks & dbt
Sebastiaan de Leeuw & Don de Lange walked us through how Holland Casino dismantled their rigid reporting systems to spin up a high-velocity Lakehouse. By migrating to a unified stack of Databricks and dbt, the team significantly slashed data complexity. They showcased live plumbing of their architecture; demonstrating how Lakeflow ingestion, dbt modeling, and Databricks Workflows tie together to form a highly agile Medallion framework that delivers speed and security faster than legacy methods allowed. The engineering team left the audience with several core lessons from this migration journey:

πŸ”Ή DBT leveraged auto-generated docs & data lineage, facilitated built-in testing for early tracking data issues and versioning of workflows.
πŸ”Ή Using the Medallion framework enabled one central highly data quality layer (gold) in Databricks that served as ground truth, which reduced latency and complexity on the side of reporting & analytics.
πŸ”Ή Unity catalog played a pivotal role for explainability, audits and compliance.


πŸ›οΈ Saving a Public-Sector CRM Migration with Fabric & PySpark
Next, Daniel Martin & Samridh Pandey shared how to navigate high-stakes architectural pivots within a massive public-sector organization. Trapped with a legacy SQL data warehouse and an incoming Dynamics 365 CRM integration, the team bypassed impossible deadlines by building an entirely new platform on Microsoft Fabric. Using PySpark as their core engine for ingestion and orchestration, they deployed a governed Medallion pipeline combining OneLake, Lakehouses, notebooks, and semantic models. Best of all, they shared the unvarnished constraints and the early choices that didn't work. To help other teams embarking on a similar pivot, the speakers highlighted a few essential realities of working with Fabric:

πŸ”Ή Roughly 90% managed solutions come out of the box, but a crucial 10% needs customized engineering solutions.
πŸ”Ή The DAX extractor was used to scan call models in the current Fabric workspace to create a centralized data dictionary in the Lakehouse to support governance, documentation and analytics management.

Next
Next

Real-World Challenges in Geospatial Machine Learning