Migrate Your Entire Iceberg Catalog to MinIO AIStor® In One Command Without Moving a Single File

‍Key Takeaways

1. AIStor's built-in Iceberg catalog eliminates the need for a separate catalog service, reducing both infrastructure and operational overhead.
2. mc table migrate moves catalog metadata only, not data files, so your query engines keep working through the transition.
3. Migration is idempotent by default. Use --dry-run to preview every table that would be registered before anything changes.

If you are already running Apache Iceberg tables in production, you have almost certainly set up a catalog to manage them. That catalog, whether it is Project Nessie, Apache Polaris, Hive Metastore, or AWS Glue tracks table locations, schema evolution, snapshot history, and partition specs. It is essential, but when it’s external to your storage it is also additional infrastructure to run, monitor, and maintain.

MinIO AIStor is the first on-prem, natively S3-compatible data store with an Iceberg REST catalog built directly into it. When the catalog lives in the same system as the data, you eliminate the network hop between catalog lookup and data access and reduce the number of services to operate. 

The question for most teams has been: how do you actually get there without re-registering hundreds of tables by hand? AIStor answers that with mc table migrate, a feature that automates the migration process end to end.

What the Command Does

mc table migrate reads catalog metadata from your existing catalog and registers those tables in AIStor. Critically, it does not move your Parquet files. If your table data is already in AIStor buckets, which is the common case because MinIO is frequently used as the object store even when a separate catalog manages the table definitions, the migration touches only metadata. Your existing query engines keep working through the transition. Trino, Spark, Flink, and others can continue reading the same underlying files; you are just pointing them at a new catalog endpoint when you are ready to cut over.

If your data currently lives in a different object store entirely, for example Amazon S3, you would first mirror the data into AIStor using mc mirror or batch replication, and then run mc table migrate to register the table metadata against the new data paths. The two steps are intentionally separate so you can validate each independently.

Supported Source Catalogs

The command currently supports five source types:

• nessie — Project Nessie, via its Iceberg REST interface
• rest — any generic Iceberg REST catalog, including Apache Polaris
• hive — Hive Metastore, via the Thrift protocol
• glue — AWS Glue Data Catalog, with region and credential properties
• sql — SQL-backed catalogs

Nessie has the most test coverage and the most documented examples, but the REST source type gives you a broad net for any catalog that speaks the Iceberg REST spec.

The Migration Workflow

Start with a Dry Run

Before migrating anything, use --dry-run to see exactly what would be registered. Combined with --output-dir, this writes a file listing every table and namespace that would be touched:

mc table migrate \

  --source-type nessie \

  --source-uri http://nessie:19120/iceberg \

  --source-warehouse warehouse \

  --dry-run \

  --output-dir /tmp/migration-preview \

  myminio my-warehouse

Review the output before committing. This is especially useful for large warehouses where you want to validate namespace and table discovery before anything changes in AIStor.

Migrate All Namespaces

Once you are satisfied with the preview, drop --dry-run to run the full migration:

mc table migrate \

  --source-type nessie \

  --source-uri http://nessie:19120/iceberg \

  --source-warehouse warehouse \

  myminio my-warehouse

This registers every table and view discovered in the source catalog. Iceberg views are included by default; use --exclude-views if you only want tables.

Migrate Selectively

For large catalogs you may want to migrate incrementally, one namespace or team at a time. The --namespaces flag accepts a comma-separated list:

mc table migrate \

  --source-type nessie \

  --source-uri http://nessie:19120/iceberg \

  --source-warehouse warehouse \

  --namespaces analytics,sales \

  --ignore-existing \

  myminio my-warehouse

--ignore-existing makes the run safe to re-execute. Tables already registered in AIStor are skipped rather than causing errors, which means you can run the command multiple times as you migrate namespace by namespace.

You can also target specific tables by exact identifier or by regex pattern:

# Migrate only the customers and orders tables

mc table migrate \

  --source-type nessie \

  --source-uri http://nessie:19120/iceberg \

  --source-warehouse warehouse \

  --identifiers analytics.customers,analytics.orders \

  myminio my-warehouse

‍

# Migrate all tables in the analytics namespace using a regex

mc table migrate \

  --source-type nessie \

  --source-uri http://nessie:19120/iceberg \

  --source-warehouse warehouse \

  --identifiers-regex "analytics\..*" \

  myminio my-warehouse

Migrating from Polaris (Generic REST)

For any catalog that implements the Iceberg REST spec, use --source-type rest. Credentials are passed via environment variables rather than on the command line, which avoids exposing secrets in the process list:

export MC_TABLE_MIGRATE_SOURCE_ACCESS_KEY=<your-key>

export MC_TABLE_MIGRATE_SOURCE_SECRET_KEY=<your-secret>

‍

mc table migrate \

  --source-type rest \

  --source-uri http://polaris:8181 \

  --source-warehouse lakehouse \

  myminio my-warehouse

Migrating from Hive Metastore

Hive uses the Thrift protocol. Note that Iceberg views are not supported in Hive, so the migration registers tables only:

mc table migrate \

  --source-type hive \

  --source-uri thrift://hive-metastore:9083 \

  --source-warehouse s3://bucket/warehouse \

  --namespaces analytics \

  myminio my-warehouse

Migrating from AWS Glue

For Glue, pass region and credential properties explicitly. Using shell variable expansion keeps credentials out of the command string as it appears in process listings:

mc table migrate \

  --source-type glue \

  --source-property glue.region=us-east-1 \

  --source-property "glue.access-key-id=$AWS_ACCESS_KEY_ID" \

  --source-property "glue.secret-access-key=$AWS_SECRET_ACCESS_KEY" \

  myminio my-warehouse

One-Way Move: Register and Drop

When you are ready to fully decommission the source catalog entry for a set of tables, --delete-source registers each table in AIStor and then drops it from the source catalog. The command prompts for confirmation by default:

mc table migrate \

  --source-type nessie \

  --source-uri http://nessie:19120/iceberg \

  --source-warehouse warehouse \

  --delete-source \

  myminio my-warehouse

For CI pipelines or scripted cutover workflows, add --force to skip the confirmation prompt.

Handling Partial Failures

Migrations over large catalogs will occasionally hit transient errors — network timeouts, permission issues on specific tables, or edge cases in schema metadata. When --output-dir is set, the command writes a failed_identifiers.txt for any tables that could not be registered. You can feed that file directly into a retry run:

mc table migrate \

  --source-type nessie \

  --source-uri http://nessie:19120/iceberg \

  --source-warehouse warehouse \

  --identifiers-from-file /tmp/migration-preview/failed_identifiers.txt \

  myminio my-warehouse

This makes large migrations operationally tractable. You do not need to re-run the full discovery pass; you retry exactly what failed.

What This Means for Your Stack

The value here goes beyond convenience. Running a separate catalog service means another component in your dependency graph: another service to deploy, another one to keep highly available, another set of credentials to manage, and another failure point that can block query engines from resolving table locations.

Collapsing the catalog into AIStor means your Iceberg tables have a single home. The object store that holds your Parquet files also holds the metadata that describes them. Query engines make one connection to AIStor and get both catalog operations and data access from the same infrastructure. For teams running AIStor on-premises or at the edge, where every additional service adds operational weight, that consolidation has real value.

For teams coming from a managed cloud catalog — AWS Glue being the most common — migrating to AIStor also means removing a dependency on a cloud-provider-specific service. Your table metadata moves with your data, and the catalog endpoint becomes part of your own infrastructure rather than a managed service you pay access fees to reach.

Availability

mc table migrate is available as of release RELEASE.2026-04-13T21-15-24Z. Download the latest mc binary from dl.min.io.

Documentation at docs.min.io is being updated to cover the new command. In the meantime, mc table migrate --help provides the full flag reference with annotated examples for all supported source types.

If you want to test the end-to-end workflow before migrating production tables, a sample setup with a local Nessie instance and test data is available in the AIStor test data repository.