A line-by-line walkthrough of a legacy stored procedure moving to Databricks. Cursors, temp tables, and multi-statement transactions all move as SQL as part of the data warehouse migration.
by Abhishek Dey and Laurent Léturgez
Somewhere in your warehouse, hundreds of stored procedures wake up every night and quietly keep the business running. They were written years ago by a bunch of SQL developers who have long since left the company. They have nested cursors. They create temporary tables on the fly. They bundle updates across multiple tables into a single transaction. And somewhere around line 47, there is a comment that simply says: “Do not change this.” No one fully understands these procedures anymore. Yet everyone depends on them. The revenue dashboard, the finance close, the operations report, all of them, in one way or another, trace back to these layers of procedural SQL business logic.
Moving data to the lakehouse is well-understood. The friction has been the procedural core of any data warehouse migration: the stored procedures, transaction handling, temp tables, control flow, and the fact that much of the enterprise still runs on SQL skills. Every time a migration came up, these procedures became the first thing everyone pointed to: “We cannot move until we can run that with minimal changes. Our enterprise is still heavily SQL-driven.”
