Solutions

Iceberg is the easy decision. The pipeline rebuild is the hard part.

Moving to Apache Iceberg is not a table format swap. Every pipeline that feeds your tables and every job that reads them has to change. Dagen's agents do that work: they read your existing pipelines, carry your logic forward, and deliver Iceberg-native pipelines you can trust.

Why Iceberg, and why now

The case for Iceberg is closed. The pipelines are the real project.

Open tables solve the easy 20%. Dagen's agents solve the other 80% — the pipelines that feed and read them.

Open tables, no lock-in.

Any engine on top

Spark, Trino, Athena, Snowflake, and BigQuery all read the same Iceberg tables — no re-platforming to switch.

Object-storage pricing

Storage costs what S3 costs, not a warehouse premium, with time travel and schema evolution built in.

The table format is 20% of the project.

The other 80%, hidden below the surface

Ingestion, transformations, orchestration, and downstream readers all have to be rewritten around the new tables. Nobody budgets for the pipelines — the pipelines are the project.

Built for Iceberg on AWS.

Deploys into your account

Tables on S3, catalogs in Glue, compute on EMR and Athena — under the AWS governance you already run.

See our AWS partnership
How Dagen migrates

Reuse over rip and replace.

01 · Discover

Map the estate

Dagen's agents read your existing pipelines, SQL, models, jobs, and schedules — mapping every asset, dependency, and piece of business logic embedded in the code.

02 · Plan

Propose the architecture

Agents propose what converts as-is, what gets modernized, and what gets retired. Your engineers review and approve the plan before anything is built.

03 · Build

Generate the pipelines

Agents generate Iceberg-native pipelines that preserve your business logic, extracted straight from the code you already wrote.

04 · Validate

Run in parallel

New pipelines run alongside the old ones. Agents reconcile outputs and surface every discrepancy for review — you cut over when the evidence says so.

05 · Run and heal

Stay governed

After cutover, the agentic runtime monitors and heals the new pipelines, with full lineage recorded from old estate to new.

Frequently asked

Iceberg migration, answered.

How long does an Iceberg migration take?+

It depends on estate size, but the bottleneck is rarely the tables — it's rebuilding the pipelines around them. Dagen compresses that work by generating pipelines from your existing assets instead of rewriting them by hand.

Can we migrate from Hive tables to Iceberg?+

Yes. Hive-to-Iceberg is the most common starting point. Dagen's agents read your existing Hive-based jobs and generate Iceberg-native replacements.

Can we migrate from Snowflake or BigQuery to Iceberg?+

Yes, and it's usually not a departure. Snowflake and BigQuery both support Iceberg tables, so many teams adopt Iceberg alongside the warehouse they already trust. Dagen builds the pipelines either way.

Do we have to stop development during the migration?+

No. New pipelines run in parallel with the old estate, and cutover happens table by table, on evidence.

What happens to our existing business logic?+

It's the most valuable thing you own, and it travels with you. Dagen's agents extract the logic from your existing SQL, models, and jobs, and preserve it in the new pipelines.

Bring us one pipeline.

Book a technical demo and we'll walk one of your own pipelines through discovery, plan, and build. You'll see exactly what your migration looks like before you commit to anything.