The migration of Apache Zeppelin notebooks to Databricks has become a pressing concern for organisations that built their analytics on Cloudera, because Cloudera is scheduled to fully decommission Zeppelin in 2027. Deutsche Börse Group, operator of the Frankfurt Stock Exchange and a major European market-infrastructure provider, faced exactly this challenge and responded by building a generative AI tool to automate much of the work.
According to the company, its internal Statistics Platform supplies roughly 95% of all clearing and trading data across the group and powers self-service analysis for hundreds of business users. For years that platform relied on Zeppelin notebooks running on Cloudera, with access to HDFS and Oracle data systems. Two forces converged to force a change: the 2027 Zeppelin shutdown, and a strategic decision to move analytics workloads to the cloud with Databricks selected as the unified analytics platform.
Why the Zeppelin to Databricks migration is hard
The difficulty is rarely the infrastructure itself. The harder problem is the volume and entanglement of existing work. Deutsche Börse reported more than 2,000 users and a large body of notebooks, many embedded in daily business workflows. Rewriting that material by hand would take years and tie up scarce engineering time.
Manual migration also introduces risk. Each notebook re-created by hand is an opportunity to introduce subtle errors in logic that may not surface until a business report produces the wrong number. The scale of the task made a repeatable, semi-automated approach attractive.
A two-step converter: structure first, then logic
The team built a tool it calls the Zeppelin to Databricks Notebook Converter, delivered as a Databricks App. It separates the problem into a deterministic structural step and an AI-assisted reasoning step.
Structural conversion
The first step handles the mechanical transformation. Zeppelin paragraphs are mapped to Databricks cells, interpreter directives such as %python, %sql and %pyspark are translated to their Databricks equivalents, and the notebook metadata is reformatted into valid .ipynb JSON. At this stage the original content is preserved exactly; the logic is not rewritten, only prepared for the next step.
AI-assisted logic reconstruction
The second step uses Databricks Genie, the platform’s natural-language assistant. For each uploaded notebook, the app generates a context-aware prompt that encodes details of the original Zeppelin environment, including custom interpreters, data sources and configuration patterns. That context helps Genie reconstruct the logic in a Databricks-native form rather than producing a generic translation.
The design deliberately limits where AI is applied. Predictable, rule-based transformations are handled deterministically, and the model is reserved for the parts that genuinely require reasoning. This keeps the rule-based components robust while still benefiting from generative assistance where it performs best.
Reported results
According to Deutsche Börse, combining structural transformation with AI-assisted reconstruction reduced notebook redevelopment from hours of manual effort to roughly 15 to 20 minutes per notebook, depending on complexity. Because business users no longer need deep Databricks expertise, the migration does not depend on a dedicated engineering team; users follow a short sequence of steps and let the tool rebuild the notebook.
Lessons the team highlighted
Several principles emerged from the project. The first was to avoid over-engineering: an early, more elaborate attempt was simplified once the team understood which parts of the problem actually needed AI. The second was that investing in a detailed prompt — one capturing the specifics of the Zeppelin environment, such as interpreters, data sources and configuration patterns — was what made the generated output genuinely usable. The third was to involve the platform team early, which reduced rework during the build.
Limitations and what to watch
The published account describes a tool whose initial development is complete but which is still entering large-scale, real-world testing rather than a full production rollout. The reported 15-to-20-minute figure and the productivity claims come from the organisation itself and have not been independently audited, so they are best read as a combined vendor-and-customer account rather than a neutral benchmark.
Generative reconstruction also carries an inherent caveat: AI-assisted output still requires human review. A notebook that runs without error is not necessarily one that produces the same results as the original, and validation against known outputs remains essential, particularly for regulated financial data. Organisations weighing a similar approach should budget for verification, define clear acceptance tests, and treat the AI step as an accelerator rather than a guarantee of correctness. The economics also depend on how repetitive the notebook estate is; highly bespoke notebooks may see smaller gains than standardised ones.
The broader takeaway is that AI-assisted migration is available today rather than a future capability, but its value rests on disciplined scoping — using deterministic tooling for predictable work and reserving the model for genuine reasoning. For teams undertaking this kind of move, the quality of the underlying data and metadata matters as much as the tooling, a theme explored further in Data quality is AI strategy.
Further detail appears in the original write-up on the Databricks engineering blog, and Cloudera documents the Zeppelin deprecation timeline in its deprecation notices.
