Vendor lock-in is a measure of cost and operational risk when you change a provider. The Exit Cost Test turns that idea into a repeatable, scored method. It evaluates seven dimensions: data format, catalog metadata, identity and policy, SQL and APIs, operations, egress, and organizational retraining. A low exit cost means another engine can read the same bytes, discover the same tables, reproduce controls, and take over writes in a tested amount of time. This article gives the full test, a worked scoring worksheet, an evidence checklist, an exit drill design with acceptance criteria, and guidance on what to measure after you switch.
Do this test before you sign a multiyear contract and periodically after you adopt a platform. The goal is practical: quantify how long and how much effort it takes to move production workloads, not argue about marketing terms. The test focuses on measurable activities you can time and repeat. A paper migration plan is useful, but weaker than a timed drill. Run drills against representative datasets, pipelines, and teams, then score and weight results to reflect your business risk.
This is not a binary checklist. Most open formats reduce but do not eliminate exit cost. Open formats, like Apache Iceberg, address part of the problem, specifically storage layout and table mutation semantics. But you still need metadata portability, policy transfer, and operational readiness. When I say open format, check the spec and the implementation you depend on. For Iceberg, verify the table format and REST catalog behaviors against the specification before assuming zero migration cost. The Apache Iceberg specification is a primary technical reference for format details and table semantics.
These are the seven dimensions you will score. Each gets a numeric score, evidence artifacts, and a timed drill. Assign local weights later based on business impact. We use these dimensions in the worked examples below.
Each dimension has specific failure modes. For example, formats that allow arbitrary vendor metadata in manifest files create subtle compatibility problems. Catalogs that store table state only in the control plane, not in object metadata, force full exports. Identity systems that embed proprietary IDs into ACLs require mapping tables and reconciliation work. Expect these failures unless your drill proves otherwise.
Collect evidence in tiers. Higher tiers provide stronger claims. A paper migration plan is useful but should not count as high evidence. Timed drills and cross-engine reads are the strongest evidence. Use the ladder to qualify each score in your worksheet.
Scoring converts qualitative gaps into a numeric decision tool. Score each of the seven dimensions 0 to 10. Use weights that reflect business risk. The table below is a template, not a rule. Weights should follow business risk, audit requirements, and cost sensitivity. For example, a regulated finance workload might weight identity and audit 30 percent, while a marketing analytics workload might weight egress and cost more heavily.
Example weighting guidance:
These weights are an example. Replace them based on regulatory constraints and the cost of downtime. The weighted score gives you a single number to compare providers or measure progress after mitigations.
I ran this worksheet during a migration evaluation for a mid-size retail analytics team. Your numbers will differ. I include the raw evidence I collected and the timed steps so you can reproduce the method.
Scope: 12 TB of Iceberg-managed event data, 350 daily writes, 120 daily analytics queries, some materialized views. Team: analytics engineers, data platform SRE, and data governance. Target: evaluate switching query engine to a new provider while keeping storage in the same object store.
Data format and storage compatibility, score 8/10. Evidence: table files in Iceberg layout. I verified schema evolution semantics with small write tests and confirmed the other engine could read snapshots and perform deletes using the same manifests. I examined the Apache Iceberg specification to ensure the table features in use were part of the stable spec. For deeper format checks, consult the Apache Iceberg spec and the REST catalog docs for behaviors that affect table discovery.
Catalog metadata portability, score 6/10. Evidence: the current platform uses a proprietary hosted catalog. The vendor provides an export API, but it omits some table-level metrics and history. I tested importing exported metadata into a Polaris-compatible catalog and found missing lineage entries. The platform supports an Iceberg REST catalog in principle, and the Iceberg REST protocol documentation helps you understand what a REST catalog exposes compared with a control-plane-only catalog. See the Dremio blog post on choosing an Apache Iceberg catalog for background on catalog implementations.
Identity, access, and policy migration, score 4/10. Evidence: ACLs are stored partly in the platform control plane, and some row-level policies are enforced by the query engine. I extracted role mappings, but the vendor forbids full export of audit logs in raw form. Recreating identical enforcement required building a mapping layer and re-authoring row filtering rules. This is a common failure mode when policy is embedded in the control plane rather than in table metadata or an external policy engine.
SQL and API compatibility, score 7/10. Evidence: I executed a representative query suite against both engines. Basic SQL, window functions, and aggregations returned identical results. Differences cropped up for proprietary UDFs and certain optimizer hints. Rewriting three UDFs and changing two query plans were needed. Track query differences with automated test suites during a dry run.
Operational tooling and automation, score 5/10. Evidence: platform handles compaction and background cleaning automatically. The file layout was compatible, but the new engine lacked the same automated compaction controller. I timed a manual compaction and estimated SRE work to automate it. Operational gaps are common even when formats are open, because maintenance tooling is often platform specific.
Egress and network cost, score 9/10. Evidence: storage remained in the same object store, so no data egress charges were required to flip engines. If the new provider required pulling data into a new storage account or region, costs would be higher. Always quantify transfer bytes, using provider cost calculators and your current query patterns as measured over a 30 to 90 day window.
Organizational retraining and runbook shift, score 6/10. Evidence: query engine changes required two half-day training sessions and updates to three runbooks. The platform team estimated two weeks of on-call fatigue while the new monitoring alerts stabilized. Count the cost of learning curves and incident debug time in your weightings.
Applying the example weights above produced a weighted score of 6.8/10. That number captured a medium exit cost, driven down by controls and policy extraction issues. The scoring showed where to invest: either negotiate stronger metadata export guarantees or build a policy translation layer before committing.
Below is a checklist for each dimension. For each item, collect the artifact and mark the portability tier it satisfies.
Linking to the right documentation helped me when I collected these artifacts. The Dremio article on the Apache Iceberg REST catalog explains how a REST catalog exposes table metadata and why it matters for migrations. The Dremio Open Catalog documentation shows practical ways to centralize metadata across engines. The Dremio Apache Iceberg platform page gives operational guidance about running Iceberg tables at scale.
A timed exit drill is the most persuasive evidence you can gather. Design drills for the smallest production slice that exercises all dimensions. The goal is not to migrate everything in one run, it is to prove you can perform the critical steps within acceptable risk and time.
Choose a set of tables that includes writes, deletes, schema evolution, and queries that drive dashboards. Include a table with row-level policies and at least one downstream materialized view if you use them. Schedule a drill during a low-risk window and notify stakeholders. Run drills quarterly to keep readiness current.
1. Baseline: run the query suite against the existing system, record runtimes and result checksums. Capture object storage state and catalog snapshots. Timestamp this baseline.
2. Catalog import: export the catalog artifacts and import them into the target catalog. Time the entire operation. Verify table discovery and snapshot visibility.
3. Read verification: run the analytics queries against the new engine in read-only mode. Compare results, row counts, and checksums. Record performance differences.
4. Policy re-creation: apply exported role and policy artifacts. Perform access tests for a sample of principals. Verify audit logs and enforcement on both engines.
5. Write takeover: flip a low-traffic write pipeline to the new engine, or run a controlled write test that appends and commits data. Verify snapshots and consistency after writes.
6. Operational checks: run compaction/vacuum processes, restore a deleted file from object storage if your retention policy allows, and run disaster recovery steps in the target environment.
7. Post-drill rollback: flip writes back to the original engine if you did not intend a permanent switch. Time the rollback and document what was manual work.
Set numeric thresholds for each criterion. For example, catalog import must finish in less than 4 hours and read diffs must be zero for critical dashboards. If you cannot meet acceptance, treat the drill as proof of the specific gap and plan mitigation work before any contract change.
Here are the failure modes I have encountered and practical mitigations.
These mitigations are practical but not free. Prioritize them using the same weighted scorecard. If identity and policy are critical, investing to duplicate enforcement in an external policy engine will have a greater ROI than fixing a handful of UDFs.
Governance should include a change control that requires a new drill when substantial platform features are adopted, for example, switching catalog types or enabling vendor-managed encryption at rest. The Dremio article explaining Apache Polaris architecture is useful if you evaluate a catalog that separates control plane concerns; it helps you map where metadata lives and how that affects exit cost.
After you migrate or adopt a new platform, collect metrics so you can measure actual exit cost over time. A single drill is a snapshot. Continuous measurement proves your assumptions.
Measure these metrics and put threshold alerts in place. If any metric degrades, run a targeted drill for the affected dimension and fix the root cause. The Cloud Native FinOps micro-survey (2024) suggests teams that measure cost continuously make different decisions than teams that do not, so treat cost metrics as operational telemetry you act on.
Open formats like Apache Iceberg significantly reduce the cost of moving bytes and understanding table semantics, but they do not solve metadata, policy, or tooling gaps automatically. The Iceberg specification defines table file layout, snapshot semantics, and schema evolution rules. If you plan to rely on an Iceberg table for portability, verify the features you use are specified and correctly implemented by your vendors. The Apache Iceberg REST protocol documentation describes how a REST catalog can expose table metadata for remote clients. If your current platform supports an Iceberg REST catalog, that is stronger portability evidence than a control-plane-only catalog, but you still must test the exact REST endpoints, behaviors, and authentication flows you need.
If you want a practical comparison of catalog options and how they affect migrations, read the Dremio blog post on choosing an Apache Iceberg catalog. If you need operational guidance on running Iceberg tables under real load, the Dremio Apache Iceberg platform page helps you understand the operational tasks you must automate. And for architects evaluating catalog separation, the Dremio piece on Apache Polaris architecture explains control plane and data plane separation patterns that influence exit cost.
Here is a concise worked checklist and the acceptance criteria I used in the retail example above. Use these verbatim if they match your risk tolerance, or tighten numbers as needed.
If any of these criteria fail, capture the partial result, estimate mitigation time, and rerun the drill after remediation. Treat the first failed drill as an expected outcome; the point is to reveal gaps early.
Contracts often mention portability in words but not in testable terms. Convert portability into obligations:
Negotiations are easier when you can show concrete drill failures and the time to remediation. If you rely on an Iceberg table layout, referencing the Iceberg spec and REST protocol in contract language reduces ambiguity about what counts as portable metadata.
The Exit Cost Test gives you a repeatable path from vague portability promises to specific, testable outcomes. Score the seven dimensions, collect tiered evidence, run a timed drill, and weight the scores against your business risk. Open formats like Iceberg reduce the biggest part of the byte-copy problem, but they do not eliminate the rest. Use the drill to find the real edges: vendor metadata, control-plane-only policies, and missing operational hooks. Negotiate export guarantees and include a timed drill in contracting when the cost of moving matters to you.
Answer first: convert each scored line in your scoring worksheet into one or more executable tasks, with a clear owner, estimated duration, and acceptance criterion that matches your exit drill acceptance criteria. The goal is a repeatable checklist you can run under time pressure, not a theoretical table. Below I give a concrete mapping from worksheet rows to test-plan tasks, a sample timing budget, and a short command list you can adapt.
Start by exporting the scoring worksheet into a CSV or ticketing backlog. For each row, add these columns: test task id, description, owner, prerequisites, playbook reference, time budget (minutes), success metric, evidence artifact. Keep entries short. Example rows you should have for the worked example in your draft include: 1) metadata export, 2) data files export, 3) identity and policy export, 4) query portability verification, 5) restore to alternate execution engine.
Sample timing budget for a medium sized drill, 8 person-hours total wall time: metadata export 60 minutes, data fingerprinting and sampling 90 minutes, data transfer simulation 120 minutes, policy and role extraction 45 minutes, restore and validation 90 minutes, query validation 60 minutes, triage and report 45 minutes. For larger catalogs increase proportionally.
Concrete task examples you can paste into a backlog. Adapt commands to your environment, verify versions and endpoints before the drill.
<!-- Example task: metadata export -->
# Task: Export table metadata to a portable REST spec or JSON
# Owner: Data platform engineer
# Time budget: 60 minutes
# Success: All tables referenced in the scope have schema, partition, and snapshot identifiers exported
# Evidence: metadata-export-2026-09-22.json
# Use the catalog's documented REST export, or run SHOW CREATE TABLE equivalent to capture DDL
# Verify primary keys, partition specs, and current snapshot id are included
<!-- Example task: Data file sampling and checksum -->
# Task: Sample file list and compute checksums
# Owner: Storage engineer
# Time budget: 90 minutes
# Success: For each sampled table, checksums and file paths match the storage layer and Iceberg manifest entries
# Evidence: checksums-2026-09-22.csv
# Use object-store APIs to fetch object metadata and compare to catalog entries
<!-- Example task: Export identity and policies -->
# Task: Extract roles, groups, and ACLs from the system, and map to target IAM model
# Owner: Security engineer
# Time budget: 45 minutes
# Success: All roles in scope have an exported representation and a mapping to target IAM
# Evidence: iam-export-2026-09-22.json
<!-- Example task: Restore to alternate engine -->
# Task: Point an alternate engine at exported metadata and storage, run validation queries
# Owner: Analytics engineer
# Time budget: 90 minutes
# Success: 80 percent of control queries return matching results within agreed tolerance
# Evidence: query-validation-2026-09-22.log
Keep the evidence artifacts in a versioned location, and number them so they link back to the scoring worksheet rows. If a task spills beyond its time budget, capture why and re-estimate. A paper migration plan will not provide these timestamps or artifacts, which is why a timed drill is a stronger signal of real exit readiness.
Injecting controlled failures during a drill reveals hidden coupling. Pick three failure classes to exercise: metadata catalog outage, partial object-store loss, and permission drift. For each class I list what to do, expected immediate symptoms, evidence to collect, and the scoring worksheet consequences.
1) Metadata catalog outage. Simulate by blocking access from the compute cluster to the catalog endpoint, or by running the catalog in maintenance mode if supported. Immediate symptom: queries that require snapshot resolution fail with explicit catalog errors. Evidence: failure logs, API error snapshots, duration until alternate metadata source is usable. Scoring impact: downgrades metadata portability and recovery time dimensions. Acceptance: your drill should show a documented failover path that restores read access to metadata within the acceptance window in the worksheet.
2) Partial object-store loss. Simulate by making a subset of object prefixes unavailable, or by introducing higher latency. Immediate symptom: read failures, missing file errors, or degraded scan throughput. Evidence: object-store error counters, failed read traces, percentage of files unreachable. Scoring impact: lowers data portability and restore time. Acceptance: the drill should demonstrate either complete recovery from intact backups or show that parity/replication covers the scope tables within the time budget.
3) Permission drift. Change an IAM policy or remove a role in the catalog. Immediate symptom: authorization failures for critical drill tasks, especially metadata export and query validation. Evidence: authorization-denied logs, IAM audit entries, steps to restore. Scoring impact: reduces identity and policy portability. Acceptance: after restoration, tests relying on identity should succeed and the exported policy mapping should have been usable to rebuild roles.
When you run these injections, timebox the recovery. Record the elapsed time from fault injection to full validation of the acceptance criteria. That elapsed time becomes an operating metric you publish to governance. If it is longer than the threshold in the scoring worksheet, escalate and remediate design or contract gaps identified by the drill evidence.
Turn drill outcomes into measurable operating metrics that live in your runbook. The three I recommend you publish after each drill are: mean time to metadata recovery MTMR, fraction of tables restorable within N hours, and percentage of control queries validated. Record each metric against the baseline in the scoring worksheet.
Decision table, actionable thresholds tied to your business risk. Use this to make go no-go decisions for procurement or continued use. Example rows for the decision table mapped to the worked example weights in your draft:
# Decision table example
# Metric | Good if | Warning if | Fail if
# MTMR (minutes) | <= 60 | 61 - 240 | > 240
# Tables restorable within N hrs | >= 90 percent | 60 - 89 percent | < 60 percent
# Control queries matched | >= 95 percent | 80 - 94 percent | < 80 percent
# Policy export completeness | Complete | Partial mapping required | Missing critical roles
Rollout checklist additions to your existing checklist. These assume you already have the evidence checklist and acceptance criteria sections. Add these items before the first timed drill: 1) run a dry run of each task without timing to validate scripts and permissions, 2) register an incident channel and war room before the drill, 3) pre-seed the evidence storage location and access controls, 4) allocate a timekeeper who will enforce time budgets in the worksheet, 5) agree on post-drill remediation owners for each failed item.
Finally, what to measure after deployment. Cross-check the metric trends against cloud spend signals. The NIST Cloud Computing Standards Roadmap suggests teams pay attention to operational cost variance. If drills show rising MTMR or lower restorable fraction while costs increase, treat that as a procurement and architecture red flag. Record timestamps and versions for facts checked on September 22, 2026, when you compare against Apache Iceberg behavior, specifically the table and REST protocol specifications in the Apache Iceberg documentation.
All of these additions make the scoring worksheet, evidence checklist, and exit drill acceptance criteria operational artifacts. They move the team from theoretical vendor lock-in assessment to measurable programmatic risk control. Run the first timed drill within 90 days of production cutover and repeat at a cadence tied to major platform changes or annually, whichever comes first.
Quarterly for critical workloads, and at least annually for lower-risk workloads. Run a new drill whenever you adopt major new platform features or change catalog strategy.
No. Iceberg reduces format and snapshot portability risk, but you still must validate catalog exports, policy migration, and operational tooling. Verify the specific Iceberg features you use against the Apache Iceberg specification and the REST protocol documentation. Facts checked on September 22, 2026.
It depends on business risk. For regulated data, give identity and policy at least 20 to 30 percent of the weight. For exploratory analytics, lower weights may be acceptable. Weights should follow actual business risk, not vendor preference.
No. A paper plan is weaker than a timed drill. Documentation and design are useful, but you need implementation tests and a timed exit drill to prove you can perform the migration within your SLA.
Set thresholds that reflect user impact. Examples: catalog import under 4 hours for drilled scope, read parity 100 percent for critical dashboards, write takeover visible in snapshots in under 10 minutes. Tighten thresholds for high-availability or compliance-sensitive workloads.
For format and catalog design, read the Dremio article on choosing an Apache Iceberg catalog. For REST catalog mechanics, the Dremio article about the Apache Iceberg REST catalog explains how a REST catalog can be used during migrations. If you want architecture-level thinking about separating control and data plane, the Dremio post on Apache Polaris architecture is useful. For operational guidance on running Iceberg at scale and practical platform features, see the Dremio Apache Iceberg platform page and the Dremio Open Catalog documentation. Each of those pages helped me map tests to implementation details in the worked examples above.
Continue with these related implementation and operations guides.
For a deeper treatment, download Apache Iceberg: The Definitive Guide, co-authored by Alex Merced and available free from Dremio.
To put the catalog and table-format ideas into practice, explore Dremio's Apache Iceberg platform.
Deploy agentic analytics directly on Apache Iceberg data with no pipelines and no added overhead.
Editor’s note, September 2026. This post was published in September 2023 and some product details have changed since. Nessie is still available and self-deployable under the Apache-2.0 licence, and it remains the clearest implementation of catalog-level branching. It is not an Apache Software Foundation project, and its development has slowed considerably. For how the current […]
With its capabilities in on-prem to cloud migration, data warehouse offload, data virtualization, upgrading data lakes and lakehouses, and building customer-facing analytics applications, Dremio provides the tools and functionalities to streamline operations and unlock the full potential of data assets.
This is Part 15, the final article of a 15-part Apache Iceberg Masterclass. Part 14 covered hands-on Dremio Cloud. This article covers the three migration strategies and how to execute a zero-downtime migration using the view swap pattern. Most organizations do not start with Iceberg. They have years of data in Hive tables, data warehouses, CSV files, databases, […]