Comprehensive Data Warehouse Migrations With Lakebridge

Summary

Lakebridge is Databricks' free, AI-powered migration tool that automates the data warehouse migration lifecycle—from assessment and code conversion to data migration and reconciliation—replacing expensive manual workflows.
The agentic code converter, currently in private preview, uses AI agents to translate proprietary SQL dialects and tools like TSQL and SSIS into open Databricks-compatible code with automatic syntax and semantic validation.
Lakebridge integrates with LakeFlow Connect for data replication, Unity Catalog for governance, and a reconciliation dashboard that provides row-level data fidelity checks to close the loop on a completed migration.

Comprehensive Data Warehouse Migrations With Lakebridge

Lakebridge is Databricks' free, AI-powered solution for migrating legacy data warehouses to the Lakehouse. Migrating from a legacy warehouse means confronting decades-old code, converting proprietary dialects, and reconciling bespoke differences between source and target systems. With Lakebridge, AI agents handle that automatically. We'll show how Lakebridge uses Genie Code to accelerate the migration lifecycle: Assessment: analyze legacy code automatically to surface complexity, dependencies, and risk before work begins Conversion: Use agents to convert proprietary dialects into open ANSI SQL, automatically validating syntax and semantic intent Data Migration: Use LakeFlow Connect to replicate data from a wide range of sources, either as a one-time snapshot or incremental change capture Reconciliation: easily identify discrepancies between source and target systems With Lakebridge, migrations are faster to scope, easier to deliver, and no longer dependent on expensive manual workflows.
Talk By: Guenia Izquierdo Delgado, Engineering Manager, Databricks ; Jonathan Brito, Staff Product Manager, Databricks ;

Chapters

FAQs

What is Lakebridge and what does it do?

Lakebridge is a free, AI-powered tool from Databricks that automates the end-to-end process of migrating legacy data warehouses to the Databricks lakehouse. It covers every phase of a migration: automated assessment of legacy code complexity and dependencies, AI-driven conversion of proprietary SQL dialects, data migration via LakeFlow Connect, and final data reconciliation.

How does Lakebridge handle converting legacy SQL code?

Lakebridge includes an agentic code converter—currently in private preview—that uses AI agents to translate proprietary SQL dialects such as TSQL and ETL tools like SSIS into open ANSI SQL compatible with Databricks. The converter automatically validates both syntax and semantic intent, reducing the manual effort required for code translation.

What is the reconciliation step in a Lakebridge migration?

Reconciliation is the final step of a Lakebridge migration, providing a dashboard that compares source and target systems at the row level to identify any data discrepancies. This step gives data engineers and platform architects confidence that the migrated data in Databricks matches the original system before decommissioning the legacy warehouse.

What Databricks capabilities does Lakebridge unlock after migration?

Once data is migrated to the Databricks lakehouse through Lakebridge, organizations gain access to the full Databricks Data and AI platform including AI/BI dashboards, Genie for natural-language analytics, developer tools, and modern pipeline orchestration with LakeFlow Connect and Unity Catalog governance.

Full transcript

[00:08] I'm just going to get started. Uh so again, welcome everyone in the audience. Uh my name is Jonathan Burto. Uh I'm a PM here at Data Bricks and the PM for Lakeridge. And I'm joined here with my colleague. >> Hi everybody. Hi. Can you hear me?
[00:21] >> Yeah. Okay. Um hi, my name is Gardo. I'm an engineering manager here at Data Bricks focused on building Lake Bridge. Nice to see you all. Okay, great. So throughout the session, we're going to walk through a very
[00:33] common challenge that we see from our customers and this is migrating from a legacy data warehouse to a datab bricks lakehouse. Uh we'll introduce the concept of aentic lake bridge and this is our new AI powered tooling that can
[00:46] really accelerate and automate each step of a migration from a legacy data warehouse. So to kick things off, a little bit of legal ease. I'm not going to go through
[00:58] this line by line. I'm pretty sure you guys have probably already seen this before in past presentations. Uh but basically what we're saying here is these are all forlooking statements. These aren't necessarily commitments.
[01:14] Okay. So what we'll cover today, there's still a lot of echo. Um but what we'll cover today is the endto-end migration life cycle. Uh so we'll start with how to use Aentic Lake bridge to actually plan your migration
[01:26] and automate a lot of the complexity around scoping and ultimately getting to a migration plan. We'll introduce the Agentic code converter which are a new tool that's actually in private preview
[01:38] allows you to translate from proprietary dialects to uh database compatible code. And then lastly, we'll talk through uh new data validation capability. And this is really the last step of a migration
[01:50] to help you kind of close the loop on the overall experience. Okay, so we're going to tell this story through two protagonists. Um, Angela and
[02:02] Bob. Angela is a data engineer and Bob is the platform architect. Together, it's their job to make sure that they choose the right architecture for the future of their organization. So let's
[02:15] see actually what they have today. So here's the world that Angela and Bob are actually currently living in. This is a very classic legacy data warehouse architecture. As you can see here, if
[02:27] starting from left to right, you have some traditional sources. You have a CRM, you have ERP, you have some CSV files, those are then being loaded in uh through an external ETL tool, in this
[02:40] case SSIS. That data then lands in your data warehouse which is SQL server and then that eventually feeds uh your serving layer which in this case is going to be PowerBI but also some legacy
[02:52] tools like SSRS. So this works today. However, it wasn't really built with AI in mind and ultimately the cost of this architecture is starting to really starting to balloon and the team is trying to think about what comes next.
[03:10] So, we return to our protagonist and Angela has a great idea. She wants to migrate to data bicks lakehouse and there's really three big reasons why she wants to move to datab bricks. First is openness. Moving to data bricks means
[03:22] fully adopting open standards. So all their tables will be stored in open formats like Delta and iceberg. These tables then be exposed via open catalog APIs. So the Unity REST APIs, the
[03:34] iceberg rest catalog APIs which then allow you to have full access to the full ecosystem, not just data bricks but other tools you can imagine using. And then from there again of course all your data is stored in your customer managed
[03:46] bucket. So no more lock in. The second reason is unification. If you remember in our previous architecture, everything was separate. You had a
[03:58] separate ETL tool, you have a separate data warehouse, you have separate BI tools. And right now for Angela, even the leadership team now is asking them to start building with AI. And that to them is a new integration that they need
[04:10] to bolt on to this legacy architecture. Data bricks collapses all that into one unified platform. So you have a single data warehouse with unified governance, ETL and AI all built in.
[04:28] The third pillar is cost. When you add the licensing fees, subscription fees and the overhead of maintaining multiple systems, these legacy architectures be really expensive to maintain. Data bricks offers the best price performance and contrast. And on top of the
[04:41] consolidation benefits, so low overhead, you have things like serverless and autooptimized tables. So the cost savings can really start to add up when you're moving from your legacy system to something like data bricks.
[04:54] So return to Angela. She's really excited about this plan. She sees the vision. She wants to have a data data bricks lighthouse today. And now she's already thinking through, okay, what does this migration look like? So she
[05:07] starts jotting down some ideas. At a high level, you have these four steps. You have assessment. So, this is actually planning the migration, understanding the scope and complexity of the migration and then actually ultimately landing on a deliverable like
[05:20] a migration plan. This is critical because you're going need to bring this to your various stakeholders to make sure they're bought on the plan that you have a predictable and cost-effective migration. Then you need to convert code. So, you need to convert all this
[05:32] legacy code in in TSQL and SSIS to something that could actually run on data bricks. you need to migrate tables. Uh so this is actually physically moving the data from SQL server to data bricks. And then lastly you have reconciliation
[05:46] and this is uh typically the last step of the migration where you're actually saying hey I moved the data converted the code is everything working properly. So Angela has her plan. She's excited. She's ready to move forward.
[05:58] There's a there's a hitch. Her teammate Bob, he sees the value. He's excited about data bricks. Loves the idea. But this isn't his first migration and he knows this isn't going to be easy. As
[06:10] the data architect, his job is to really figure out things before they actually go wrong. And he sees four huge risks with this migration. So let's actually hear Bob out in terms of what he actually has to say.
[06:30] Okay. The first concern, this is actually targeting the assessment phase. If you're thinking through actually building a migration plan in Bob's mind, this actually looks more like an archaeology project. This is actually really captured well on this slide which depicted on the the right hand side of
[06:43] the slide. This is what a typical legacy data warehouse can look like after years and even maybe decades of organic growth. You know, situations where if you start at the top, you have two store procedures, nightly load and customer
[06:55] refresh. They're active pipelines, but they're actually not documented. So if you try to move these, how do you actually determine whether or not the business logic that you had in the old system is actually maintained in the new
[07:07] system? Then it gets even worse. You move to the next layer of their ETL pattern. You're seeing this legacy stored proc. And no one's actually sure if this actually still is in use today or the person who wrote it may not even
[07:20] be at the company. So for Bob, moving this is a really, really, really risky idea because at the end of the day, this could break things downstream. And you actually can see this on the slide here where there's a dotted line connecting this legacy store proc to their customer
[07:34] table. So there still is a hidden dependency that could be invisible to folks who haven't really touched this or didn't write the original code.
[07:46] Moving forward into code conversion another risk there's a lot of proprietary nuances to old school uh SQL dialects. So in this case, we're looking at some TSQL code on this slide, and you can see highlighted in yellow are some
[07:58] of the nuances of proprietary dialects that wouldn't necessarily cleanly map over to something within data bricks. So unless you're an expert potentially or you're working with experts, this may be hard to convert. So all this is really
[08:10] scaring Bob for data movement. It's really about the volume. there's a lot of tables in their existing system and moving those tables is going to be an effort all of itself.
[08:23] Yet you're seeing on this slide they have a database and then you have schemas. Each schema has dozens of tables but then you also have dozens of schemas. So all this can really balloon into quite a few tables actually to move all varying sizes and moving tables
[08:37] isn't just copying data. You actually have to do things like schema validation. Make sure the data types are actually matching. So there's a lot of work to make sure you don't end up in a world where you have downtime.
[08:52] The last step is reconciliation. And I mentioned before this is actually making sure two things um the source and tart are actually the same. And the tricky thing about this is actually convincing folks that you move things correctly. Typically what we see at data bricks is
[09:05] customers try to run the two systems in parallel and then run queries against their source and target tables to make sure things are actually matching. What Bob is concerned about is actually mismatches. So you can have situations where when you get a mismatch, how do
[09:18] you debug? This is a great example covered on this slide. This is a real example of a difference between SQL Server and data bricks. On the SQL Server side, if you have a string that has a trailing space, SQL Server will
[09:30] just trim that at query time. Data bricks on the other hand actually reads the data exactly how it's stored. So you can have a situation where you have identical queries running against identical tables and still getting different results. So for a human, this
[09:43] probably isn't something you may or know off the top of your head and can be really difficult to debug if you run into situations like this. So summarizing everything, these are Bob's concerns really from end to end.
[09:55] He sees risk with assessment, the undocumented ETL patterns, entangled dependencies, conversion, you have proprietary dialects, data migration, just the volume of tables that need to move. And then you have reconciliation
[10:07] which is this mismatch problem in debugging which can take a lot of time. So now the team is stuck. Angela Bob they both see the value in the migration
[10:20] but the question is how do you make the migration itself tractable for Bob these risks are real uh but they're not impossible to solve. So what the team needs is Agentic
[10:33] Lakeridge. So, Agenda link bridge is our new suite of AI powered tools that address every step of the migration. They map to the four pillars that we've been discussing assessment, code conversion, data migration,
[10:46] reconciliation, and all this is orchestrated by Genie code to make it easy and simple to automate and orchestrate. So, I'll walk through a lot of these steps and I'll use again these characters as our examples. So, start
[10:58] with assessment. Lakebridge automatically discovers and invenaries everything in your legacy source system. So what you're seeing here is actually one of the reports that we automatically generate which gives you a full idea of your legacy estate.
[11:11] This will be your procedures, views, tables, really everything you can have in a legacy data warehouse. And we generate this both for SQL and coming soon ETL uh sources as well. So this
[11:23] removes a lot of the manual discovery that was giving Bob some concern. At the same time, we also generate usage reports so you can understand actually what things are being used in your existing system.
[11:39] But isn't just stop at inventorying and profiling. It's really comes down to prioritization. So for each of the various things in your system, so the various scripts, we also compute a complexity score. What this allow you to do is understand what things would be
[11:51] easier or hard to migrate and get you a feel for the level of effort that's going to be required to do the migration. So you can see on the one hand a distribution of things that can be largely automated versus things that were going to need more human review.
[12:08] One of the more powerful features uh that's available is lineage. So all of the concerns that Bob had around mapping dependencies and figuring out what store procedures ripped or which tables, all of that gets automated within
[12:20] Lakebridge. So you can figure out which objects need to be migrated together and ultimately come up with clusters or batches that you can use for wave planning. So if you remember that stored proc that was nightly load or the the
[12:33] ghost objects in the previous slide, all that gets demystified through this lineage graph. Okay, so bringing it back to our protagonists Angela and Bob, they're going through the documentation. and
[12:46] they're seeing all these assessment capabilities and they're really starting to put together the puzzle of how you can put together a migration plan. So what you're seeing here is a sample lineage graph and then we overlaid that with a lot of the different reports and
[12:59] statistics that we were mentioning before. So things like your usage uh as well as your complexity and then from there you can do work like find what the lowhanging fruit would be. So Angela sees hey this sales cluster is perfectly
[13:13] isolated. It's also has high usage, so it's high business priority, but at the same time, it's not particularly complex to move. So, it seems like a great place to start to show value to the rest of the organization. At the same time, you
[13:26] can see things that probably aren't being used that you can probably remove from the scope of the migration. So, Bob sees here, hey, this store procedure actually isn't being used. Maybe it can be deprecated and again, save us some
[13:38] time. Okay, so the team has a really good feel for assessment. Now let's talk about code conversion. This is an area that historically has been really challenging
[13:50] for customers but also an area that we made a lot of recent investments in. So our solution is the agentic code converter which is right now in private preview. This is all powered by Genieode
[14:03] and what the agent converter does is it uses an agentic loop to actually convert your code. So it converts the code, it runs various checks and then the agent reasons and understands ways that it can
[14:15] improve the code before you actually even see the output. So ultimately you're getting a result that's validated for syntax. So this can run on data bricks as well as semantic intent to make sure that ultimately what you're producing here has the same business
[14:27] logic maintained as what you had in the source system. It supports a variety of different SQL and ETL sources, some of which you're seeing on the slide, but you should contact your data bricks account person to see the full list.
[14:45] Okay, one of the coolest features about this is custom skills. So, we're actually going to allow folks to customize the results of the conversion. So if you have a specific ETL pattern that's approved or um you want to rename
[14:59] columns, you can just submit an MD file, upload that and then that will impact the actual results of your conversion. So again, really easy way to customize just through plain text.
[15:15] So what you're seeing here is an example output of a SQL to SQL translation. And what makes a lift and shift like in this case appealing is that datab bricks supports the full suite of enterprise SQL features. I'm going call out three things on this slide that are now G
[15:28] multi-statement transactions, store procedures, and temp tables. These are important because these are features that typically together are most commonly found within your ETL patterns in a legacy data warehouse and the ones
[15:40] that historically can make a SQL SQL migration particularly difficult. All of these are now GA along with a whole long list of other features, geospatial functions, variant data type, which
[15:53] again have a full suite of SQL capabilities all built into that data bricks lighthouse. As an alternative, if you are looking for instead of SQL, you want to land in
[16:05] Pispark, maybe because your team wants to modulize a store procedure or you just have a preference that also will support as a particular dialect. Okay, so let's return back to our protagonist. At this point, they've gone
[16:18] through the documentation. They have a full view of assessment, code conversion, and they have a highlight understanding of how Gent Lake bridge will work. Uh, but they're not going to know for certain until they actually run a PC. So, what they've done is actually
[16:31] pull together a subset of actual code that they want to run through the code conversion tool, the agent converter. So, I'm going to hand this over to Gina, who's our in-house Angela, who will run the PC for us. >> Okay. We're going to attempt to do this
[16:46] live. So, let's try that.
[17:01] All right. So, they have selected the subset of code that they want to run through the PC. Then what they want to do is they come into their workspace. They will open a new migration project.
[17:13] Um they'll give it a name and they'll select the source system. In their case is SQL server. So they'll do TSQL U target. Yes, they want to stay in SQL. Um they'll specify
[17:25] where they want their project to go and they'll create the project. Uh at this point they're ready to start adding files uh to their PC. So they can add either work
[17:40] um files that they have on their workspace or they can connect directly to GitHub and retrieve a subset of the files from their um from the repo for um Expediency. Um let's go and look at
[17:52] their ongoing migration project um which is uh in here. So as part of this you can see that there's already some things that have been going on as part of their PC. Um
[18:04] there's a new file that we need to add that was just added to the PC scope. So let's add it here. Um but let's let's look at the two um initial um objectives
[18:18] for this PC. The first one is to detract to determine whether the assessment fits their needs um to debunk this archaeology project. So you see that there's this lineage tab here um where
[18:30] they can see well you can barely see that because that's very small um but if you zoom in um you can see that you have the full lineage of your the files that you have selected for your migration project along with the tables that they
[18:42] affect um and you can toggle between the two. So this this gives you an overall view of of the overall project. Um, if we go in here, I'm going to kick off the migration of this file and then I'm
[18:56] going to show you some goodies on this page. So, while that's going, um, and I'll come back to what's happening here on the right hand side in a second. But if we open the information for this file, uh, we can see things like the
[19:09] complexity of this file. In this case, it's a very trivial. It's very small, only 27 lines. It's low complexity. Uh, you can see details such as what are the common, what are all the function calls that are happening in that file. you get a lot of rich details around the file.
[19:22] In this case, again, very simplistic, not a lot here, but for bigger files, you'll see that there's more. Um, if we look, for example, at files that have already been converted, uh, in a previous iteration, for example, if we
[19:34] look at this one, um, you see not just the complexity, um, the functions, the tables that it reads, um, you could potentially see the lineage and that will take you take it to the lineage page, but you can see what happened
[19:46] during the actual conversion. uh what are the changes that were applied um when when the file was converted and this was a successful file. If we look at one that is marked as needs review um
[19:59] let me open that. I don't know how readable that is. It looks pretty small. So let's zoom in a little bit. So you have the change everything that was all the changes that were applied but you also have the list of the things that need a review. In this case it's fairly
[20:11] trivial. It's just a print statement that was removed but you would see everything that needs your attention here. Um another important thing to call out is that um on the output so your input files remain um remain untouched
[20:26] so that you have that always but when we look at the output of the file um we have this diff view of the code. So to help you form a mental map of what the code looked like before and what it was
[20:39] converted to. So you get to see that side by side and at the end you get to accept uh when you're ready to move forward with this file in the way it's written. As Jonathan was mentioning before, um something that is really
[20:51] powerful around having Genie code powering these migrations is that on the right hand side, what you see is that we have created custom um custom skills tailored to really teach Genie code
[21:04] around the differences of what does uh how do you express whatever you have on SQL server and all in all these uh sources into data brick specific code. Um, but you can also add your own
[21:17] flavor. Um, so the custom skills. So if you wanted to do that, um, you would come in here under settings and add your instructions, uh, into the skills files. And this can be as simple as I want to
[21:29] make sure that this catalog that was named PRD in my source system. Now it's called prod on data bricks. But it can be things that are a lot more involved where you have tooling and things happening under the hood that are tailored to your organization. And again
[21:41] you can choose that they these custom skills are applied at the overall project level per file um or however however better fits your needs. Um so at
[21:53] this point um we are ready to keep going with the next part of the PLC. So let me >> send that back to the other >> yeah switch it back over.
[22:15] >> There we go. >> And there we go. Okay. Great. So, Angela, let's see if this switched. This isn't working.
[22:27] I'll just move from here. >> Okay. >> Okay. So, moving forward, uh, they ran the PC as you saw there. some successful conversion results. Uh and ultimately now they have a really good feel for the
[22:40] assessment. They saw the lineage graph. They saw the capabilities that exist to help them build a migration plan. They could see the full DAG in their source system and how they can move. They also get good conversion results. They feel comfortable that hey, if we were to
[22:52] scale up this PC to the broader batches that you have in that lineage graph, you could easily get really good conversion results and really simplify the conversion from their legacy TSQL to data bricks. So there's two points that
[23:04] still remain though. There's data migration and reconciliation. Bob had concerns with both of these steps. Okay, this works again. Okay, so for data migration, the solution really is
[23:17] LFlow connect. So if you're not familiar, LakeFlow Connect is our data ingestion tool. It has a whole slew of connectors that you can pull from. Here listed are various data warehouses that we can actually ingest data from that
[23:30] can help you in your migration. There's two types of connectors uh with link flow connect. There's both CDC connectors. So this is going to be incremental processing. So you only really bring in what changes and we also
[23:42] have querybased connectors which can do things at a full snapshot level. Both are managed. So there's no custom code that you need to write in order to make all this work. And the setup is extremely simple. We'll
[23:55] see on the next slide actually what that flow looks like. But you can with LakeFlow Connect there's a pointand-click user experience as well as all these capabilities available via API.
[24:10] Okay. So what does Angeline need to do to actually make all this work? So you're seeing here is the really simple user journey to using LakeFlow connect to ingest from SQL server. So the first thing you do create a connection to SQL
[24:22] server. From there you can click you can select the various tables that you want to have within the scope of the migration. So if you remember we just did an assessment we figured out a cluster that we wanted to focus on the low hanging fruit. So the high usage low
[24:36] complexity those would be the ones you want to start with for actually moving data from SQL server over to uh data bricks. And then from there lightflow connect takes it. It will do CDC replication for SQL server and then you
[24:49] can see some continuous monitoring to make sure nothing is left behind or anything falls through the cracks. So closing out data migration. Now we have the last step. We've converted
[25:01] code. We've moved data. How do you know everything actually moved correctly? And this is the thing that gave Bob the biggest headache. Uh because you remember the SQL server example of having to debug these mismatches. What can we do here? So, Lakebridge has a
[25:14] dedicated capability and I'll walk you through that as well. The solution here is Lakebridge reconciler. So, Lakebridge reconciler allows you to compare a source and target table and verify that everything moved correctly. So, what you do is you
[25:27] configure a source and it data bricks counterpart and then from there you can determine if other things definitively match.
[25:39] Along with the actual data diff computation, we also provide dashboards. So you can see how match rates are evolving over time. So you can see which tables are already fully validated and which ones still see have gaps. You can track that through the course of the overall migration. This is all comes out
[25:52] of box. Lake bridge runs a variety of different comparisons and you can configure Lakebridgeidge to do all these capabilities. First you have types. So
[26:04] you can look at whether the schemas actually match. You can look if primary keys actually exist and you can make sure the data types are matching across the source and target tables. You can also configure the various form factors that you use the data diffing for. So
[26:18] you can do full rowle comparisons. You can do aggregations. You can also put define an acceptable tolerance range saying hey as long as we're close enough we're good. And you also can define rules because not everything that you're
[26:31] going to encounter is not necessarily a bug. So you may want to configure things like that to make sure that as a team you discover what things you're comfortable being different and then you can document them in order to move forward the migration. Okay, so back to our protagonist. Um
[26:46] have Guinea again help me out in terms of walking through what reconciliation looks like and some new features we're building out. >> All right, so by this point they have already converted their code. They have moved some of their data using the CDC
[27:00] um lakeflow connect um and they have deployed lake bridge reconcile. I'm not going to bore you doing all of that. So they've done all of that. Um and they are um they have run reconciliation for
[27:12] a few days. They've had these parallel runs running and now they're ready to go and take a look to see what's been happening um so far. So let's go and take a look.
[27:33] So this is the dashboard um that is generated and updated on every run of labbridge reconcile. So essentially what happens during a reconciliation run is that Lakebridge goes through a specific
[27:46] set of tables that you select on your source system, a specific set on data bricks and it matches them um and collects information on on the various um features that Jonathan mentioned before on schema on rows on columns uh
[27:59] however you have specified your reconciliation to happen and then all of that gets um refreshed on this dashboard um on every run. So we can see at the top that on the latest run most of the
[28:11] tables were successful um except this one that is failing. Uh you can see details at the run level uh at every job run of reconcile that has been running and then you have a summary overall how
[28:24] many runs have there been how many have been successful um at the table level it looks like there is one table in in particular that is giving us a lot of headaches uh which is this shipments table. So we'll have to take a look at
[28:36] that. Um and we can do that by looking in this in the details uh for that specific table. So if we go and we take a look here, we can dive in and understand. Okay, so we see that there
[28:49] are some mismatched records, some missing in source, some missing in target. Um we see that when we look at the overall schema when we do a comparison, um there is there is an issue with the way the schema was
[29:01] converted on on data bricks. um we see details around which columns have the biggest issues on how many runs etc. But we know uh from having built Lake Bridge
[29:13] over the last uh two years that just finding the differences between these two tables is not ne is not um all that there's needed. You also need to understand why there's an issue and
[29:25] that's usually where the rubber hits the road um because it's it's very very difficult to find where that issue even came from. So, Angela finds this Ask Genie button here at the bottom of the
[29:37] Oh, that you can see. Um, that's tricky. Believe me when I say that there's a button down here. Let me see if can I do There you go. Uh, okay. So, on every dashboard, you have this ask Genie
[29:49] button at the bottom here. I'm
[30:01] Genieode actually has enough context and I will tell you now in a second why to go and do a pretty comprehensive analysis and it gets to a pretty sensible set of recommended actions to understand why there's been an issue
[30:14] with that table. And the reason why Genieode is able to provide you with this context is because when we run reconciliation we store all the metadata for all the runs. We collect all of that
[30:26] into Unity catalog tables that Geniode then has access to query and understand and intelligently assess why there's an issue. So it's all based on the data that you're giving it and and that
[30:38] context that you're providing to it. >> Okay, great. >> So that's Rexilian action >> and I'm going to change that the back.
[30:59] Okay, cool. So, we completed reconciliation and always makes you do one of these. Okay, great. So, there you have it. Here's the full picture. So you went
[31:12] from four risks that Bob originally brought up earlier in the presentation and you can see step by step how lake bridge solves and provides a fully agentic migration. So you have assessment, you have automated migration
[31:25] planning, AI powered code conversion, seamless data movement with layflow connect and then with reconciliation, AI powered data validation and debugging
[31:40] and this is all in just theoretical. So the number you're having here is actually the number of customers that have used link bridge to migrate to data bricks in the last year since we launched lake brbridge at data summit and you can see here actually a quote from a customer who used data brick uh
[31:53] used lake bridge successfully to migrate their legacy store procedures to spark declarative pipelines cutting down a lot of the manual work that you typically see in a migration. And we don't just stop at tooling. Uh we
[32:06] also provide an ecosystem of partners that can help you along the way for the migration. At this data summer, we're actually launching the migrate and modernize program uh which is a program to connect customers to specialized partners who have experience with given
[32:20] source systems. So whether or not you're migrating from SQL Server or Terod Data or Snowflake, we have a partner who has done those migrations before that can help you along the way. And this has 20 specialized partners in this first
[32:33] cohort. We're all global coverage across global uh SIS as well as RSIs. Okay, so we bring it back to our two protagonists. Where do they end up? Uh
[32:46] so they have the right tool, they have the right partner that executed the migration and this is their new architecture built on an open lakehouse. You have the same sources on the lefth hand side, your ERP, CRM, CSV, all that
[32:59] comes in through LakeFlow connect and then it lands in open tables uh your bronze m uh your medallion structure all governed through unity catalog and you have a data warehouse that has all types
[33:12] of capabilities for serving and all types of opportunities. You're seeing not just your original PowerBI and SSRI as you had before. You have AI, BI, you have connectors to uh Excel and Google
[33:24] Sheets, you have connectors to build custom applications using any real language you'd like, as well as access to AI and agents, which you have things like Genie uh and some of the developer tools that we make available as well.
[33:36] So, regardless of the persona, you can build with AI right directly on your on your warehouse, all built in. Okay, and that's it. Uh thanks again for um spending time with us. We'd love to
[33:50] talk. We'll take questions out in the back and please if you could also please fill out the survey. You can follow uh the directions in Dave Brooks event app. Thanks.

Learn more about the Databricks Data and AI platform.

The information provided herein is for general informational purposes only and may not reflect the most current product capabilities or configurations.