Migrating from Oracle to Databricks Lakehouse

Summary

This video presents proven migration strategies for moving legacy Oracle data warehouses to the Databricks Data and AI platform, covering why lift-and-shift fails at enterprise scale and how to inventory and classify use cases as atomic migration units.
Two methodologies are compared—ETL-first versus BI-first migration approaches—and tooling is demonstrated including Lakeflow Connect for ingestion and Lakebridge for AI-assisted conversion of complex PL/SQL code into Spark Declarative Pipelines.
A new agentic code conversion capability accelerates the most complex transformations, and common Oracle-specific migration traps such as sequences, external procedures, and custom data types are addressed with practical remediation guidance.

Migrating from Oracle to Databricks Lakehouse

Migrating your legacy Oracle data warehouse to Databricks can accelerate your data modernization journey. In this video, learn the top strategies for completing this data migration. We will cover data type conversion, basic to complex code conversions, validation, and reconciliation best practices. Discover how to proceed with data migration by leveraging Lakeflow Connect and code migration with Lakebridge to convert complex ETL pipelines to Databricks Spark Declarative Pipelines. See before and after architectures of customers who have migrated, and learn about the benefits they realized.
Talk By: George Komninos, Migrations Architect, Databricks ; Laurent Léturgez, Data warehouse migration Specialist, Databricks ;

Chapters

FAQs

Why does lift-and-shift migration fail for Oracle data warehouses?

Oracle data warehouses are often in place for 20 to 30 years and contain deeply embedded use cases, complex interdependencies, stored procedures, and custom data types that do not translate directly. Attempting a wholesale lift-and-shift without inventorying and classifying use cases as atomic migration units leads to runaway costs and technical debt on the new platform.

What is the difference between ETL-first and BI-first Oracle migration approaches?

The ETL-first approach migrates ingestion, integration, and serving layers before moving BI tools, ensuring data is fully available in Databricks before business users switch their reports. The BI-first approach moves dashboards and analytics earlier and uses data federation through Databricks to read from Oracle in the interim, providing business continuity while the full migration proceeds.

How does Lakebridge help convert Oracle PL/SQL to Spark Declarative Pipelines?

Lakebridge analyzes Oracle PL/SQL code and uses AI assistance to convert it into equivalent Spark-based workloads compatible with Lakeflow Spark Declarative Pipelines. The demo in this video shows a live conversion from a PL/SQL procedure to a declarative pipeline definition, and a new agentic code conversion capability handles complex transformations that rule-based tools cannot address.

What are the most common Oracle migration traps to avoid?

The speakers identify sequences, external procedures, and custom user-defined types as the most common Oracle-specific constructs requiring special handling during migration. These features have no direct Databricks equivalent and must be refactored rather than converted, making early identification during the use-case inventory phase critical.

Full transcript

[00:09] Uh so my name is Laur uh I work at the data bricks for almost five years now as a product specialist uh and uh for the EMA region um I'm French uh and uh I'm working in uh everything that covers
[00:23] data was migrations and prior to data bricks I worked 20 years with Oracle database so that's a system that I know a little bit and today with me I I will present with George. George over to you.
[00:35] >> Hi everyone. I'm George. Uh I'm a migrations architects and I lead the EDW migrations arm of professional services at data bricks for IMIA. So I'm involved in most of the big migrations we have from uh onrem and cloud data warehouses
[00:48] to uh data bricks. I work closely with Lauran and been with data bricks for almost three years now. uh not much Oracle experience but together with Lauran we'll put together this session to discuss how we address migrations
[01:01] both from Oracle perspective specifically but also how we try to unify them and make them all u similar. All right. So uh first of all uh in this
[01:13] session we will present you a couple of slides on what is probably something that is really really important is to uh have a a strong uh migration strategy in
[01:25] place and we will explain you at a high level uh how we can uh uh organize and and set up this uh this strategy. So migrating an Oracle database an Oracle data w is something that is huge to to
[01:40] do. Why? Because Oracle and all of the data warehouse that uh are uh installed in at our customers are usually things that are in place for more than 20 30
[01:52] years sometimes. And so uh it's huge. It's well in place and if you want to uh decommission that to datab bricks uh you will have to consider it not only as a big database to migrate but something
[02:05] that lives within this big database. And we will uh use this uh various uh uh um uh items in this database to be uh migrated off uh our account and then to
[02:17] datab bricks. And so um the first thing to consider is to uh identify which which are the the use case that you have within your data warehouse. Okay, it's not specific to Oracle. It's it's for
[02:31] all the data warehouse in the world. you have a set of use case and so you have to inventory uh to make an inventory of this all of this use case because they will be considered as a atomic unit of what you will migrate of Oracle to datab
[02:44] bricks and then um you have to establish what are the the the dependencies between all of these use case because in normal case you have multiple of uh this use case in the data warehouse some of
[02:58] them are independent some of them are interconnected they have some dependencies and So establishing the list the the the the dependencies in this between this use case is very important because it will give you the
[03:10] first idea of what will be the first uh use case to migrate and then what will be the next one and for some of them who are which are u independent it's an opportunity for you to consider this use
[03:23] case to be migrated in parallel and then reduce the timelines uh of the migration. So it will help you to prioritize the migration. The second thing to operate is uh to consider um if you have uh if
[03:38] you want to modernize your environment and you want to bring more capabilities, you will have to uh consider new use case. But for the the the ones that are currently implemented within your data warehouse, you will
[03:50] have to look at them and making a second level inventory that consists in uh uh listing all the the technical artifacts that are related to this use case. And when I say technical artifacts
[04:04] for every data you have uh ETL processes. So these ETL processes can be managed internally using store procedures uh PL/SQL packages um or
[04:16] externally using third party ETL. It could be Informatica, it could be data stage, could be ODI, it could be whatever you want and a third party ETL. Everything that is uh an ETL process that is linked to this uh business uh
[04:28] case has to be linked to and the other things to consider is the database artifacts. Uh for every use case you have database artifacts that are linked to this use case. Okay, it could be of course tables, materials, views,
[04:40] indexes, views, uh data types also because in Oracle you have standard data types uh bar chart numbers and so on. But you have also uh more complex data
[04:52] types, userdefined data types, for example, for the most complex of them. And these ones are a little bit harder to to to migrate to databicks. Um if you use uh stored procedures, if you use uh
[05:05] packages, if you use this uh evil external procedures in Oracle uh and we will cover that as after uh it's really important to identify them early in the
[05:17] process because it they will help doing this it will help us to uh uh establishing the the complexity of the mig of the use case to be migrated. Okay. And when I say complexity, it's
[05:30] code complexity. Uh it's it's um data complexity. We have seen that with user defined data types. And uh with data bricks, you can assess that by using legbridge. And uh the the component of
[05:43] leg brbridge that could be used to evaluate the complexity of these uh tech technical artifacts is legridge analyzer. So it will give you uh an idea of the complexity. And when I say complexity, it's the the risk of slipage
[05:56] for example to migrate a complex uh uh code uh sample to data bricks because multiple reasons. We will see that uh in the coming in the next slide.
[06:09] So uh as Lauran said it's very key and very important and one of the main things that customers are asking us from professional service at data bricks when they start this big data warehouse migration. Um
[06:21] it looks daunting when you see we have a system that has been put together and has been used and evolved within years and years and developers have put it have started working on it 20 years ago and they may have left an organization. So we don't know where to start from.
[06:34] That's one of the things that it's very uh key and that's one of the things that lots of customers struggle a lot. We have kind of systematicized this approach. That's not really a word but
[06:46] anyways um to make it systematic anyways uh and here what we're trying to measure is the value that the customer will get from a specific use case uh and the
[07:00] feibility that it will take. So basically what we're trying to optimize is uh on on those two uh metrics uh we have some categorical uh parameters we look at. So we want important data sets,
[07:13] important tables to uh be prioritized if those are too big and if we are talking about uh the first use case we want it to be shortening delivery. So we would take a slice of those important tables.
[07:25] So all organizations have customers or most organizations have customers. Most have like customers transactions or activity or something like that. They have products. So get a slice of those important data sets in uh in your first
[07:37] this first use case. um look into what could be uh a key driver with regards to momentum. So if you go to your leadership and you show this dashboard that your leadership looks into every
[07:49] day and uh focus a use case around that that is a good way to go with and then the extra cherry on top would be if you can by uh addressing
[08:01] this first use case to um enable something that's not possible to do in this original in the in the legacy system. So after I have done my dashboard or my reports or my breakdowns
[08:13] of how my customers um interact with uh our business, if I can then do something like uh predictive analytics uh anomaly detection something that was not
[08:25] possible to do in the legacy system uh that is a perfect first use case to do and this is something that we can work backwards from and address that and then if we do this right we should identify all the different complexities and be
[08:37] able to uh make a good uh migration plan. >> Thank you George. So uh as I was saying initially uh moving or the big Oracle data wars as a single technical unit to
[08:50] data bricks is not the the right thing to do. You have to split it into smaller chunks and these chunks are considered as being the the use case that lives within your data wells. Quick remark on that. uh sometimes uh we have customers
[09:05] said hey I can identify the use case but usually you know they are interconnected within a single business domain and that's totally fine if you want to migrate your business domain as a single unit you can do that the only uh mistake
[09:20] that you uh have to avoid is to consider the whole database to be migrated as a whole um and so once you have defined your priorities once you have defined the the the dependencies between the use case their complexity and so on and so
[09:33] you have a rough idea of what could be the plan uh to to to migrate of uh Oracle to database you have to establish a list of priorities and this uh priority uh use case will be uh yeah P 0
[09:47] P1 P2 and so on and doing that will help you to uh deliver first of all to deliver the highest value for your use case because you know and because of what George presented you know what are
[09:59] the the the use case that will deliver the biggest value for your business. Okay, so this will definitely help you to uh to to to bring the more interesting for you uh early um you will
[10:13] uh minimize the risk and uh you will the most important thing is you will minimize the time to migrate. Why? because beyond that uh you will apply to every use case that you will migrate of
[10:26] u Oracle to datab bricks uh um a methodology that is always the same. Okay. And so from something that was a little bit unclear you will create a kind of industry process of the the
[10:39] migration and thus reducing the the timelines. So the question is which migration methodology to choose to apply. Um so at databicks we are uh we recommend two of
[10:53] them okay and we will see uh to those two different methodologies but the choice between one of them has to be uh done depending on multiple uh uh factors
[11:06] and the the the drivers that uh George presented is something that will help you to to choose one or the other one. So when I said uh what I uh as I said uh
[11:20] we have uh two different methodologies. We named them ETL first and BI first because um ETL first yes we will migrate the ETL part first and BI first we will
[11:34] migrate the serving layer first. Um the the the migration drivers are different depending on the the methodology. If you uh for example uh you have a high TCO pressure and you want to uh be uh you
[11:49] want to work first on DTL pipeline which are usually the the the most complex part to be migrated uh in that case you will choose that one. Uh on the other hand uh if you for example uh you are
[12:02] very interested to use uh natural language uh uh uh quering uh so genie uh to uh on your um data mod for example you will uh you will need to migrate
[12:15] this data mod first and then open them up to the to the business user to make them use genie on top of this uh data sets. um or if you want to implement uh AI based uh workloads uh to forecast uh
[12:29] key indicators. So in that case you will choose BI first. So you will migrate your uh uh serving layer first and then you will work afterwards on the the injection and the ETL part.
[12:47] Um in terms of migration approach uh you if you're interested on by uh more detail on this uh uh methodology we wrote a couple of months ago with George and people from datab bricks a blog post so feel free to to to scan this code um
[13:00] but if you Google it you will find it no problem on that so uh in detail what is the injection uh and ETL first what we've initially
[13:13] called the ETL first and what is the BI first? So the injection and ETL first is the one that will um that is the one that is usually considered by our customer because it's very uh straightforward. It's very natural to to
[13:26] to use this u migration approach. But um the the main uh uh downside that we have for this uh approach is that you will uh be focused on the the the most complex
[13:40] part but the less visible part for your business first. Okay. And so as like migration can take some time um the results of your work will not be uh visible uh early to to the to the the
[13:53] cuit for example in your in your organization. So um if we consider for example um at the top of this slide a data w made of three different layers a staging area an
[14:05] integration layer a serving layer. So staging area you have your operational data source that lands into this uh into this area. You consolidate them into a data model that lives within the integration layer and then you export
[14:18] them uh to your business layers usually by uh business users usually by uh uh implementing a set of data mods. So it's just an example here. Uh things can differ but it's a it's just an example.
[14:32] The the injection and ETL first methodology consists in first of all you will open up a new branch of injection into data bricks. Okay. So you your operational data source will uh bring
[14:44] the data will continue to bring the data into Oracle and you will open up a new branch of ignition into data bricks into within the the bronze layer. Once it's landed into this uh bronze layer, you
[14:56] will uh in import the the historical data that lives within this uh integration layer on on Oracle as an initial load into the bronze layer. And once you have the data for this specific
[15:09] use case, because this is something that you will apply to a specific use case, you will then recreate the integration layer that you have not on Oracle but on data bricks by migrating the ETL process
[15:23] that uh usually uh lives somewhere here. Okay. and you will migrate it to here on datab bricks using a
[15:35] different language uh different capabilities. Once you have recreated your integration layer, you can recreate your data mod by recreating the the materialized view the business logic that is used on Oracle and you will
[15:48] reproduce that uh on data bricks again using a different uh language and different capabilities. And once uh that is done you will uh open up the UAT uh
[16:00] to your user saying okay do we have the same business consistency do we have the same uh logic and um all the things that you have to validate and having a validation plan is also something really
[16:13] really important to be sure that once you have validated the the accuracy of the the numbers the the floating point numbers uh the the business consistency and so on you are auto you you all agree
[16:26] on the fact that we can move on to the next use case and this one can be considered as done and then once it's validated your phase is validated you can cut off the initial uh use case in
[16:39] Oracle. So this one is very natural, very straight. You put you open up a new branch, you recreate everything step by step and then at the end uh you will have the same consistency. The other one
[16:52] is the BI first and it's usually driven by the business value. But I will let George present this one. >> Sure. Thanks Dan. So basically uh BI first word means we're migrating the consumer first. We want to expose the
[17:06] users that we have already to the new platform as early as possible. Uh that has the big benefit as uh we discussed already that uh users see the actual uh benefit of uh the new platform as early
[17:20] as possible but it will give you this false sense of completeness. So they would think that the migration is complete because they can use the data. Uh but uh that's uh that's not really the case. So I will go through this very quickly. Again we have a blog that describes this in big detail. So uh you
[17:34] replicate the data from the data side from the serving layer to the new platform. There are multiple ways to do that. Uh you replicate the data both to your gold layer if we're speaking about metal architectures uh but also you're
[17:46] replicating it in a one-off copy uh the data warehouse layer integration layer of the legacy data warehouse to the bronze. At some point what you want to do is to repoint your sources from the
[17:58] legacy platform to data bricks to the bronze layer. You build your ETL to populate your silver layer and from there you do the same for data M. Uh again going through this very quickly I don't know Luran if you want to add
[18:10] anything like it's um kind of the reverse what you described before starting from the uh end of the process from the consumption once you see that slowly slowly the users can use uh the
[18:22] new platform and slowly slowly uh legacy use cases are decommissioned and no longer used by the uh by your business owners. You can then completely switch off the your legacy completely decommission it uh and use your migrated
[18:36] uh warehouse uh as as your main as your pod. Right. So next we have put together a couple of demos to show some of those um
[18:48] uh components how we would do them uh in a somewhat of an accelerated way. So we have put together an Oracle environment. Um we have set it up it's it's on cloud. AWS RDS or Amazon RDS. Uh they have we
[19:04] have three layers uh staging, integration and data M. Uh between them we have pipelines that like a pipeline from staging generates integration and same way uh another one creates data
[19:17] marts. Uh those pipelines are basically packages oracle packages and data marts have some tables have some views. Uh so uh we will look into both.
[19:30] Um Lighthouse Federation is a great uh feature, a great offering that you can use to very very quickly expose your legacy data from your source system to
[19:44] datab bricks. And again this has a downside that it gives you a bit of a false sense of completeness because you can query the data and it looks like it's data bricks but in reality the underlying technology is your existing
[19:56] source technology but it's something you can put together very quickly uh and very very efficiently you can have data it can be used to join data sets from what you already have in Oracle uh and
[20:08] what you already have in data bricks but is some that's still in Oracle you can ingest new data sources uh there are many many different ways you can use federation. Uh so in this scenario what
[20:20] we will do we will try to get our data match data uh that reside in Oracle uh and federate them so they can be accessible to uh data bricks and the other thing you can do which we will try
[20:32] to do here is to ingest those initial data sets using federation itself. So let's see >> maybe uh one comment on that using house
[20:44] federation is uh can can be used in this specific context because usually it it can be used for >> uh data sets which are not huge to be migrated and usually data months are
[20:57] couple of gigabytes that you can migrate very quickly and you can refresh on a daily basis on datab bricks >> right so the other problem we have is I'm not very good at coding. So I will
[21:09] use Genie to help me code. Let's see how this goes. Uh so first what I need to do what I try to do in the beginning is to create a connection between Oracle and uh data bricks. So I will ask Genie uh
[21:23] create is this visible? Shall I zoom in? >> Yep. >> Yeah. connection to Oracle in SQL. So let's see what we
[21:39] get out of this. Okay, this looks okay.
[21:51] I am asking for your patience because we're using Lauran's laptop and Lauran's scrolling is backwards for some reason.
[22:04] Uh so I will replace this with my host my port uh service name
[22:24] and password. Uh I don't think I need to say that we should not hardcode passwords but >> for that for example you can use >> someone else's job to fix that >> you can use database p for that >> okay
[22:36] >> uh right this looks okay I think
[22:50] it did it correct this time
[23:02] but that was not enough for us. So we decided to add agents as an extra liability. Every time I prepared this demo, it instead of service name, it used database here. So I wanted to make the point of
[23:16] see agents are not great blah blah blah. I need to change database service name. But this time it looks like it did it correctly. So it learns >> someone told them. >> Yes, someone told them. Uh so the
[23:29] federated connection is done here. Okay, let's see uh what happens next. So what I want to do now is create a forign catalog
[23:42] uh based on the above connection.
[23:57] Uh okay. Connection name is from above. Let's see what happens. Connection name is not defined. Did we not define connection name?
[24:27] All right, I'll do some more hard coding then, I guess.
[25:01] >> Sorry
[25:53] >> Uh connection needs to be connection. Yes.
[26:47] Okay, maybe it did.
[27:21] Yeah, looks straightforward. Let's run
[27:33] And these look like the schemas we had on Oracle. >> If you used to work on Oracle, you probably identified a couple of non schemas
[27:53] Let's see if we have if we can get some data out of it again. Very nice, very easy. And this is the schemas
[28:10] and this is some data. Always makes me happy when some connection works and I can see data that exists somewhere. So, if I go now to uh what was our catalog's name again?
[28:28] Retail Mart. If I look for retail mart here, um is this one?
[29:04] here's really smart and if I go to any table here which I just made available like you can see here that I'm not getting much information because this is not data that's owned by data bricks. This data that's stored in uh Oracle. So
[29:18] this way I can just show to my consumers that the data that exists in Oracle can is queriable via datab bricks. The other thing I can now do hopefully if the agent allows me to uh what I want to do
[29:33] is now create uh a new catalog and a new schema on datab bricks. So create catalog uh retail lakehouse
[29:45] uh schema gold and uh create table as select for all the tables in the above schema to the newly
[30:03] generated schema. Okay, it's not great English, but hopefully the agent will agree that looks probably correct.
[30:15] Uh I will accept and run. So basically what I'm doing here is uh this code after generating a new catalog
[30:29] which will be the catalog to which we will migrate I'm creating a schema. So I'm creating gold and I am creating copies of those
[30:43] tables uh in a database. Those would be actual delta tables. And if I go here in here, this seems like it runs successfully. So if I refresh my catalog here
[30:56] and I go look for
[31:14] this one. And now show me some
[31:41] All right. So, it gives a character that it does not like
[32:28] So this is the backup code that we would use for this. But then I should change the names of cut name is
[34:11] So, leg bridge is a tool that will automate code conversion. Um and uh in this uh specific um uh scenario we can use it for example here if we want to recreate the table that lives within the
[34:23] silver layer um by analyzing the the scripts that has been used on our accordion to create this schema and so for that um
[34:36] we can use language for that. So here is the desktop app that is currently in preview private or public I don't remember exactly but will be the future. So first of all I have to select um the
[34:51] source dialect and you can see it populates automatically the the data target which is DBSQL and the transpiler that will be used in the background. Um and here I will have to uh provide
[35:12] the location of my file. So as you can see here in this uh uh folder I have a script that creates the integration schema. And so if I put
[35:24] the folder here and the output folder here I can start the conversion
[35:36] and so will stop the processing. I hope I will be more lucky than you.
[36:05] right? So it seems that it works well. So the file is converted. But I will what I wanted to show you is this one come here. Okay. So if I go to my folder dis local input and I open the oops the
[36:22] scripts as you can see here there is some uh table details that can be uh that will be my review uh but something that is oops also uh really interesting
[36:34] is at the end of the file we have a set of creat create sequence and sequence are not
[36:46] they they do not exist on data bricks. We have identity columns that can uh work around but we don't have as of today it's in the plan to have sequences objects and so uh the the
[37:03] leg bridge converter if we look at the results file as you can see he converted all the table detail uh into a data table because you can see that there is a
[37:15] table properties uh the the data types has been uh converted and so on. But if we go at the end of the scripts, we don't have any sequences created.
[37:29] Oh, I mean we have create seconds but if we execute that on data bricks they will uh generate some error and so doing that uh using the bridge show you that we can
[37:41] automate the code conversion but in some case we we will have to uh to deal with uh some uh manual conversion at the end and sequence is currently one of the example we have to review all the tables
[37:54] and generate identity columns for example or find another rack. Um
[38:07] the next the last demo is to use GI code to transpire the ETL logic. So ETL logic is a little bit complex to to to convert by using red bridge because it's usually uh you have some business logics that live within this um this uh area and for
[38:23] that uh we are we this morning we introduced the the agenting converter capabilities. So they will as of today it's in private preview so we will support uh we currently support all of this uh source platform Oracle is one of
[38:36] them and so um if you need uh if you want to know to learn more about this uh new capabilities I encourage you to attend the the tomorrow session with Gina and Jonathan they will present you
[38:49] this new capabilities but uh in order to make you wait a little bit um we recorded um a quick uh demo on that. So we will
[39:02] be uh very fast.
[39:14] as you can see here we have this schema box well you know that and we will convert this part of the of the code that live within uh PL/SQL uh package.
[39:29] So as you can see here this is the the code of this uh package. So it's package with procedure definitions uh and uh later in this uh we have the package body where we can find all the code that
[39:43] live within this uh single procedure with merge statement. We have uh some uh recursive uh cities. We have connect by we have stuff that is very common on
[39:57] Oracle and what we will do uh on the week. So we have uh connected the g repository where we can find um the this script. So the script is here available and you can see the
[40:10] same one um and what we will do we will create this new migration project. So here if you click on new of course you have to to to be involved in the private preview you have this new object which
[40:22] is called the migration project and in this migration project so you will name it because you can have multiple of them um you will then select uh the source dialect to be used so here in our case
[40:34] it's Oracle the target which is SQL SQL sorry and you will select in your workspace the the destination folder for the the execution. So here I've created
[40:48] one new folder. I select it, create it and then um I added a couple of files. So here I
[41:00] will focus only on one file that is the one that contains the the code for this PL/SQL package. And once it's uh
[41:13] added, I can click on the run button. And as you can see, it will uh spin up a new uh GI code uh session and it will create this uh prompt for you
[41:25] and in the background it will use a set of uh skills that we've developed that will help you to automate the code conversion uh and get uh better results by using the the deterministic approach
[41:37] in in the bridge. Even if though even if it's not it's still recommended to use a deterministic approach especially for tables and so on. So if I go back to the end because we are short in time um as
[41:51] you can see here the results. So at the end it will uh convert the code as you can see here. Um still needs to uh to to to do some
[42:04] manual work and you you have the details here at the end of the of the the genie code uh results. Uh and here the the problem that we have encountered
[42:16] are related to the row count function that not existing in data bricks. um and also the fact that we have sequences um that has been identified uh and used by
[42:28] the by these scripts and so it will create um an output file as you can see here is it's a language that is fully compatible with our this databicks uh
[42:41] store procedure um we have some comments that will that has been added and to show you what has been converted and it will definitely help you to to ease the
[42:53] the migration process to to use this uh which is powered in the background by agentic capabilities.
[43:06] So in order to wrap up because we are already late. Oh something that I wanted to to to add in order to to finish this uh session. uh we usually uh when we when I discuss
[43:19] with customers who are experienced Oracle guys they always told me well you don't you don't have the same capabilities as Oracle of course we don't have because we are not Oracle we
[43:31] are datab bricks but uh we have some uh features that you probably know in Oracle that have an equivalent on data bricks uh and and we try to uh put the
[43:43] most known of this uh capabilities on Oracle For example, if you use intensively the the internal scheduleuler on data bricks on the Oracle powered by the DBMS job or
[43:55] DBMS scheduleuler packages, we have like flow job to help you. Uh if you are using uh iterate genius services uh and um and the gateway on Oracle, we can uh
[44:08] make something similar by using house federation. You have all of this that exists in a different form in the bricks but we have some equivalents. Um last thing that I wanted to to to
[44:23] tell you is uh the traps to avoid. So the major traps to avoid are usually uh located in the code base that you have and essentially if you are using intensively PL/SQL to make your logic or
[44:36] something different um you all know that in Oracle uh it's supplied with set of PL/SQL sheet packages the one that usually start by DBMS CTX
[44:49] UTL and things like that and if you are intensively using that in your code it complexifies the way you to to the way you will have to migrate to database because we don't have any equivalent. So
[45:02] if you are using intensively these packages within your code, we will have to analyze the code and so on and to find an alternative or a rock current. Uh and finally uh if you are using external procedures in our core uh
[45:16] external procedures are just packages that are linked to compiled library or something like that. Um when you have this in your code uh you have to find
[45:28] the code because it is compiled. We are not able to analyze compiled code. So you must have the the code that has been used to generate this uh external procedure um to make sure that we will
[45:40] be able to to convert it into something understood by

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.