How to migrate Hive tables to Apache Iceberg in 2026: three methods, with commands

Hive tables are folders of files plus an entry in a metastore. They work, but they have no transactions, changing the partitioning means rewriting everything, and listing millions of files slows every query. Apache Iceberg fixes this with a proper table layer: atomic commits, schema and partition changes without rewrites, time travel and fast planning. In 2026 it is also the format that Snowflake, Databricks, BigQuery, AWS, DuckDB and Polars all read and write. On 4 November AWS turned migration into a managed feature of Amazon S3 Tables. This guide covers that option and the two classic ones.

Method 1: in place, with Spark procedures

Iceberg ships Spark procedures that turn an existing Hive table into an Iceberg table without copying data. They read the file list, write Iceberg metadata and manifests, and register the new table. The data files must be Parquet, ORC or Avro.

-- Step 1: try it safely. Creates db.sales_iceberg pointing at the same files.
-- The original Hive table is untouched.
CALL spark_catalog.system.snapshot('db.sales', 'db.sales_iceberg');

-- Test queries, row counts and downstream jobs against db.sales_iceberg...

-- Step 2: convert for real. Replaces db.sales with an Iceberg table
-- (the old Hive table is kept as a backup with a _BACKUP_ suffix).
CALL spark_catalog.system.migrate('db.sales');

-- Alternative: add existing files to an Iceberg table you created yourself
CALL spark_catalog.system.add_files(
  table => 'db.sales_new',
  source_table => 'db.sales'
);

Method 2: full rewrite with CREATE TABLE AS SELECT

If the Hive table has problems you want to fix anyway, such as thousands of tiny files, the wrong partitions or old compression, write a fresh Iceberg table instead:

CREATE TABLE lake.db.sales
USING iceberg
PARTITIONED BY (days(order_ts))      -- hidden partitioning: no extra date column needed
TBLPROPERTIES ('write.parquet.compression-codec' = 'zstd')
AS SELECT * FROM spark_catalog.db.sales;

This reads and writes every byte, so it takes longer and doubles storage until you delete the old table. In exchange you get well-sized files, modern compression and hidden partitioning: queries filter on order_ts and Iceberg prunes partitions automatically, so users no longer need to know about a separate partition column.

Method 3: managed migration in Amazon S3 Tables

New on 4 November 2026. If your Hive tables are registered in AWS Glue and stored as Parquet, S3 Tables can run the whole migration:

• Cost: you pay only for the data the job copies; the Hive-to-Iceberg conversion itself is free. Source files in S3 Intelligent-Tiering keep their access tier.
• Better files: Snappy-compressed tables are recompressed to Zstandard and compacted, which reduces storage and the number of objects.
• Limits at launch: Glue-registered Hive tables in Parquet, in the same AWS account and region, in 10 regions including Ireland, Frankfurt and Stockholm in Europe.
• For AI agents: AWS also published a migration skill so an agent can run the workflow, with your approval.

Which method should you use?

The cut-over checklist

Related: Apache Iceberg v3, DuckDB vs Polars vs Spark and how to choose a database.

Sources: AWS, "Amazon S3 Tables now provide a simple, cost-effective path for data lake modernization" (4 November 2026); Apache Iceberg documentation for Spark procedures (snapshot, migrate, add_files) and table properties; Google Cloud blog (4 November 2026) for the talabat figure. Test procedures on a copy before running them on production tables.

Alessandro Ecclesie AgazziWritten by Alessandro Ecclesie Agazzi, analytics engineer in London. Updated 9 November 2026. About me