Migrating to Apache Iceberg: Strategies for Every Source System

This article, the final part of a 15-part Apache Iceberg Masterclass, outlines three strategies for migrating existing data to Iceberg: in-place migration, full rewrite, and shadow migration. It explains that the recommended approach for production is the view swap pattern, which uses Dremio's semantic layer to create views that allow for a zero-downtime transition by first pointing consumers to legacy data, then swapping the view to the new Iceberg table after validation.

This is Part 15, the final article of a 15-part Apache Iceberg Masterclass. Part 14 covered hands-on Dremio Cloud. This article covers the three migration strategies and how to execute a zero-downtime migration using the view swap pattern. Most organizations do not start with Iceberg. They have years of data in Hive tables, data warehouses, CSV files, databases, and Parquet directories. Moving this data to Iceberg is not an all-or-nothing project. The best migrations happen incrementally, one dataset at a time, with no disruption to existing consumers. In-place migration creates Iceberg metadata over existing Parquet or ORC files without copying or moving them. The data files stay exactly where they are; only new Iceberg metadata is created to track them. Spark example: CALL system.migrate 'db.existing hive table' This converts a Hive table to Iceberg by scanning its files and creating the Iceberg metadata tree metadata.json, manifest list, manifest files that references them. The Parquet files are untouched. Pros: Fast. No data movement. The table becomes queryable as Iceberg immediately. Cons: The existing file layout sizes, partitioning, sort order is inherited. If the original files are poorly organized, you inherit those problems. Requires the original files to be in Parquet or ORC format. A full rewrite reads data from any source and writes it as a new Iceberg table with optimal partitioning and file sizes: -- Spark CREATE TABLE iceberg catalog.analytics.orders USING iceberg PARTITIONED BY day order date AS SELECT FROM hive catalog.legacy.orders -- Dremio CREATE TABLE analytics.orders PARTITION BY day order date AS SELECT FROM legacy source.public.orders Pros: Best result. Optimal file sizes, correct sort order, proper partitioning. The table is perfectly organized from day one. Cons: Requires reading and writing all data, which takes time and compute resources. The source system must be available during the migration. Shadow migration builds the Iceberg table alongside the existing source, then swaps consumers from old to new when ready: Pros: Zero downtime. Consumers never see a disruption. You can validate the migration before committing to it. Cons: Temporarily doubles storage costs. Requires maintaining two copies during the transition. The view swap pattern is the recommended approach for production migrations. It uses Dremio's semantic layer to create an abstraction between consumers and the underlying data: Create views in Dremio that point to the legacy data source: CREATE VIEW analytics.orders AS SELECT order id, customer id, order date, amount, status, region FROM postgres source.public.orders All consumers dashboards, reports, notebooks query through these views. They do not know or care where the data physically lives. Create and populate the Iceberg table: -- Create the Iceberg table CREATE TABLE iceberg data.analytics.orders order id BIGINT, customer id BIGINT, order date DATE, amount DECIMAL 10,2 , status VARCHAR, region VARCHAR PARTITION BY day order date -- Backfill from the legacy source INSERT INTO iceberg data.analytics.orders SELECT FROM postgres source.public.orders Compare the two datasets to confirm data integrity: SELECT SELECT COUNT FROM postgres source.public.orders AS legacy count, SELECT COUNT FROM iceberg data.analytics.orders AS iceberg count Beyond row counts, validate aggregates total amounts, distinct customer counts and spot-check individual records. A comprehensive validation script should compare: Only proceed to the swap after all validation checks pass. Update the view to point to the Iceberg table: CREATE OR REPLACE VIEW analytics.orders AS SELECT order id, customer id, order date, amount, status, region FROM iceberg data.analytics.orders Consumers notice nothing. The view name is the same. The query interface is the same. But now the data is served from Iceberg with all of its advantages: time travel, hidden partitioning, metadata-driven pruning, and automatic optimization. The view swap pattern enables incremental migration. You do not need to migrate everything at once: During the transition, Dremio's federation queries legacy and Iceberg tables together. A join between a PostgreSQL table and an Iceberg table works the same as a join between two Iceberg tables. The migration is invisible to consumers. After migrating each table: Migrating without testing query performance: Always benchmark critical queries against the new Iceberg table before switching production traffic. Iceberg's partition layout and file organization affect performance, and a migration can make some queries faster but others slower if the partition strategy is wrong. Skipping the validation phase: Data discrepancies between the old and new systems are more common than expected. Schema differences, timezone handling, null semantics, and data type precision can all cause subtle mismatches. Validate thoroughly. Migrating everything at once: Large "big bang" migrations carry high risk. If something goes wrong, rolling back is complex and time-consuming. Migrate one table at a time, validate each one, and build confidence incrementally. This completes the Apache Iceberg Masterclass. The series covered table formats, metadata, performance, partitioning, writes, catalogs, maintenance, tooling, and migration. For hands-on practice, start a Dremio Cloud trial and follow the workflow in Part 14.