Cross-posted. This article's canonical home is iceberglakehouse.com.

Every warehouse migration sounds simpler before the first inventory. Then the team discovers old dashboards, hidden dependencies, undocumented stored procedures, replicated tables, cost-center politics, permission shortcuts, and ten slightly different definitions of the same metric.

That is why I am careful with the phrase "zero-copy migration." It is attractive because nobody wants to pay twice for storage or run a risky big-bang rewrite. But true zero-copy depends on the current system, file layout, table metadata, storage location, access model, and target architecture. Sometimes zero-copy means registering existing files as open tables. Sometimes it means translating metadata while leaving data in place. Sometimes it really means low-copy migration with selective rewrites. Sometimes it is simply not possible without exporting data.

The best 2026 playbook is not built around a slogan. It is built around staged modernization. Move toward open table formats. Preserve access during the transition. Validate results continuously. Reduce lock-in as a measurable outcome. Avoid copying data just to satisfy a platform boundary. Use query federation to keep the business running while the foundation changes.

That is the Dremio-positive direction: migration should not end with data trapped in a different proprietary box. It should end with an open lakehouse that supports many engines, governed semantic access, and fast analytical workloads.

Why Warehouse Migrations Fail

Warehouse migrations fail when they are treated as storage moves rather than operating-model changes.

A legacy warehouse is rarely just a place where tables live. It is a collection of habits. It contains data models, permissions, jobs, reports, extracts, user workflows, cost assumptions, and institutional memory. Some of that memory is documented. Much of it is not.

The first failure mode is underestimating dependencies. A table may feed a dashboard, a machine learning feature, a finance close process, a partner export, and a daily spreadsheet nobody wants to admit exists. If the migration only tracks obvious dashboards, it will miss important consumers.

The second failure mode is copying everything before understanding value. Large migrations often begin with bulk export because it feels concrete. But copying low-value, stale, duplicated, or unused tables consumes time and money. It also recreates old problems in the new platform.

The third failure mode is semantic drift. If teams rewrite logic during migration without a strong validation process, numbers change. Sometimes the new number is more correct. Sometimes it is not. Either way, trust suffers unless the difference is explained.

The fourth failure mode is switching lock-in layers. A team may leave a proprietary warehouse only to land in another tightly coupled storage, catalog, and compute model. The invoice changes. The architecture does not.

A good migration avoids those traps by treating openness, validation, and governance as first-class goals.

What Zero-Copy Really Means

Zero-copy can mean several things, and conflating them creates confusion.

Physical zero-copy means the data files stay where they are. The migration creates or translates table metadata so a new engine can read the same physical data. This works best when the existing data is already in open file formats and stored in accessible object storage.

Logical zero-copy means users can query data through a new platform without first moving it. Query federation often supports this. The data may remain in the source system while the new platform provides a unified access layer.

Metadata-first migration means the team translates schemas, table definitions, lineage, ownership, and semantic models before or alongside any physical data movement. This reduces risk because the team understands what is moving and why.

Low-copy migration means the team copies only what must be copied. Some tables may be registered in place. Some may be federated. Some may be rewritten into Iceberg. Some may be retired. This is often the most realistic path.

The phrase zero-copy is useful only if the team says which version it means.

Iceberg as a Migration Target

Apache Iceberg is a strong migration target because it gives object-storage data table semantics. It supports snapshots, schema evolution, partition evolution, manifests, and transactional behavior. Those features matter when a lakehouse becomes the system of record for analytical data.

In a migration, Iceberg helps in several ways.

First, it gives the target architecture an open table foundation. The organization is not simply moving from one proprietary query engine to another.

Second, it supports multiple engines. Spark, Dremio, Flink, Trino, and other tools can participate depending on the deployment and feature support. That gives teams more freedom to use the right engine for the workload.

Third, snapshots help with validation and rollback. A table can represent a clear state at a point in time, which is useful when comparing results against the source warehouse.

Fourth, schema evolution helps migrations that happen in stages. Tables can evolve without forcing every downstream consumer to switch at once.

Fifth, Iceberg aligns with open catalog patterns. REST catalogs and projects such as Apache Polaris make the catalog layer less of a proprietary bottleneck.

The migration goal should not be "move data to cheap storage." It should be "move analytical truth into an open, governed table layer."

The Role of Query Federation

Query federation is one of the most practical tools in a migration. It lets teams query across source systems and target lakehouse tables during the transition.

Without federation, migrations tend to become all-or-nothing. A dataset is either still in the old warehouse or fully moved to the new platform. That creates pressure to copy quickly and creates risk when consumers are not ready.

With federation, the new lakehouse query layer can reach into the old warehouse while new Iceberg tables come online. Analysts can compare old and new results. Dashboards can be migrated incrementally. Data products can be certified one domain at a time. The business does not have to pause while the platform team modernizes.

This is one reason Dremio fits the migration narrative well. Federation is not a side feature in this kind of project. It is how teams reduce risk. It lets the open lakehouse become the new access layer before every byte has moved.

A Staged Migration Blueprint

The first stage is inventory. Identify tables, views, jobs, dashboards, users, service accounts, costs, refresh schedules, and downstream dependencies. Classify assets by business value and migration complexity.

The second stage is rationalization. Retire unused tables. Merge duplicates. Flag unclear ownership. Identify metrics with competing definitions. Migration is a rare chance to clean up the estate.

The third stage is target design. Decide which datasets should become Iceberg tables, which should remain federated for now, which require physical export, and which can be registered in place.

The fourth stage is metadata translation. Translate schemas, table descriptions, ownership, tags, partitioning logic, access policies, lineage, and semantic definitions.

The fifth stage is parallel validation. Run old and new queries side by side. Compare row counts, aggregates, null rates, distinct counts, metric outputs, and performance.

The sixth stage is consumer migration. Move dashboards, notebooks, APIs, and agent tools to the new semantic and query layer gradually.

The seventh stage is optimization. Add acceleration, compaction, table maintenance, and cost controls once the workload is understood.

The eighth stage is retirement. Turn off old jobs and warehouses only after dependencies are confirmed.

Validation Is the Migration

The most important work in a migration is validation. Moving data is not enough. The organization has to prove that the new system answers the same business questions correctly or explain why the answer changed.

Validation should happen at several levels.

At the table level, compare row counts, file counts, partition coverage, schema types, null rates, distinct counts, and sample records.

At the query level, compare important reports and workloads. Use representative filters, joins, and time windows.

At the metric level, compare business definitions. Revenue, churn, usage, cost, margin, and retention should be reconciled with owners, not just scripts.

At the performance level, compare latency and resource cost. A migration that produces correct answers but breaks service-level expectations still needs work.

At the governance level, compare access behavior. Users should not gain or lose access accidentally. Sensitive fields should remain protected.

At the lineage level, confirm that downstream consumers are known. A table without lineage is a migration risk.

Validation should be automated where possible, but human review still matters for business definitions. A script can tell you two numbers differ. It cannot always tell you which number the business should trust.

Semantic Layers Reduce Migration Risk

Semantic layers are often discussed in the context of BI or AI agents, but they are also valuable during migration. A semantic layer lets the team define metrics and relationships in a place that is less tied to the physical source.

If dashboards point directly at warehouse-specific SQL, every migration becomes a rewrite. If dashboards and agents point at governed semantic definitions, the underlying tables can change with less disruption.

This does not make migration trivial. The semantic layer still has to be tested. But it gives the organization a cleaner abstraction boundary.

For agentic analytics, the semantic layer is even more important. Agents should not learn old warehouse table quirks and then repeat them forever. They should use certified definitions that survive the migration.

Security and Access Control

Warehouse migrations can accidentally change security. A table that was restricted in the source may become broadly visible in the target. A masking policy may be lost. A service account may receive more access than intended. A copied dataset may escape retention rules.

Security migration should be explicit. Inventory roles, groups, grants, masking policies, row filters, service accounts, and audit requirements. Translate them intentionally. Test them with real identities.

The target lakehouse should avoid broad storage credentials. Users and agents should access data through governed query and catalog layers. If object storage is the foundation, direct object access should be limited to controlled services.

This is another place where open architecture needs strong governance. Openness should mean portability and interoperability, not uncontrolled access.

When to Copy and When Not To

Not every dataset deserves the same migration path.

High-value analytical tables with many consumers are good candidates for Iceberg. They benefit from open table semantics, acceleration, governance, and reuse.

Cold historical data may be registered or archived rather than actively rewritten.

Highly sensitive datasets may remain in place behind federation until governance controls are fully validated.

Small reference tables may be copied because the cost is trivial and simplicity matters.

Tables with proprietary storage layouts may require export and rewrite.

Temporary or low-use tables may be retired.

The goal is not ideological zero-copy. The goal is an intentional reduction in unnecessary copying.

The Dremio-Positive Reading

This migration topic naturally supports the Dremio Lakehouse narrative because the best migration strategy values openness, federation, semantics, and performance.

Federation helps teams modernize without forcing big-bang migration. Open Iceberg tables reduce future lock-in. Semantic layers preserve business meaning. Query acceleration keeps the open lakehouse usable. Agentic interfaces can then operate over governed data rather than over a patchwork of warehouse-specific logic.

The conclusion is not that every source system disappears overnight. The conclusion is that the center of gravity moves toward an open lakehouse access layer. Dremio is compelling in that world because it helps query across the messy present while building toward a cleaner future.

Common Mistakes to Avoid

Do not migrate every table. Inventory first. Retire aggressively.

Do not treat zero-copy as a universal promise. Confirm physical layout, metadata compatibility, permissions, and engine support.

Do not rewrite business logic casually. Validate metrics with owners.

Do not let old warehouse quirks become the new semantic layer.

Do not give agents raw access to migrated tables before definitions and policies are ready.

Do not declare victory when data lands. Declare victory when consumers trust the new platform and the old dependencies are retired.

A Practical Runbook for the First 90 Days

The first month should focus on discovery and prioritization. Build an inventory of source tables, views, scheduled jobs, dashboards, extracts, owners, query frequency, storage footprint, compute cost, and sensitive data classifications. Do not trust the catalog alone. Interview finance, product, operations, data science, and support teams to find shadow dependencies. The goal is to identify which data assets matter, which are duplicated, and which can be retired.

During this phase, pick one or two business domains for a pilot. A good pilot is important enough to matter but contained enough to finish. Customer health, product usage, or infrastructure cost often work well because they touch multiple systems and reveal semantic issues quickly.

The second month should focus on target modeling and validation. Define the Iceberg table layout, catalog structure, namespace conventions, access policies, and semantic definitions for the pilot domain. If existing files can be registered in place, test that path. If data must be exported and rewritten, make that explicit. Build reconciliation queries early. Compare row counts, sums, distinct keys, time windows, and important metrics against the source.

The third month should focus on consumer transition. Move a small number of dashboards, notebooks, and agent tools to the new governed assets. Keep the source warehouse available for comparison. Track differences and classify them: migration bug, source data issue, intended semantic correction, or timing difference. Only after the business owner signs off should the new asset become the default.

This runbook is deliberately conservative. Migration projects fail when teams rush past trust-building. The first 90 days should prove the operating model, not just the data movement mechanics.

Data Contracts During Migration

Data contracts help prevent migration from becoming a vague promise that "the new table is equivalent." A useful contract describes the asset's purpose, owner, schema, primary keys or grain, freshness expectation, quality tests, access rules, semantic definitions, and known limitations.

For a warehouse-to-lakehouse migration, contracts should exist on both sides. The source contract documents what the old asset is believed to mean. The target contract documents what the new Iceberg or lakehouse asset is intended to mean. The validation process compares those contracts as much as the rows.

This is especially important when migration reveals that the old warehouse was inconsistent. Sometimes the source table is not actually correct. Sometimes a dashboard includes hidden filters. Sometimes a metric has drifted from the business definition. In those cases, the target lakehouse should not blindly reproduce the old behavior. It should document the change and get signoff.

Contracts also help agents. If an AI agent can read the asset purpose, grain, freshness, and approved metrics, it is less likely to misuse a migrated table. That turns migration work into AI readiness work.

Rollback and Parallel Run

Every serious migration needs a rollback plan. The plan does not have to mean abandoning the new platform. It means knowing how to return a consumer, job, or metric to the old path if validation fails.

Parallel run is the safest approach for important assets. Let the old warehouse and new lakehouse asset run side by side for a defined period. Compare results automatically. Review differences with owners. Track query performance. Measure cost. Watch user behavior. Only then change the default path.

Rollback should be granular. If one dashboard fails validation, that should not block an entire domain. If one table has a type issue, that should not stop unrelated tables. The migration plan should allow targeted reversions while the broader effort continues.

This is another reason query federation is valuable. A federated access layer can keep old and new assets reachable through one analytical surface. That makes comparison and rollback less disruptive.

How Migration Prepares the Agentic Lakehouse

Migration is not only a modernization project. It is also preparation for agentic analytics.

Agents need reliable table descriptions, metric definitions, lineage, access controls, freshness metadata, and audit trails. A well-run migration creates or improves all of those. It forces teams to name owners, document definitions, validate assumptions, and retire unused assets.

If the migration ends with open Iceberg tables but no semantic layer, agents will still struggle. If it ends with a semantic layer but no lineage, agents may answer without provenance. If it ends with fast queries but weak access controls, agents become risky. The migration should be judged by the whole foundation it creates.

That foundation is where the open lakehouse becomes more than a cheaper storage target. It becomes a governed operating surface for humans and machines.

The success criteria should reflect that. A migration is successful when trusted consumers move, duplicate workloads shrink, metric definitions become clearer, query performance is acceptable, old costs decline, and the platform gains more freedom than it had before.

Anything less is only relocation.

That distinction matters.

The Direction of Travel

Warehouse migration in 2026 should be less about moving from one compute engine to another and more about moving toward architectural freedom. Open table formats, open catalogs, federation, semantic governance, and agent-ready access are the real destination.

Zero-copy is valuable when it is real. Low-copy is valuable when it reduces risk. Metadata-first migration is valuable because it treats data assets as governed products rather than anonymous tables. Query federation is valuable because it lets teams modernize while the business keeps running.

The best migration is not the fastest bulk export. It is the migration that leaves the organization with fewer copies, clearer definitions, better governance, and more freedom to choose engines over time.

That is why this topic points toward the Dremio Lakehouse approach. The stronger the case for open migration becomes, the stronger the case becomes for a query and semantic layer that can make open lakehouse data practical.

For more of my thinking on data lakehouse and AI architecture, explore my books at books.alexmerced.com. To try a modern Agentic Lakehouse experience, visit dremio.com/get-started.