Migration
Migrate to Iceberg
without the operational gap
Snowflake and Databricks handle maintenance invisibly. Open Iceberg does not. LakeOps fills that gap — compaction, cleanup, and governance run on both your old and new stack while you migrate workloads at your own pace.
Run on both stacks at once
Snowflake + Iceberg in one control plane
No ops gap during migration
Maintenance runs from the moment you connect
Hit the ground running
Full operations already at scale — zero ramp-up after
LakeOpsLast 30 days Optimization Activity
Key Metrics
Storage
-56% reclaimedCPU
-76% reductionRecent Operations
| Operation | Table | Duration | Impact | Time | Status |
|---|---|---|---|---|---|
| Compact Data Files | customer_orders orders | 4s | 1.24 TB, 16 → 1 files | 57 minutes ago | SUCCESS |
| Expire Snapshots | payment_transactions payments | 27s | 8.2 TB | 4 hours ago | SUCCESS |
| Expire Snapshots | inventory_snapshots_20250702 warehouse | 3s | 2.1 TB | 4 hours ago | SUCCESS |
| Rewrite Manifests | raw_clickstream analytics | 1.9s | 3 → 1 manifests | 5 hours ago | SUCCESS |
| Compact Data Files | product_catalog products | 6m 11.3s | 3,008 → 1,256 files | 6 hours ago | SUCCESS |
Lake Events
Open and runs on your stack
The migration gap
Migrating the data is the easy half.
Operating it is where teams get stuck.
Snowflake and Databricks handle compaction, expiry, and cleanup invisibly. Move to open Iceberg and that responsibility lands on your platform team — unless someone else picks it up.
Nobody maintains the new tables
Snowflake and Databricks auto-compact behind the scenes. Open Iceberg does not. The moment tables land in your new catalog, maintenance becomes your team’s responsibility.
Two stacks, zero unified visibility
During migration you run both the old platform and the new lake. Health, cost, and query performance split across two dashboards that don’t talk to each other.
Query regressions block the next batch
Unmaintained Iceberg tables degrade within weeks — small files pile up, manifests bloat, planning slows. Analysts blame the migration, and the next batch of workloads stalls.
The ops gap kills confidence
Leadership approved the migration for cost savings. But three months in, the platform team is firefighting table health instead of delivering features. Trust erodes.
How it works
Connect both catalogs.
Migrate workloads at your own pace.
LakeOps manages table health across your old platform and your new Iceberg lake simultaneously. Move one workload at a time — tables stay healthy on both sides.
01 · Connect both catalogs
Unified visibility across your old and new stack
Connect your Snowflake, Glue, Polaris, REST, or S3 Tables catalogs — all of them, at once. LakeOps discovers every table across both your legacy platform and your new Iceberg lake, scores health uniformly, and gives you one dashboard for the entire migration.
- Multi-catalog, multi-cloud — connect Snowflake and Glue in the same view
- Table health scored from the first metadata read — no agents, no pipeline changes
- 10-minute setup per catalog — not a project
| Table | NS | Size | Status |
|---|---|---|---|
| customer_orders | orders | 1.24 TB | HEALTHY |
| payment_transactions | payments | 860 GB | WARNING |
| raw_clickstream | analytics | 4.6 TB | CRITICAL |
| product_catalog | products | 42 GB | HEALTHY |
| user_sessions | analytics | 1.9 TB | WARNING |
| inventory_levels | operations | 320 GB | HEALTHY |
| shipping_events | logistics | 580 GB | HEALTHY |
| search_query_logs | analytics | 3.2 TB | CRITICAL |
02 · Maintenance from day one
Tables are compacted and cleaned from the moment they land
On Snowflake or Databricks, compaction runs behind the scenes. Open Iceberg has no built-in maintenance. LakeOps fills that gap immediately: snapshot expiry, compaction, orphan cleanup, and manifest rewrite start running the moment your catalog connects — sequenced in the right order, adapted to each table’s write pattern.
- No maintenance gap — Iceberg tables never sit unmaintained during migration
- Health-driven cadence — high-write streaming tables run hourly, batch tables daily
- 95% faster compaction on a Rust engine — no Spark cluster to provision
Monitoring started at seq #4,812. Everything written from that point on is in scope.
03 · Route queries across both stacks
Migrate workloads gradually — not all at once
One SQL endpoint routes each query to the right engine — Trino, Spark, Snowflake, DuckDB, Athena. Move workloads one at a time: start with batch ETL, then analytics, then dashboards. If a workload isn’t ready, it stays on the old engine. No big-bang cutover.
- Gradual migration — route by workload type, team, or latency target
- Automatic fallback if the new engine underperforms on a query shape
- Cost comparison across engines — prove savings before you commit
Engine comparison
Compare engines side-by-side on cost, latency, throughput, and data scanned.
Select engines
Performance comparison
| Metric | Spark | Trino | Athena | Snowflake |
|---|---|---|---|---|
| Query success rate | 99.2% | 99.5% | 99.9% | 99.8% |
| Average runtime | 3.1s | 1.8s | 2.3s | 2.1s |
| Cost per query | $0.04 | $0.03 | $0.05 | $0.08 |
| Total queries | 3,120 | 2,456 | 1,280 | 1,876 |
| Data scanned | 4.2 TB | 2.8 TB | 1.5 TB | 3.5 TB |
Cost vs latency
Lower-left is ideal
Success rate
04 · Policies apply automatically
Governance rules carry over to every new table
Declare compaction targets, retention windows, and cleanup schedules at the catalog or namespace level. As you migrate tables into the new catalog, they inherit the policies automatically. No manual setup per table, no governance gaps.
- New tables inherit policies from their namespace — zero manual work
- Same rules across Glue, Polaris, Nessie, and Gravitino
- Full audit trail — every operation logged for compliance evidence
Policies
Manage maintenance, configuration, and lifecycle policies for your data lakehouse
| On | Policy | Type | Next Run | Last Run | Updated | Actions |
|---|---|---|---|---|---|---|
orders_critical | Compact Files | Apr 25, 2026, 8:12 AM | Apr 25, 2026, 03:05 AM | Feb 01, 2025, 3:46 PM | ••• | |
payments_compact | Compact Files | Feb 15, 2026, 12:06 AM | Feb 1, 2025, 02:18 PM | Feb 5, 2025, 4:03 PM | ••• | |
Remove orphan files (e-ip...) For all tables in all catalogs every 7 days | Orphan Files | Apr 25, 2026, 8:12 AM | Apr 25, 2026, 04:07 PM | Jun 23, 2025, 04:01 PM | ••• | |
clickstream_cdc_events_p | Expire Snapshots | Apr 25, 2026, 12:03 AM | Apr 25, 2026, 03:05 AM | Jan 28, 2025, 03:25 PM | ••• | |
sessions_cdc_events_p | Expire Snapshots | Apr 25, 2026, 12:03 AM | Apr 26, 2026, 03:05 AM | Jun 26, 2025, 11:11 PM | ••• | |
global_expire_snapshots Runs snapshot expiration on all tables once a day | Expire Snapshots | Apr 26, 2026, 1:18 PM | Apr 07, 2026, 01:08 PM | Mar 14, 2026, 8:42 AM | ••• | |
manifest_rewrite_weekly Rewrite manifests for all critical tables weekly | Rewrite Manifests | Apr 28, 2026, 2:00 AM | Apr 21, 2026, 02:00 AM | Mar 10, 2026, 9:15 AM | ••• | |
staging_config | Configuration | — | — | Dec 31, 2025, 02:45 PM | ••• |
05 · Smooth landing
Operations are already running when migration ends
Because LakeOps managed both stacks throughout the migration, your new Iceberg lake arrives at full operational maturity. Compaction cadences are tuned, governance policies are enforced, health baselines are established. No ramp-up period — the platform team ships features instead of fighting table health.
- Zero ramp-up — maintenance, governance, and routing already running at scale
- Proven baselines — health scores, cost trends, and performance metrics from day one
- No new overhead — the same control plane you used during migration runs everything after
Before — Proprietary
After — Open Iceberg + LakeOps
From teams who migrated
“We ran LakeOps throughout the migration”
“We ran LakeOps throughout our migration off Snowflake—it worked with both stacks at the same time. That single control plane took away almost all the overhead of managing our own Iceberg lake, so we could focus on the move instead of maintenance.”
Itay B.
Data Platform Lead
“LakeOps works with our Snowflake and Databricks stack—no vendor lock-in. We cut weeks of manual maintenance down to a few hours. One control plane across engines, and the team finally stopped firefighting small files and compaction.”
Egor S.
Senior Data Engineer
Results
Cut costs and boost performance
Benchmarks from production-grade tables across multiple engines and clouds.
Query speed
After compaction + layout optimization
CPU reduction
Compute hours across all engines
Storage saved
Orphans, snapshots & bloat removed
Table health
Autonomous maintenance keeps every table optimized
Deep dives
Migration guides for your stack
Snowflake to Iceberg: A Smooth Migration
Migration patterns, operational trade-offs, and a phased rollout sequence.
Read guide →Databricks to Iceberg: A Smooth Migration
Five tools, three migration shapes, and how to keep tables healthy after the move.
Read guide →Apache Iceberg Migration Strategy
From Hive, Parquet, or Delta — in-place, CTAS, and shadow migration approaches.
Read guide →Connect in minutes
- no vendor lock-in
Connect catalogs & engines
Only metadata is processed — never retained or stored.
Get visibility & insights
Telemetry reveals table health and actions needed.
Choose your mode
Autopilot, manual approval, or policy-driven.
Lakehouse optimized
Built for enterprise
grade data lakes
SOC 2, SSO, RBAC, dedicated support, and the scale your largest Iceberg lakes demand.
Security & compliance
SOC 2 Type II, encryption, SSO/RBAC, and audit trails for regulated teams.
Scale & control
One control plane for your full lake. Real-time visibility, policies, and predictable performance.
Support & training
Dedicated onboarding, training, and enterprise SLAs. Deploy in VPC or on-prem.
Get started
See LakeOps on your stack
Get a personalized walkthrough with your data and architecture.
Short call, no commitment.
Typically 30 min · Free