Open Data Infrastructure
How to Migrate from Databricks Delta to Open Iceberg
A practical Delta-to-Iceberg migration guide covering UniForm, Apache XTable, catalog choices, governance parity, and coexistence.
Moving from Delta to Iceberg is not just a file-format exercise. The table may live in files, but the migration lives in metadata, catalogs, governance, and workload behavior.
Start by deciding whether you need migration or interoperability
Some teams need a full migration. Some need a coexistence path where Iceberg engines can read Delta-managed tables while the organization reduces dependency over time. Those are different plans.
Databricks UniForm and Delta Lake UniForm are designed to expose Delta tables through additional metadata for formats such as Iceberg. Apache XTable takes a different open-source approach by translating metadata across table formats. Both patterns are useful, but neither removes the need to understand ownership, catalog behavior, write paths, and feature coverage.
Inventory table behavior before moving data
Make a table-by-table inventory before touching production workloads.
- Which tables use deletes, updates, change data capture, or streaming writes?
- Which workloads depend on Delta-specific behavior?
- Which identities, permissions, and lineage events need to survive?
- Which engines must read the table during the transition?
The migration risk is usually hiding in the answer to the second question.
Catalog choices decide the future operating model
Iceberg is a table format, not a complete operating model. You still need a catalog, access model, maintenance process, and governance path. If the new architecture keeps those contracts private, the table format changed but the control problem did not.
Use the migration to make table ownership explicit. Decide who writes, who reads, how schema changes happen, where lineage is captured, and how rollback works. That is the part future teams will thank you for.
Core idea: format conversion without governance parity is not modernization. It is a risky rewrite with better branding.
Cut over only after proving ordinary operations
Do not declare victory after the first successful read. Prove schema evolution, partition changes, deletes, compaction, retention, access review, and incident recovery. Migrations fail in the boring operations nobody puts in the demo.
If the Iceberg path cannot survive normal change, it is not ready to own the workload.
Sources to start with
These are the primary sources I would start from when checking the claims in this piece.