Oracle to Databricks migration for banks
The data team had heard this pitch before. Earlier attempts to move the bank’s warehouse off Oracle had failed. When we arrived, the business side expected the next one to fail too.
The bank is a major CEE bank. Its warehouse ran on Oracle, its data lake on Cloudera, and both had grown for about 20 years. The hardware was due for a refresh with a large capital bill. The AI roadmap needed data the warehouse could not feed.
What a bank’s Oracle estate looks like after 20 years
The data is the easy part. The logic is not.
Figure 1. The bank’s estate before the migration, and the target lakehouse.
| Item | Scale |
| Data on Oracle and Cloudera | 350 TB |
| Oracle PL/SQL stored procedures | 7,500+ |
| Internal data team | 100+ people, most of them Oracle specialists |
| Years of accumulated logic | about 20 |
Oracle held the warehouse. Cloudera held the data lake. Data moved between them constantly. A data virtualization layer, a legacy BI tool and a set of Excel cubes sat on top.
The business rules lived inside the stored procedures. A migration that moves the data and loses that logic fails quietly, months later, in a regulatory report.
Three options we rejected
The strategy phase compared four paths:
| Option | Assessment |
| Stay on-premise and improve step by step | Lowest disruption, highest running cost, no route to AI at scale |
| Lift-and-shift to cloud | Fast, but it copies every existing inefficiency to a new bill |
| A mix of separate cloud tools | Flexible, but integration and governance get harder |
| Databricks Lakehouse on Microsoft Azure | Chosen: one platform for warehouse, lake and AI workloads |
The target is one Databricks Lakehouse on Azure. Delta Lake stores the data in four layers: raw, base, enriched and curated. Power BI replaces the legacy BI tools and the cubes. Collibra and Unity Catalog carry the governance.
Why standard tools could not convert the PL/SQL
Standard conversion tools could not handle the complexity of 20 years of PL/SQL at this bank.
So we built our own converters in Python. They parse the Oracle procedures and convert them to Databricks-compatible code. A pilot tested them on three scopes:
- stored procedures
- ETL components
- data exports
Three mindit engineers ran the pilot over three months. Databricks funded it. The pilot had one job: prove on real bank code that conversion works, before anyone signed for the full program.
Running the old and the new platform in parallel
The bank cannot pause daily reporting while its platform changes. So old and new run side by side.
We call this changing the engine while flying. CI/CD pipelines move one workload at a time. The data team keeps delivering its daily reports from whichever platform owns each workload at that moment.
The plan has three stages:
| Stage | What happens |
| First | Pilot, first warehouse workloads, Azure foundation, first legacy systems switched off |
| Second | Transition to Databricks complete, legacy Oracle warehouse decommissioned |
| Third | Single source of truth, data model redesign, work absorbed by the bank’s own teams |
The mindit team peaks at 15 to 25 people, then shrinks. A migration that leaves the bank dependent on its vendor has only moved the problem.
An Oracle team on a Spark platform
A data team trained on Oracle for two decades does not own a Spark platform on day one. The bank’s 100+ data people are the ones who will run the lakehouse after we leave.
So the program includes structured upskilling for that team, running alongside the migration.
What the regulator needs to see
A bank migration is also a supervisory event. This bank agreed the solution and the implementation approach with its national banking regulator before the migration started.
Under DORA, a bank must show where each data set came from, who changed it, and how it recovers after a failure. We build that evidence into the platform. Unity Catalog records lineage and access. Collibra holds the business glossary and the data quality rules.
Where the money in a bank migration comes from
When the bank approved the program, its five-year business case projected:
| Projected outcome | Figure |
| Net benefit over five years | EUR 25M+ |
| Total cost of ownership versus on-premise | up to 40% lower |
| Share of benefit from switching off the legacy warehouse | 56% |
These are projections, not measured results.
The last row is the one to remember. More than half the value comes from turning the old warehouse off. A migration that goes live but never decommissions pays for two platforms.
If you are planning an Oracle to Databricks migration
Count the stored procedures before you pick a tool. The amount and age of the logic decide the method more than the data volume does.
Test conversion on real code in a short pilot, with a budget small enough to lose.
Plan the decommission dates first. Go-live dates are a cost. Decommission dates are the return.
Agree the approach with your regulator before the first workload moves.
This migration runs on Databricks on Microsoft Azure, with Delta Lake, Unity Catalog, Collibra and Power BI. For more on our work with banks, visit our dedicated banking section.
