AWS Adds Managed Hive-to-Iceberg Migration to S3 Tables: Launch Scope Is Glue-Registered Parquet Tables in the Same Account and Region and Ten Regions, and the Destination Is Read-Only Until You Complete the Migration

On November 4, 2026, AWS announced managed migration of Apache Hive tables to Apache Iceberg in Amazon S3 Tables. The What's New post and the AWS News Blog launch post describe it as an API-driven operation in which S3 Tables validate the source, convert data types, copy the data, recompress it and compact small files, while production workloads keep running. AWS says moving from Hive to Iceberg used to take weeks of engineering because each table needed its own migration pipeline. That duration is AWS's statement and the posts give no measurement for it.

The launch scope is narrow, and it should be read before anything else. At launch the capability supports AWS Glue-registered Hive tables stored in Parquet, in the same AWS account and the same Region. It is available in ten Regions: US East (N. Virginia, Ohio), US West (Oregon), Asia Pacific (Mumbai, Singapore, Sydney, Tokyo) and Europe (Frankfurt, Ireland, Stockholm). Hive tables in other formats, in another account, or in a Region outside that list are outside the stated scope. The posts do not say when that will change.

The workflow has three steps: start, sync and complete. When a migration starts, S3 Tables identify every source object in scope and write compatibility reports before any data is copied. By default the job continues automatically after planning; setting a review flag pauses it so the reports can be read first. The destination is a new Iceberg table in a table bucket, created with recommended defaults, and it is read-only during the migration. You can call sync as often as you like, and each sync copies only what changed. When you complete the migration, the destination table is promoted to read-write. Athena and Amazon SageMaker Unified Studio integrate directly in the console, and any engine that speaks the Iceberg REST API can query the result.

The sources differ on how much the source table is disturbed. The developer guide says the source table stays unchanged and fully available for reads and writes during a migration job. The launch blog says you can sync as many times as you need without stopping writes to the source, except for a few minutes during cutover. These statements are not contradictory, but they are not identical either: the docs speak about the job, and the blog speaks about the final switch. Teams that cannot accept even a short write pause at cutover should plan that step and not assume zero downtime. The posts also say you can roll back to your source data, which fits the docs' statement that the source stays intact.

Type and schema handling is explicit. Migration maps the Hive schema and partitioning to an Iceberg schema and partition spec, and you can either give a destination schema or let migration generate a compatible one from the Glue schema. A migration policy controls what happens on a mismatch, and the blog's example sets both the unmatched-field policy and the incompatible-value policy to fail. That is an example value in a sample request, not a stated default. The sample request also shows tunable maintenance settings: compaction with a 512 MB target file size and snapshot management that keeps at least three snapshots and expires them after 168 hours. After copying, an object migration report gives a result for each source object.

Cost is described qualitatively. You pay only for the data the job copies, with no charge for the Hive-to-Iceberg conversion itself, and source objects in S3 Intelligent-Tiering stay in their current access tier and keep their days-since-last-access clock. No charge for conversion does not mean the migration is free: copied data is billed at S3 rates, and the posts point to the S3 pricing page without giving a per-gigabyte figure. If your tables use Snappy compression, S3 Tables recompress them to Zstandard and compact them, which AWS says reduces storage and object count and improves query performance. AWS gives no before-and-after numbers.

Agents are part of the pitch. A migration skill in the Agent Toolkit for AWS lets a coding agent such as Kiro analyze existing IAM policies and recommend equivalent destination policies, validate the plan, run the start, sync and complete calls, and monitor progress, with safety guardrails. The skill is guidance for an agent that calls the same APIs, not a different migration engine.

Our reading: the feature removes a pipeline-building step, and the stated limits decide whether it applies to you. Check four things before relying on it: the table is registered in Glue, the data is Parquet, the source and destination share an account and Region, and the Region is on the list. Then plan the cutover window, read the compatibility reports before copying if the schema has unusual types, and estimate copy cost from your data volume. The destination being read-only during migration also means the new table cannot serve writes until you complete it.