TL;DR
Databricks Lakebridge is a free, open-source migration tool that assesses legacy warehouses and ETL pipelines, converts their code, and validates results before cutover. Databricks reports up to 80% task automation and roughly 2x faster implementation than manual migration across 10+ source platforms including Teradata, Snowflake, Oracle, and Informatica. It handles straightforward SQL and warehouse migrations well. Complex ETL logic, custom business rules, and validation sign-off still require engineering judgment the tool does not supply on its own.
Databricks gave away its own migration tooling for free in June 2025, and that undercut an entire category of paid accelerators built to do exactly that job. The tool is called Lakebridge, and it assesses, converts, and validates legacy data warehouse and ETL workloads on the way into Databricks SQL.
For a data engineer staring at a Teradata or PowerCenter estate, the free price tag raises a real question. What does Lakebridge automate on its own, and where does a free tool stop being enough for an enterprise migration?
This article breaks down what Lakebridge does, how it works end to end, which source systems it currently supports, how it compares to manual and partner-led migration, and where its limits show up in practice.
Key Takeaways Lakebridge has three components, an Analyzer for assessment, a Converter for code translation, and a Validator for reconciliation Databricks reports up to 80% task automation and 2x faster implementation versus manual migration Source support spans 10+ platforms, but assessment coverage and conversion coverage are not the same list Lakebridge’s converted output targets Databricks SQL specifically, worth knowing for teams keeping a multi-platform strategy Complex Informatica PowerCenter logic, custom UDFs, and validation criteria still require manual engineering review The Analyzer can produce early cost and effort estimates before any code conversion begins
Evaluating a Migration to Databricks? Kanerika is a Databricks Consulting Partner with production migrations from Teradata, Informatica, and Snowflake with full Unity Catalog governance.
Explore Our Databricks Practice
What Is Databricks Lakebridge Databricks Lakebridge is a free migration toolkit built by Databricks Labs to move legacy data warehouses and ETL pipelines onto the Databricks Lakehouse. It came out of Data+AI Summit 2025, aimed at a problem every migration project runs into. Years of undocumented SQL and stored procedure logic sit inside a platform the business wants to retire.
In practice, that adds up to thousands of views, stored procedures, and ETL jobs built up over a decade by different teams, with little documentation left behind. Lakebridge’s Analyzer scans that environment directly and generates a multi-tabbed report inventorying every object that needs to move .
Lakebridge doesn’t replace a migration project. It handles the mechanical parts, scanning the source environment, converting code, and checking the output against the original, so engineers spend their time on the logic that needs a human decision. Databricks positions the tool as extensible, letting partners contribute features as new migration patterns show up in the field.
That split of work happens across four steps, each building on the one before it.
Source: Databricks How Databricks Lakebridge Works Lakebridge runs as a four-step pipeline, with three named components handling the first three steps and deployment closing the loop.
1. Analyzer The Analyzer connects to the source environment and profiles it. It inventories tables, views, ETL jobs, and stored procedures, then classifies each by complexity from low to very complex, which is what lets a team scope the project before committing a timeline.
2. Converter The Converter translates the profiled SQL and ETL logic into Databricks SQL or PySpark. It runs through one of three transpilers, BladeBridge, Morpheus, or Switch .
BladeBridge is Lakebridge’s mature engine with the widest dialect coverage. Morpheus is newer, with a narrower dialect set and experimental dbt support. Switch is an LLM-based transpiler built for more complex conversions, and the Lakebridge Agentic Converter extends this further, using subagents that convert files concurrently and retry any section that fails validation.
3. Validator The Validator reconciles source and target data, checking schema, row counts, and column-level accuracy after conversion. This is where a team catches a transformation that converted syntactically but changed the result.
4. Deployment Validated workloads deploy into the target Databricks workspace, where they run alongside Unity Catalog governance and the rest of the Lakehouse. Nothing here forces a full cutover in one move. Lakebridge supports lift-and-shift and hybrid approaches , so a team can stabilize on Databricks first and modernize workloads afterward.
Which of those four steps carries the most weight depends entirely on what kind of migration is running.
Where Databricks Lakebridge Fits Lakebridge is built for a specific range of projects, and knowing which one applies saves time before evaluation even starts.
1. Legacy Warehouse and Platform Migration Teams moving SQL-heavy workloads off Teradata, Oracle, Snowflake, or Synapse into Databricks SQL get the most direct value here. The Analyzer profiles the estate, the Converter handles dialect translation, and the business ends its dependence on aging infrastructure without a manual rewrite.
2. SQL and ETL Modernization Organizations keeping their broader architecture but converting individual SQL scripts, stored procedures, and ETL jobs use Lakebridge for the code-conversion piece on its own, without a full platform swap attached. The Converter handles this independently of the Analyzer’s estate-wide profiling.
Read More: Databricks Lakeflow: What It Is and How Teams Use It
3. Large-Scale, Complexity-Sorted Migrations Enterprises with thousands of legacy objects use the Analyzer’s complexity classification to sequence the project, moving simple workloads first and holding complex ones for closer review. That sequencing is the difference between a predictable rollout and a stalled one.
4. Early Cost and Effort Estimates Teams that need a defensible budget number before a project gets approved can run the Analyzer early. It generates a complexity and effort breakdown that supports planning conversations with finance and leadership, before any code gets converted.
None of those use cases work if the source platform isn’t on Lakebridge’s supported list yet.
Databricks Lakebridge Supported Sources Lakebridge’s source coverage isn’t one list. Assessment support and code conversion support come from different components and don’t line up exactly, which is worth checking before scoping a project.
The Analyzer’s profiler currently covers Snowflake, Redshift, BigQuery, Oracle, and Legacy SQL DW as assessment targets, alongside its original base of Teradata and Synapse. The Converter’s transpile support runs through DataStage , Informatica in both Cloud and PowerCenter versions, Netezza, Oracle, Snowflake, SQL Server, and Teradata.
Databricks Lakebridge Supported Sources by Component Capability Currently Covers Assessment (Analyzer/Profiler) Teradata, Snowflake, Redshift, BigQuery, Oracle, Synapse, Legacy SQL DW Code conversion (Converter) DataStage, Informatica (Cloud and PowerCenter), Netezza, Oracle, Snowflake, SQL Server/Synapse, Teradata Reconciliation (Validator) Teradata added as a source platform in recent releases
Check the current documentation before scoping, not a blog post from last year. Lakebridge ships new source support on a rolling basis, and a source that wasn’t covered six months ago may be now.
Knowing what’s supported only answers half the planning question. The other half is what happens at each stage of the project.
Databricks Lakehouse Architecture: What’s Changed in 2026 See how Databricks Lakehouse Architecture is evolving in 2026 core components, enterprise design patterns, governance, and migration pitfalls teams.
Learn More
Databricks Lakebridge Migration Process A Lakebridge project generally moves through eight stages, and the tool contributes different amounts of automation at each one. Teams not ready to commit to a full migration yet sometimes look at Lakehouse Federation instead, which queries data across platforms without moving it, though that is a different problem than the one Lakebridge solves.
Databricks Lakebridge Migration Process: Stage by Stage Stage What the Team Does What Lakebridge Contributes Assess Define scope, source systems, and success criteria Analyzer profiles the environment and classifies complexity Convert Route flagged workloads to the right transpiler Converter translates supported dialects automatically Remediate Rework logic the transpiler couldn’t handle Flags unsupported syntax during conversion Validate Set pass and fail criteria for reconciliation Validator generates schema and row-level comparison reports Test Run performance and business logic checks on Databricks No direct role, output feeds into team-led testing Deploy Approve cutover and manage rollback plans Supports lift-and-shift and hybrid deployment paths Optimize Tune clusters, storage, and query performance post-migration No direct role, this happens after the tool’s job ends
The gap between “what Lakebridge does” and “what the team does” in that table is where a project’s real risk sits. Automation covers the assessment, conversion, and reconciliation reporting. Everything involving a judgment call, remediation priorities, test criteria, rollback authority, still sits with the engineering team.
The Optimize stage is entirely team-led, and it usually involves applying Databricks performance features like liquid clustering that Lakebridge itself doesn’t configure. That is exactly the split the next comparison makes explicit.
Databricks Lakebridge vs Manual vs Partner-Led Migration The real choice for most teams isn’t Lakebridge versus nothing. It’s Lakebridge alone versus Lakebridge paired with a consulting partner who handles what the tool can’t automate.
Databricks Lakebridge vs Manual vs Partner-Led Migration Factor Manual Migration Lakebridge Alone Lakebridge + Partner-Led Workload discovery Manual inventory Automated via Analyzer Automated, plus dependency mapping across hidden integrations Code conversion Rewritten from scratch Automated where dialect is supported Automated, with manual remediation on flagged sections Complex ETL logic (custom UDFs, nested procedures) Fully manual Flagged, not resolved Redesigned by engineers with source-platform experience Validation sign-off Custom-built per project Reconciliation reports generated Reports reviewed against business-defined pass criteria Architecture decisions Team-dependent Not addressed Part of the engagement
No row in that table is a surprise once a team has scoped the workload. The differences show up in execution, not in a spec sheet.
1. What Lakebridge Handles Well Dialect translation, schema mapping, and reconciliation reporting are exactly what an automated tool should own. Lakebridge does that part reliably for supported sources, and doing it manually would waste engineering hours on work a script does faster. Where the conversion lands also counts, converted workloads run on Databricks SQL’s Photon execution engine , which is a large part of why teams pursue the move in the first place.
2. Where Human Judgment Is Still Required A tool can convert syntax, but it can’t decide whether a PowerCenter Lookup should become a broadcast join or whether a Sequence Generator needs redesigning for distributed execution. It won’t set the business rules for what counts as a passing reconciliation either.
Kanerika’s own migration work through FLIP runs into this same 80/20 pattern. Automation handles the bulk conversion, and engineers spend their time on the redesign decisions the tool flags but doesn’t make.
3. Where Lakebridge Sits Among Other Migration Tools Lakebridge isn’t the only accelerator in this category, and the broader Databricks competitor and tooling landscape is worth a look before committing to one path. Informatica’s own CLAIRE Modernization Agent routes through IDMC first, a different path than a direct-to-Databricks conversion. Kanerika’s FLIP and tools like LeapLogic cover both PowerCenter and BDM/DEI repositories, which is broader than Lakebridge’s current Informatica coverage.
Tool selection carries more weight than most teams realize going in, and picking the wrong one for a given repository type costs weeks of rework later.
Best Practices for a Databricks Lakebridge Migration Five practices consistently keep Lakebridge migrations on schedule.
1. Start With Full Discovery: Run the Analyzer on the full estate before touching any conversion settings, not on a sample. Skipping this step is what causes the dependency surprises and complexity spikes that derail timelines mid-project. It is the same discipline Kanerika applies across its data engineering work generally.
2. Classify and Sequence by Complexity and Criticality Together: Complexity alone is the wrong sequencing filter. A simple workload feeding a critical daily report deserves earlier attention than a complex one nobody depends on.
3. Review Every Converted Script Before Production: Check even the workloads the tool marks as fully converted. Automated conversion reduces manual work, it does not remove the need for a second set of eyes on business-critical logic.
4. Set Reconciliation Pass Criteria in Writing First: Define what counts as an acceptable discrepancy before conversion starts, not after the Validator flags something unexpected. Teams that skip this step end up arguing judgment calls under deadline pressure instead of checking against an agreed standard.
5. Document Every Manual Remediation: Each fix a team makes outside the tool becomes the pattern library for the next migration. Skip this step and the same edge case gets solved twice, by two different people, on two different projects.
Even with all five practices in place, the tool itself has limits worth knowing before they show up mid-project.
Challenges and Limitations of Databricks Lakebridge A free tool is still worth scrutinizing before a project depends on it.
1. Transpiler Coverage Varies by Dialect BladeBridge carries the widest dialect support, Morpheus is newer with a smaller set of supported dialects, and Switch handles complex cases through an LLM rather than fixed rules. Picking the right transpiler for a source system isn’t automatic, and getting it wrong produces incomplete conversion output.
Converting an Informatica repository , for example, requires specifying the exact source dialect on the command line so the tool selects the right transpiler. Get that specification wrong, and part of the workload can fall outside what gets converted.
2. Complex Business Logic Needs Manual Remediation Nested PowerCenter mappings, custom transformation expressions, and pre-session shell scripts commonly fall outside what any transpiler converts cleanly. Kanerika’s own FLIP migrations flag the same categories, Lookup transformations, Sequence Generators, and pre-session scripts, as the 20% that needs engineering redesign rather than automated translation.
3. Output Targets Databricks SQL Specifically Third-party migration comparisons note that Lakebridge’s converted output is built for Databricks , not a multi-target destination. That’s a reasonable design choice for a Databricks-native tool, but it’s worth knowing for a team still weighing platforms.
4. Reconciliation Still Needs Human-Defined Criteria The Validator produces schema and row-level comparison reports, but someone has to decide what counts as an acceptable discrepancy. A tool can flag a mismatch. It doesn’t indicate whether that mismatch is a rounding difference or a business-critical error.
How Kanerika Delivers Databricks Migrations in Practice Kanerika is a Databricks Consulting Partner with production migrations across manufacturing, retail, financial services, and healthcare. Every engagement starts with a discovery scan that maps the full source estate before any conversion work begins, because the gaps automated tools flag for manual review are where most migration programs lose time and budget.
Three areas where Kanerika’s Databricks migration practice delivers directly:
Complex ETL and business rule conversion: Kanerika engineers handle the transformation logic, custom business rules, and edge cases that automated tooling identifies but cannot resolve without domain and engineering judgmentMigration acceleration with FLIP: FLIP , Kanerika’s proprietary migration accelerator, reduces manual migration effort by 50 to 60% and compresses complex timelines to approximately 90 days. It handles source platform parsing, transformation mapping, and output validation across Informatica, SSIS, and legacy warehouse environmentsUnity Catalog governance from day one: Access controls, lineage tracking, and data quality checks are configured in Unity Catalog before any workload runs against the migrated environment, not retrofitted after production go-live
Kanerika holds ISO 27001, ISO 27701, ISO 9001, SOC II Type II, and CMMI Level 3 certifications across 100+ enterprise clients with a 98% retention rate.
Case Study: Informatica to Databricks Migration for a Healthcare Provider A healthcare provider running clinical, diagnostic, and billing workloads across multiple facilities needed to move its Informatica pipelines to Azure Databricks without losing reporting accuracy during cutover. Rising patient volumes and reporting complexity had made the existing batch-heavy pipelines a bottleneck for audits and operational reporting.
Kanerika’s assessment surfaced hidden dependencies across clinical, claims, and billing systems before conversion started. FLIP then handled the bulk of the workflow conversion to Azure Databricks, preserving business logic while engineers re-architected pipelines for distributed processing and a unified analytical path across departments.
Results: 71% higher reporting accuracy across clinical and financial reports 38% reduction in data handling costs through optimized compute 64% faster decision-making for clinical and administrative teams
Wrapping Up Databricks Lakebridge is a genuinely useful free tool for warehouse and SQL migrations onto Databricks, and it automates the mechanical work well. Its limits show up exactly where every migration tool’s limits show up, in complex business logic, validation judgment calls, and architecture decisions a script can’t make.
Teams running a straightforward migration should start with Lakebridge before paying for anything else. Teams facing a complex Informatica estate or a governance-heavy rollout get more value pairing it with a partner who’s already done the redesign work.
Ready to Move Your Data Warehouse to Databricks? Kanerika delivers Databricks migrations with Unity Catalog governance and zero production downtime as standard delivery outcomes.
Book a Meeting
FAQs
1. What is Databricks Lakebridge? Databricks Lakebridge is a free, open-source migration toolkit from Databricks Labs that assesses, converts, and validates legacy data warehouse and ETL workloads on their way to Databricks SQL. It runs through three components, an Analyzer, a Converter, and a Validator, and automates a large share of the mechanical migration work for supported source systems.
2. Is Databricks Lakebridge free to use? Yes. Lakebridge is free and open-source, distributed through Databricks Labs on GitHub. Compute costs on Databricks itself, and any engineering time spent on complex conversion or validation work, sit outside the tool and still factor into a project’s real cost.
3. What data sources does Lakebridge support? Assessment support currently covers Teradata, Snowflake, Redshift, BigQuery, Oracle, Synapse, and Legacy SQL DW. Code conversion covers DataStage, Informatica in both Cloud and PowerCenter versions, Netezza, Oracle, Snowflake, and SQL Server. Source coverage updates on a rolling basis, so check current documentation before scoping.
4. What is the difference between Lakebridge and BladeBridge? BladeBridge is one of three transpilers Lakebridge uses internally for code conversion, alongside Morpheus and Switch. BladeBridge carries the widest dialect coverage of the three and handles the bulk of ETL and SQL translation work, while Morpheus and Switch cover newer or more complex conversion cases inside the same toolkit.
5. Can Lakebridge migrate Informatica PowerCenter workloads? Yes, Lakebridge’s Converter supports both Informatica PowerCenter and Informatica Cloud as source dialects, converting mappings and workflows into Databricks-ready code. Complex PowerCenter logic, including custom transformation expressions, Sequence Generators, and pre-session shell scripts, commonly still needs manual review after automated conversion runs.
6. How much of a migration can Lakebridge automate? Databricks reports up to 80% automation of migration tasks and roughly 2x faster implementation compared to manual conversion. That figure applies to the mechanical translation and validation work. The remaining share is typically the complex logic and architecture decisions that need engineering judgment.
7. Does Lakebridge replace the need for a migration consulting partner? For straightforward SQL and warehouse migrations, often yes, since the mechanical conversion work is exactly what the tool is built to automate. For complex Informatica ETL, governance-heavy environments, or projects without an existing validation framework, a partner adds the practitioner judgment the tool doesn’t provide on its own.
8. What happens after Lakebridge converts a workload? Converted workloads go through the Validator for reconciliation before deployment, comparing schema, row counts, and column-level data against the source. Teams review anything flagged, remediate it, then deploy validated workloads into the target Databricks workspace under Unity Catalog governance.
