databricks

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

May was a busy Databricks month, and the interesting part was not just the headline platform launches. The real story was the spread across governance, Lakeflow, apps, AI, and operational polish.

Are your tired of parametrizing dozens of pipelines via templates, maybe you want a more metadata driven approach, or simply you are hitting ADF temmplate parameter limits. If yes, this blog entry is for you.

This is the final wrap-up in our Unity Catalog migration series. These are the practical tips we landed on after the migration, the ones that would have saved us time if we had known them before we started.

The most important migration decision was not technical. It was about teams and roles. In Unity Catalog, the wrong role model makes the whole platform hard to operate.

In our platform, one of the first questions we answered was: what is a project in Unity Catalog? That decision shaped every later governance and onboarding choice.

One of the biggest surprises in our Unity Catalog migration was how much of the design depended on product limits. If you do not know which limits are soft and which are fixed, you can build a design that stops before it starts.

The most surprising part of our Databricks migration was this: without previews, we would not have finished. The features we used were not in plain sight, but they were the only path through several blockers.

This was the one part of the migration where the word “catalog” almost hid the real work. We were not just moving metadata; we were rebuilding a platform with Azure Landing Zone thinking and Unity Catalog governance baked in.

In this SQLDay 2025 session, we explore the realities of migrating enterprise Databricks environments to Unity Catalog.