A team has 90 TB of Parquet in Hive-style date directories and wants Iceberg tables with no downtime for the 200 dashboards reading them. Which sequence is right?

The mechanism that makes this cheap

Iceberg's metadata is a pointer structure over immutable data files, and existing Parquet files are already valid Iceberg data files. Adopting the format means writing manifests that reference them. No bytes move. A 90 TB migration becomes a metadata operation measured in minutes per table rather than a rewrite measured in days of compute and read requests.

Two variants exist and the difference matters operationally. A snapshot-style migration creates an Iceberg table pointing at the same files while leaving the original table intact and writable, which gives a rollback window and a parallel-run period. An in-place migration replaces the table. Use the first for the cutover period, the second when the last writer has moved.

Why the other options fail

• Rewrite with a full table copy. Correct, and it pays a complete rewrite for a result you can get from metadata. It earns its cost only when you are also changing partitioning, sort order or file sizes — which is a legitimate reason, and if that is the plan, say so and do it deliberately on the tables that need it rather than on all of them.
• Dual-write for a month. This is a database-migration reflex applied where it does not fit. You cannot dual-write into a bare directory layout, because it has no commit protocol to make the two writes agree. It doubles the write path to buy a guarantee the atomic metadata swap already provides.
• Engine auto-conversion. No engine silently rewrites a table's format, and believing it does is how teams get halfway through a cutover before finding that their 2019 partitions have a column the 2024 partitions do not.

The hard part, which is not the conversion

Writers, not readers. Every job still appending files into the directory layout must move in the same change. A file written into the directory after the manifests are generated is present to the old path and invisible to the new one — no error, no warning, a table that is quietly missing yesterday.

So the real sequence is: inventory every writer per table, including the ad-hoc ones and the one shell script; generate metadata; move writers; then move readers; then remove the old path. The point of no return is removing the directory-based writer, because after that a rollback means replaying.

What it actually takes

Weeks, and almost none of it is the conversion. The time goes on the writer inventory and the schema inconsistencies you find while doing it: columns added mid-history, types that changed, partitions written with a different granularity during an incident three years ago. Iceberg requires a single schema per table and will refuse files that do not fit, which is a feature presenting itself as an obstacle.

When this is the wrong sequence

When the tables are small. Below roughly a terabyte the metadata-only path's advantage is minutes against hours, and a clean rewrite costs little while letting you fix partitioning, file sizes and the schema drift in the same pass. Choose the rewrite when the layout is wrong; choose the metadata swap when the layout is right and only the format is changing.

When the table is written by a system you do not control. A vendor job that appends directories on a schedule you cannot change makes the silent-divergence failure permanent rather than transitional, and the honest answer is to keep the directory layout as the landing zone and build the Iceberg table downstream of it — one extra copy, and a boundary that fails loudly instead of quietly.